Streaming SSR for Perceived Performance

The plain-language idea

You already know the tradeoffs between SSR, SSG, and CSR from the rendering-strategies lesson. This lesson is about a specific limitation of traditional (non-streaming) SSR, and the technique that addresses it.

Traditional SSR renders the entire page server-side before sending any HTML at all. If one part of the page depends on a slow data source — a slow database query, a third-party API call, anything with real latency — the server waits for that to finish before it can send any bytes, even for parts of the page that had no dependency on the slow data whatsoever. A fast header and a slow personalized recommendations widget, rendered together in one traditional SSR pass, both wait for the slower one. The user sees nothing until the slowest part is ready.

Streaming SSR sends HTML in chunks, as each piece becomes ready, instead of waiting for the whole page. The fast shell — header, nav, layout, anything with no slow dependency — can be sent and start painting in the browser immediately, while the slower section is still being fetched and rendered on the server. The slow section arrives in a later chunk and gets inserted into the page once it's ready.

See it in a real thing: a page with one slow widget

Traditional SSR:
  [wait for header data] -> [wait for slow widget data] -> send ALL html -> browser paints everything at once
  time to first paint = time for the SLOWEST part

Streaming SSR:
  [header ready] -> send header chunk -> browser paints header
                     [slow widget still loading...]
                     [widget ready] -> send widget chunk -> browser paints widget
  time to first paint = time for the FASTEST meaningful part

This is specifically a perception and metrics story, not a total-work story. The server still has to do the same amount of work to render the slow widget — streaming doesn't make the underlying data fetch or render any faster, and total time-to-fully-loaded can be identical, or even very slightly longer once you account for streaming's own overhead (keeping the connection open, flushing chunks). What changes is which content the user sees, and when. If the page's largest visible element lives in the fast shell, LCP is measured against when that shell paints, not against when the slowest widget finally arrives — and that's a genuine, measurable improvement in the metric that captures "does this feel fast," even though the server did the exact same total amount of work either way.

What people usually miss

Watch out

• Streaming doesn't reduce total server work — it reorders when results become visible. The slow data fetch still takes exactly as long; streaming just stops it from blocking everything else.
• LCP can improve dramatically from streaming even when nothing about the underlying data-fetching got faster — because LCP measures when the largest visible content painted, and streaming can get that content to paint well before the whole response finishes.
• A page's total load time isn't necessarily better with streaming, and can be marginally worse due to keeping a connection open longer and the overhead of chunked delivery — the win is specifically in perceived/metric performance for the content that arrives early, not in raw total throughput.
• This only helps if the fast content is actually independent of the slow content. If everything on the page genuinely depends on the same slow data source, there's nothing fast to stream first, and streaming buys nothing.

Why this matters in interviews

"Your SSR page has a slow third-party API call in one widget, and it's dragging down LCP for the whole page — what would you do?" is a real question, and naming streaming SSR specifically — sending the fast shell early while the slow widget's chunk arrives later — shows you understand LCP measures when the largest content paints, not when the whole response finishes, which is exactly the distinction a shallow "just cache the API call" answer misses.