Streaming Rendering

The server sends the page in pieces: layout and fast content first, skeletons where slow data goes, real content swapped in as it lands.

HTML arrives in chunkspage fills in piece by pieceserver sends each section when readystreaming SSRsend the shell firstprogressive renderingstreaming rendershow the layout while the slow data loads

See it

Live demo coming soon

What it is

Normal server rendering waits for every query to finish before sending one byte, so the slowest widget on the page sets the speed for the whole page. Streaming rendering flushes HTML in chunks instead: the shell (nav, hero, layout) goes out immediately with placeholders where the slow parts will be, and each slow part is streamed down and swapped into place as its data resolves.

You mark the seams yourself. In React that is a Suspense boundary wrapping the slow subtree with a skeleton as its fallback; in the Next.js App Router a loading.tsx or a Suspense wrapper does the same for a route segment. Under the hood it is a response body streamed progressively (however the HTTP version in play does that) plus framework-specific markers and inline scripts that move each late chunk into its slot, which is why chunks can arrive out of order. Reach for it when one section of a page is reliably slow (recommendations, reviews, a third-party API) and the rest is fast.

The gotcha nobody warns you about: once the first chunk is flushed the response is committed, so you cannot change the status code, set a cookie, or redirect anymore. Do your auth checks and redirects before streaming starts. Also, a buffering proxy or CDN can hold the whole response and hand it over at once, which silently deletes the benefit, so verify streaming actually survives in production.

Ask AI for it

Make this Next.js App Router page stream. Keep the shell (nav, heading, static copy) rendering instantly, move each slow data fetch into its own async server component, and wrap those in Suspense boundaries with skeleton fallbacks shaped like the real content so nothing shifts when it arrives. Do not await the slow queries in the page component itself. Run any auth check or redirect before the first flush, and add an error boundary per slow section so one failed fetch does not blank the page.

You might have meant

server side renderinghydrationreact server componentslazy loadingdata fetching