Streaming SSR
Slap yourself if
You think streaming SSR is just 'SSR but faster' or only about sending HTML in chunks.
Why this exists
Streaming SSR exists to reduce time-to-first-byte and time-to-first-render by progressively sending HTML as it becomes available, instead of waiting for the full render to complete. It also enables rendering fallback UI while slower data/components finish.
Mental model
Streaming SSR turns server rendering into a pipeline. The server can start sending the outer shell immediately, then progressively stream in completed parts (often around boundaries). The browser can parse and paint incrementally, and the client can hydrate as chunks arrive depending on the framework.
- A request hits the server and rendering starts.
- The server begins sending the HTML shell as soon as it can (before the full tree is ready).
- Slower parts render later and are streamed when they complete.
- The browser parses incoming HTML incrementally and can paint partial UI sooner.
- Client-side hydration can be coordinated with streamed boundaries (framework-dependent).
- Assuming streaming always improves perceived performance (it can increase total work).
- Breaking UX by streaming incomplete layouts that shift later (CLS risk).
- Overusing boundaries and increasing overhead (too many flush points).
- Caching and CDN behavior becoming harder (partial responses, personalization).
- Debugging becomes harder because timing-dependent bugs appear.
Streaming SSR is server-side rendering where HTML is sent progressively as parts of the UI become ready, allowing the browser to render earlier and enabling fallback UI for slower sections. It improves perceived performance by reducing waiting for the full render.
- Streaming SSR is just chunked transfer encoding.
- Streaming SSR always reduces LCP.
- Streaming SSR means the page is interactive sooner automatically.
Deep dive
Premium deep dives include more internals, more scars.
What actually streams and when
- Shell vs delayed segments
- Flush points and backpressure
- How fallbacks are represented in HTML
Impact on real metrics (LCP, INP, CLS)
Streaming helps perceived speed, but your Web Vitals can improve or regress depending on boundaries and layout stability.
How streaming can backfire
Streaming can create the illusion of speed while shifting cost elsewhere.
Tradeoffs vs classic SSR and islands
Streaming SSR optimizes delivery timing, not JavaScript size.
Debugging streaming issues
- Identify what renders the shell vs what is delayed
- Measure CLS and LCP around boundaries
Related terms
Hydration
You think hydration just means React attaching event listeners.
Partial Hydration
You think partial hydration just means hydrating components later.
Selective hydration
You think hydration is a single on/off switch that just needs to be faster.
Suspense boundaries
You think Suspense is just a loading spinner with better ergonomics.
Server components
You think server components are just SSR with better DX or a way to hide API calls.
Edge rendering
You think edge rendering is just SSR moved closer to the user.