You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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: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
The text was updated successfully, but these errors were encountered: