Rendering strategies: SSG, SSR, ISR, streaming, and hydration

A user taps a product page. The server sends finished HTML — text, price, photo arrive in under a second, the page looks ready. Then nothing happens when they tap “Add to cart” for another two seconds. The page is painted but not yet alive.

The rendering strategies split on timing. SSG (Static Site Generation) renders at build time — the HTML is a file on a CDN, served instantly to every visitor. SSR (Server-Side Rendering) renders per request — fresh HTML for every hit, but the server works on every request. ISR (Incremental Static Regeneration) is SSG that refreshes itself on a schedule or on demand. Streaming SSR sends the HTML in chunks as each part is ready, rather than waiting for the whole page.

Cutting across all of them: hydration is the client-side step where React (or any framework) re-runs the component tree to attach event handlers and state to the server’s HTML. Until hydration finishes, the page looks done but cannot be clicked.

The restaurant metaphor. SSG is a meal cooked in advance and kept ready — served instantly, but made hours ago. SSR is cooking to order — fresh and exactly right, but the customer waits. ISR is a buffet a cook refreshes every so often — mostly instant, occasionally a tray is swapped. Streaming is bringing out each dish the moment it is ready. And hydration is the part after the plate lands: the food looks perfect, but the customer cannot eat until the cutlery arrives.

Why the gap matters. A server-rendered page looks ready almost instantly — text and images are right there in the HTML. But click a button before hydration finishes and nothing happens: the picture is on screen, the app is not running yet. The gap between “looks ready” and “works” is the most misunderstood thing in modern web performance.