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.

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

Use streaming for dynamic page content #523

Open
1 of 3 tasks
taesungh opened this issue Dec 23, 2024 · 0 comments
Open
1 of 3 tasks

Use streaming for dynamic page content #523

taesungh opened this issue Dec 23, 2024 · 0 comments
Assignees

Comments

@taesungh
Copy link
Member

taesungh commented Dec 23, 2024

All pages of the main site need to be dynamically rendered because the Navbar depends on getUserIdentity to show specific navigation items based on the user's status. While dynamic rendering itself is not a huge problem, the initial loading of the site can feel really slow if there is a cold start for the serverless function that's running the API. I noticed that it can take over 6 seconds just to get a page response:

$ curl -v --trace-time https://irvinehacks.com
...
16:25:28.351589 > GET / HTTP/2
16:25:28.351589 > Host: irvinehacks.com
16:25:28.351589 > User-Agent: curl/8.7.1
16:25:28.351589 > Accept: */*
16:25:28.351589 > 
16:25:28.351642 * Request completely sent off
16:25:34.527435 < HTTP/2 200 

This is a very poor score for Time To First Byte which could be causing negative user sentiment. This can be improved by using Streaming with Suspense for the navigation items that do need to by dynamically rendered. This will allow all parts of the UI not depending on the API to be rendered and streamed first so the primary page content can be visible faster.

One alternative is reverting to a client-side fetch for the user identity in the navigation, but fetching data on the server-side is just a lot more convenient (no need to deal with useEffect, SWR, or React Query).

Besides the Navbar, the Apply, Login, Guest Login, and Portal pages also rely on getUserIdentity. Most of the time, these should be less impacted since the API would likely be in a warm state, but it's possible for somebody to directly open such pages and encounter a cold start. However, in many cases, the user identity determines a redirect, so it may semantically make more sense to not use streaming to preserve the HTTP status codes (although client-side redirects aren't terrible).

Next.js 14 also introduced Partial Prerendering, but this is still considered experimental even in Next.js 15. PPR would allow mixing static and dynamic components so the non-dynamic parts can be cached and served from a CDN.

Main tasks

  • Use streaming for dynamic items in the Navbar
    • Ideally the brand (Hack logo) is still shown on initial render
  • Check if streaming makes sense for the Apply and Portal pages
    • Any necessary usage would be in child components, after any redirects happen, but the data should technically already be available if past the point of checking identity
    • Alternatively, stream everything and defer to client-side redirects
  • Look into configuring Speed Insights with Vercel to get more detailed metrics
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants