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 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/backpressure.
• 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.org and 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; renderToPipeableStream replaces renderToNodeStream. 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.
• sources/2026-09-23-github-rendering-huge-pull-requests-in-the-github-copilot-app — stream-structure-before-content at the diff-data layer. GitHub's Copilot-app PR view requests the diff incrementally so the file tree and metadata paint while the document is still loading, resolves the full set of review threads up front, and defers per-item work — syntax highlighting runs off the main thread (rows appear as plain text, colored when results arrive) and large markdown / suggested-change context is built only as it approaches the viewport. Same "commit structure early, fill content lazily" discipline as streaming SSR, applied to a client-rendered virtualized surface rather than a server HTML stream; pairs with concepts/list-virtualization as the rendering-side counterpart.