CONCEPT Cited by 4 sources
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¶
- sources/2026-04-16-atlassian-streaming-ssr-confluence — Confluence's React 18 streaming SSR rollout.
- sources/2024-08-01-vercel-how-google-handles-javascript-throughout-the-indexing-process
— canonical wiki instance of Google-successfully-indexes-
streaming evidence. Vercel + MERJ measured streamed React
Server Component content on
nextjs.organd confirmed Googlebot fully captures the stream. "Streamed content via RSCs was also fully rendered, confirming that streaming does not adversely impact SEO." Removes a specific adoption friction for Streaming SSR — the SEO-regression worry is empirically disposed of for Googlebot. - sources/2026-04-21-vercel-bun-runtime-on-vercel-functions — canonical wiki instance of runtime-implementation choice as the dominant cost axis for streaming SSR. Vercel's 2026-04-21 profiling + benchmark: streaming SSR via Next.js App Router is the workload where the Node.js vs Bun gap is largest (28 % TTLB reduction on CPU-bound Next.js rendering). The transform chain per chunk — Web Streams + buffer scanning + data conversions + GC pressure — dominates CPU time, and runtime Web-Streams implementation is the differentiator. Also canonicalises TTFB vs TTLB measurement — TTFB hides the per-chunk transform cost streaming SSR pays.
- sources/2023-07-10-zalando-rendering-engine-tales-road-to-concurrent-react
— canonical wiki instance of streaming SSR in a
pre-existing in-house partial-streaming framework migrating
to React 18. Zalando Rendering Engine's Renderers become
<Suspense>boundaries;renderToPipeableStreamreplacesrenderToNodeStream. A/B-measured impact of the narrow API swap on Fashion Store: INP −5.69 %, FID −8.81 %, LCP −2.43 %, FCP −0.23 %, bounce rate −0.24 %. Pairs with Confluence as the second production-React-18-streaming- SSR instance, with the architectural distinction that Zalando rejects hook-based render-as- you-fetch in favour of an Application- State layer outside React that dictates Suspense state.