SSG, SSR, ISR, streaming, and RSC — how each works

A product page price changes twice a day. A logged-in dashboard is different for every user. A blog post is the same for everyone. These three facts imply three different rendering strategies — and picking the wrong one means paying for server compute on every request when a CDN cache hit would do, or serving a stale price for 12 hours when ISR could cap staleness at one hour.

SSG: render at build time. Static Site Generation runs the components once, during the build, and writes the result to HTML files deployed on a CDN. The request path is unbeatable — no server compute, an edge cache hit, time-to-first-byte in tens of milliseconds. The cost is freshness and scale: content is frozen at build time, and a million-page site takes a long time to rebuild. SSG is the right default for anything whose content does not change per request and per user: marketing pages, docs, blog posts. The moment the page must reflect “now” or “this specific user,” pure SSG breaks down.

SSR: render per request. Server-Side Rendering runs the components on the server for every request, producing fresh HTML each time. It can read the user’s cookies, the current time, live data — the HTML is exactly right for this request. The cost is on the critical path: the user’s time-to-first-byte now includes the server’s render time plus any data fetching it does. A slow database query in the render is a slow TTFB for the user. SSR also means you run and pay for server capacity that scales with traffic. SSR is right when the page must be per-request fresh or per-user personalised — a logged-in dashboard, a feed, search results.

ISR: SSG that refreshes itself. Incremental Static Regeneration is SSG with a revalidation rule. The page is served static from cache, but after a configured time — or on an explicit on-demand trigger — the next request gets the stale copy while the server regenerates a fresh one in the background; subsequent requests get the new version. It is stale-while-revalidate applied to whole pages. ISR is the answer to “mostly static, but the content does change — a product page whose price updates a few times a day.” You get SSG’s instant delivery for the overwhelming majority of requests and bounded staleness instead of a full rebuild.

Streaming SSR: send the HTML in chunks. Plain SSR has a blocking flaw: the server must finish rendering the entire page — including its slowest data fetch — before it can send a single byte. If one widget needs a 400 ms query, every user waits 400 ms for time-to-first-byte. Streaming SSR fixes this. With renderToPipeableStream, the server sends the shell immediately, and each <Suspense> boundary streams in as its data resolves. The user sees the header, nav, and layout in ~50 ms; the slow widget arrives 400 ms later as a streamed chunk that the browser slots into place. TTFB drops to the speed of the fastest part of the page, not the slowest.

React Server Components: components that never ship to the client. RSC is a different axis entirely. A Server Component runs only on the server — its code is never sent to the browser. It can read the database directly, use server-only secrets, and import heavy libraries (a markdown parser, a syntax highlighter) that cost the client nothing because they never cross the wire. Its output is not HTML and not a JS bundle — it is a special serialised format, the RSC payload, describing the rendered tree. Client Components (marked 'use client') are the interactive islands within that tree; only their code ships. The win is bundle size: parts of your app that are just “display server data” carry zero client JavaScript.