happykit / flags

⛳️ Feature Flags for Next.js
https://happykit.dev
MIT License
1.02k stars 11 forks source link

Add `<link rel="preconnect" href="https://‎happykit‎.dev" />` #7

Open dferber90 opened 2 years ago

dferber90 commented 2 years ago

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:

Bear in mind that while is pretty cheap, it can still take up valuable CPU time, particularly on secure connections. This is especially bad if the connection isn't used within 10 seconds, as the browser closes it, wasting all of that early connection work. (source)

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 boots

The third alternative is to educate @happykit/flags users that they can add <link rel="preconnect"> to all pages using useFlags() where it will fetch on mount manually by doing the following:

import Head from 'next/head'

function IndexPage() {
  return (
    <React.Fragment>
      <Head>
        <link rel="preconnect" href="https://‎happykit‎.dev" />
      </Head>
    </React.Fragment>
  )
}

export default IndexPage

Resources:

dferber90 commented 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.

awndrw commented 1 year ago

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 :)

dferber90 commented 1 year ago

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.