Open dferber90 opened 2 years ago
On further thought having useFlags
render <link />
would happen too late. At that point the real request could start already (unless using SSR).
Should we export a <PreconnectFlags config={config} />
component instead that should get rendered into Head
by users?
Then users can decide manually whether to render it everywhere or just on specific pages.
Following up on this re Next 13. Is there a reason config needs to be passed to PreconnectFlags
? I feel like it would be beneficial to just mention prefetch in the docs to avoid the overhead of another component. We could just explain that it should be put in the head.ts
or NextHead
of each page that they need it on.
If it still isn't in the docs I would be happy to add it :)
The only reason would be so that it can connect to the correct domain, but if people supply their own <link rel="preconnect" href="https://happykit.dev" />
I don't think it's necessary.
Side note: For ultimate perf, you'd wanna read your feature flags in middleware from Edge Config using this integration https://vercel.com/integrations/happykit which syncs happykit's feature flags to Edge Config. You'd then never actually read the flags on the client and deal with static pages only. In this world the preconnect is totally unnecessary since you never connect to happkyit.dev.
If this does not fit your model you can actually have an Edge API Route in your own application which reads the feature flags. An example of that is here. For this to work you should also use the integration to sync your feature flags into Edge Config. Then you don't need the preconnect either as everything happens on your domain.
We can reduce the time happykit's first client-side request takes by pre-establishing the connection (
preconnect
) or at least the DNS resolution (dns-prefetch
).We can do this by having users add
<link rel="dns-prefech" href="https://happykit.dev" />
or<link rel="preconnect" href="https://happykit.dev" />
to<head />
.But there is one downside, as not all pages will actually make a request to happykit:
We could in theory optimise this further. When rendering, we know whether happykit is going to make a request the first time it renders. It will only skip the request if initial data from server-side rendering is passed in. It will make a request if no data is passed in, or if static initial data is passed in.
~We could extend
useFlags()
to tell a<PreconnectContext />
whether to add<link rel="preconnect" href="https://happykit.dev" />
or not depending on the type of data being passed in.PreconnectContext
would then add it to the<head />
. This would give us control per page.~~But it might be better to simply always have the
<link rel="preconnect">
on the page. It's a tradeoff of wasted CPU cycles fro establishing the connection which might not get used and having a bigger bundle size and some CPU cycles for figuring out whether to preconnect or not.~ No,useFlags
is too late. At that point the real request could happen already. It needs to be in the Head before js bootsThe third alternative is to educate
@happykit/flags
users that they can add<link rel="preconnect">
to all pages usinguseFlags()
where it will fetch on mount manually by doing the following:Resources: