A 32-minute working session on how the web turns components and data into HTML — CSR, SSR, SSG, ISR, and streaming — and how to pick the right one per route instead of betting the whole app on a single default.
"Rendering" just means turning your components and data into the HTML a browser can paint. The only thing that really differs between strategies is where that work happens— a build machine, a request-time server, or the user's browser — and when it happens. Get those two axes straight and the rest of this deck is just named points on a map.
One axis: HTML built early (SSG/ISR) is fast but can go stale; built late (SSR/CSR) is fresh but costs time or compute. Everything else is detail.
Render once when you deploy. The result is a static file a CDN can serve to millions for nearly free — but it's a snapshot.
Render fresh on a server for each visitor. Always current and personalizable — you pay compute and time on every hit.
Ship JavaScript and let the browser build the page. Cheap servers, rich interactivity — but a slow, blank first paint.
Hybrid. Marketing page static, dashboard client-rendered, product page revalidated. Pick per route, not per app.
In the classic single-page app, the server sends almost no HTML — just an empty <div> and a script tag. The browser downloads the bundle, runs it, fetches data, and only then paints the screen. Brilliant for app-like interactivity; rough on that very first impression.
The user stares at a blank screen until the bundle downloads, runs, and fetches — then everything appears at once, fully interactive.
Like mailing someone a flat-pack and the instructions: it travels light, but they can't use the furniture until they've built it themselves.
SSR flips CSR around: the server runs your components per request, fetches the data, and sends finished HTML. The user sees content almost immediately. The catch is the second act — hydration — where the browser still has to download the same JS and re-attach all the interactivity.
Content paints early (good), but there's a window where it looks ready yet ignores clicks — until hydration finishes.
If a page looks the same for everyone, why rebuild it on every request? SSG renders it at deploy time into a plain file a CDN serves instantly and almost for free. The only weakness is staleness — and ISR is the fix: keep the static speed, but let pages quietly refresh themselves.
ISR serves the cached page instantly, then regenerates it in the background — readers never wait on a rebuild.
Docs, marketing, blogs, changelogs — content that rarely changes and looks identical for everyone. Cheapest and fastest there is.
Catalogs, listings, news — mostly-static pages too numerous or too fast-moving to rebuild fully, where minutes of staleness are fine.
Per-user or real-time data (cart, balance, dashboards) — static caching leaks one person's view to another. Keep those dynamic. On-demand revalidation pairs with cache tags.
Like a printed newspaper (SSG) versus one with a small inset that gets re-printed each morning (ISR) — far cheaper than a fresh edition per reader.
Plain SSR has one flaw: the slowest piece of data holds the whole page hostage — nothing ships until everything is ready. Streaming breaks that deadlock. The server sends the instant parts immediately and flushes the slow ones as chunks, with Suspense drawing placeholders in the gaps.
The static shell paints and reacts instantly; the slow region shows a skeleton, then streams in real content when its data lands.
use cachedirective: you mark what's cacheable, and everything else streams.Strategy isn't an aesthetic preference — it shows up in search rankings, in the metrics Google grades you on, and on your hosting invoice. Here's how the spectrum lands on each, and the frameworks that let you pick per route.
SSG/ISR pull TTFB and LCP far left; CSR pushes first content right (blank, then a burst); SSR is early paint with a hydration gap before interactive.
Crawlers and social scrapers read HTML best. SSG/SSR/ISR hand them complete markup; pure CSR risks an empty shell — Googlebot can run JS, but on a budget and a delay. Static <title> and OG tags are safest.
SSG/ISR win LCP (prebuilt, edge-served). SSR/streaming paint early but watch the hydration cost on INP. CSR tends to the worst LCP — nothing until the bundle runs.
Static is nearly free to serve at any scale. SSR/streaming bills compute on every request — and edge runtimes trade a constrained sandbox for lower latency than regional node.
Pick on how app-like the product is and which language your team lives in — each framework supports the whole spectrum, but optimizes for a different center of gravity.
Pro — every strategy in one place: Server Components, SSR, SSG, ISR, streaming, PPR.
Con — large surface area; richest features lean on Vercel.
Choose for React apps that need fine-grained, per-route control.
Pro — islands architecture ships zero JS by default; superb for content.
Con — less natural for heavily app-like, stateful UIs.
Choose for marketing, docs, and content-first sites.
Pro — compiler output is tiny; pick SSR/SSG/CSR per route via adapters.
Con — smaller ecosystem and hiring pool than React.
Choose for lean, fast apps where bundle size is king.
Pro— Vue's answer: hybrid rendering rules set per route.
Con— Vue-only; you inherit that ecosystem's bounds.
Choose when your team already builds in Vue.
The same app renders differently depending on the runtime it lands on — edge is globally close but constrained; node is full-featured but regional.
Pro — first-class Next.js: ISR, streaming, and PPR work out of the box, node or edge.
Con — usage-based pricing climbs with request volume.
Choose when Next.js is your framework and DX matters.
Pro — Workers run at the edge with near-zero cold start; cheap at scale.
Con — constrained runtime; not full Node by default.
Choose for global low-latency SSR and edge logic.
Pro — strong static + functions story; edge and node both available.
Con — advanced framework features can lag the platform they ship on.
Choose for static-heavy sites with some dynamic glue.
There is no "best" rendering strategy — only the cheapest one that meets a route's real freshness and interactivity needs. The win is realizing it's a per-route decision: one app can serve a static landing page, a revalidated catalog, and a client-rendered dashboard side by side.
Walk left to right only as a route's freshness and per-user needs demand it — most routes stop sooner than you'd guess.
Five quick questions on CSR, SSR, SSG/ISR, streaming, and Core Web Vitals — instant feedback, no sign-in.
Navigate with ← → or scroll · back to library