What does streaming SSR flush first, and why does it help?

The static shell (layout, header, nav) — immediately, without waiting on data. That drops TTFB and gives a fast first paint while slow regions stream in behind Suspense.

How do you control streaming granularity?

By where you place boundaries. Wrap slow, independent regions so fast content isn't blocked; use a few meaningful boundaries rather than one giant one or one per element.

What's the classic CLS pitfall with streaming?

Fallbacks that aren't sized like their real content. When the streamed content swaps in, it shifts layout. Size skeletons to match dimensions to keep CLS near zero.

Why is setting an HTTP status code tricky with streaming?

Once you start flushing the shell, the response head (status + headers) is already sent. Any status/redirect decision must happen before streaming begins.

Streaming SSR · fearchitect

Summary

Streaming SSR sends the page in pieces instead of waiting for all data. The static shell paints first; slow sections render placeholders and stream in as their data resolves. It turns a single slow query from a whole-page block into one spinner, improving TTFB and perceived performance.

Jump to the interview angle

Streaming SSR

Instead of awaiting every query before sending HTML, the server flushes the static shell first and streams slow regions in as their data resolves — turning one slow query from a whole-page block into a single skeleton.

The flow

1
Flush the shell
Header, nav, and layout are sent immediately, before any slow data resolves — so TTFB stays low.
2
Show fallbacks
Each <Suspense> boundary whose data is still pending emits its skeleton inline.
3
Stream the rest
As each region's data resolves, the server streams that HTML plus a tiny script that swaps out the fallback.
4
Hydrate selectively
React hydrates streamed regions as they arrive, prioritizing the part the user interacts with first.

The shell paints first; each slow region streams in and replaces its skeleton.

Size your fallbacks

If a skeleton isn't sized like its real content, the swap-in shifts layout and wrecks CLS. Match the dimensions.

Tradeoffs

Pros

Low TTFB and fast first paint — the shell isn't blocked by the slowest query.
Per-region loading states instead of one whole-page spinner.
Selective hydration prioritizes what the user touches first.

Cons

Unsized fallbacks cause layout shift (CLS).
Can't set an HTTP status once the shell has flushed.
More boundaries to reason about; some proxies buffer streams.

Interview angle

This is a favorite because it ties rendering, Suspense, and Core Web Vitals together. Interviewers probe where you'd put boundaries and how you'd avoid CLS. Strong answers connect streaming to TTFB and INP, and note the status-code caveat.

Soundbite: "Stream the shell first, wrap the slow, independent regions in Suspense, and size the fallbacks so nothing shifts. One slow query becomes one skeleton, not a blank page."

Key terms

Suspense boundary: A React region that shows a fallback while its children's data is pending, then swaps in real content.
Selective hydration: React hydrating streamed regions independently and prioritizing the part the user interacts with first.
renderToPipeableStream: The Node.js React API that streams SSR output as a pipeable stream (Web runtimes use renderToReadableStream).

Summary

Streaming SSR

The flow

Tradeoffs

Interview angle

Key terms

Related topics

Further reading

Search fearchitect