Skip to content

CONCEPT Cited by 1 source

Streaming SSR

Streaming server-side rendering is an SSR variant where the server emits HTML incrementally as regions of the page become ready, instead of blocking until the full tree renders. The browser can paint earlier chunks (recovering the SPA-style fast First Contentful Paint) while later regions — gated by slow data — stream in behind them. React 18 operationalized it with renderToPipeableStream / renderToReadableStream + <Suspense> boundaries; equivalents exist in other frameworks (e.g., Next.js App Router, Astro partials).

Load-cycle comparison

Model FCP TTVC TTI
SPA early (shell only) late (after data fetch) early (shell interactive)
Classic SSR late (full page) early late (awaits hydration)
Streaming SSR early (first boundary) often faster than SPA early (per-boundary)

(Source: sources/2026-04-16-atlassian-streaming-ssr-confluence — Confluence reports ~40% FCP improvement from adopting it.)

Required primitives

  • A boundary mechanism that lets the renderer commit markup for a region while later regions are still pending. React uses <Suspense> — see patterns/suspense-boundary.
  • A server→client transport that preserves chunk boundaries. HTTP chunked transfer works, but every intermediate proxy and compression layer is suspect — they default to buffering. See concepts/head-of-line-buffering.
  • Per-chunk state injection ordered before the markup for that chunk, so hydration finds the state it needs in the page as each boundary arrives.

Trade-offs

  • Wins back early FCP/TTI without giving up SSR's visually-complete content — the best of SPA + classic SSR on first paint.
  • Cost: the whole pipeline must be chunk-aware — data loaders bound to Suspense boundaries, transforms running in objectMode, compression force-flushed, proxies with buffering disabled.
  • Adds hydration-ordering constraints that are easy to get wrong and manifest as cryptic "hydration mismatch" errors.

Seen in

Last updated · 200 distilled / 1,178 read