Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
dferber90 opened this issue Oct 12, 2021 · 3 comments
Open

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

dferber90 opened this issue Oct 12, 2021 · 3 comments

Comments

@dferber90
Copy link
Contributor

dferber90 commented Oct 12, 2021 •
edited

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
Copy link
Contributor Author

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
Copy link

awndrw commented Jan 21, 2023

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
Copy link
Contributor Author

dferber90 commented Jan 23, 2023 •
edited

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dferber90 @awndrw