Understanding web rendering strategies helps you combine them effectively like the computer memory hierarchy

Have you ever wondered why you can play a graphics-heavy game without a single stutter? The answer isn't one powerful chip — it's several layers of memory working together. The same principles apply to the modern web today. Delivering a seamless experience isn't about picking one rendering strategy — it's about knowing how to combine several: CSR, SSR, SSG, ISR, and Streaming.

What is web rendering?

Key metrics to know

Before comparing different strategies, let's clear one thing up: developers don't just rely on vibe checks like "I feel this website is smoother" or "Maybe this one is faster". In the web world, there are standards introduced by Google called Web Vitals.

Why should we know about these key metrics?

They help us speak the same language when discussing web rendering, and they determine two major things you should be aware of:

1. User experience: No one has the patience to stare at a blank screen for more than 3 seconds, or click a button and see no response. A slow website means customers walk away.
2. SEO ranking: Google officially prioritizes websites with superior UX, pushing them to the top of search results.

Every rendering strategy — whether it's CSR, SSR, or SSG — comes with its own pros and cons that directly impact these metrics. Therefore, understanding them is mandatory if you want to make informed trade-off decisions for your product. Here's a visual breakdown of all five:

One term you'll see a lot below is the JS bundle — the packaged JavaScript the browser downloads to boot your app. The bigger it is, the longer the browser spends parsing before the page becomes interactive, which is why every strategy below cares about how much JS it ships.

Web Rendering Strategies

CSR — Client-Side Rendering

How it works. The server hands over a nearly empty HTML shell and a big JS bundle. The browser downloads that bundle, boots up the framework, fetches data from an API, and only then paints the actual page. Every pixel you see is drawn by the client.

SSR — Server-Side Rendering

How it works. On every request, the server runs your components, fetches the data, and sends back fully-rendered HTML. The browser paints it immediately — no waiting for JS. Then a smaller JS bundle downloads and hydrates the page: it attaches event listeners so buttons, forms, and interactions come alive.

SSG — Static Site Generation

How it works. All pages are pre-rendered at build time. The build process fetches all the data needed, renders each page to HTML, and stores those static files. When a user visits, they get the pre-built HTML served directly from a CDN. No server computation, no waiting — just instant HTML.

ISR — Incremental Static Regeneration

How it works. Pages are pre-rendered at build time and cached on the CDN like SSG. But instead of being frozen forever, ISR regenerates pages in the background — on a schedule or on-demand. When a user visits, they get the cached version instantly. While they're reading, the server quietly regenerates the page in the background. Once ready, the new version replaces the old cache for future visitors.

Streaming

How it works. Instead of the server waiting to build the entire page before sending it, streaming breaks the HTML into small chunks and sends them to the browser as soon as they're ready. The fast parts (nav, layout, header) go out immediately; the slow, data-heavy parts follow as they finish.

At a glance

A framework for choosing

Before jumping into real routes, here's a compact decision framework — three questions that map directly to the trade-offs above. Ask them in order and the answers narrow down which strategy (or combination) fits.

1. Is the page public — does it need SEO?

This decides whether real HTML must exist at request time.

• Yes, it's public → Crawlers, LLMs, and social previews need fully-rendered HTML. CSR is out — pick from SSR / SSG / ISR based on Q2.
• No, it's behind auth → SEO isn't a constraint, and interactivity dominates. CSR is a great fit — ship a shell, boot the app, let every interaction feel instant without server roundtrips.

2. How fast does the data change?

This decides how fresh the served HTML has to be — and drives the choice between SSR, ISR, and SSG.

• Changes on every request → SSR
• Changes every few minutes or hours → ISR
• Almost never changes → SSG

3. Does the page have a slow part that blocks everything else?

This decides whether to layer Streaming on top of whatever you picked in Q2 — so one slow data source doesn't hold up the rest of the page.

Case studies

Theory only sticks when you see it applied. Below are two real products I've worked on — an AI-powered SaaS and an e-commerce platform.

E-commerce

Now picture a gifting-focused online store. Every page has to earn its place on Google and reflect the correct price and stock at all times — and there's a marketing team behind it that keeps rewriting SEO metadata for each new campaign. Those three pressures — SEO, freshness, and non-dev content changes — pull different routes toward different strategies.

SaaS app

Picture a platform where users upload private documents and chat with them through AI. Almost everything lives behind a login and belongs to one user, so SEO barely matters and most routes lean toward the client. But a few pages break that pattern — a public landing page that must rank, and shared answers that need to be crawlable — and those are exactly where the strategy flips.

After analyzing the two apps, a few principles stood out:

1. SSG/ISR only works when the data is the same for every user. If the content changes only when a developer edits the code → SSG (a redeploy happens anyway). If a non-dev edits it through a CMS → ISR, with a webhook for instant publishing and a periodic revalidate as a safety net. But when the data differs per user, SSG/ISR is wrong from the start — whether or not the data "changes."

2. Streaming makes a page feel fast, not actually fast. It shows the user the shell early, but a heavy query is still heavy. Real speed comes from the data layer (pagination, server-side aggregation). Streaming is a way to present, not a way to optimize.

3. A route isn't a single render unit — it's a component tree. The right question isn't "is this page SSR or CSR?" but "where does the server/client boundary run through the tree?" A static shell, heavy sections streamed in via Suspense, interactive or per-user parts pushed to the client.

4. Rendering handles the first load; real-time handles everything after. SSE or WebSocket isn't a "rendering strategy" — it's a push channel layered on top of an already-rendered page.

Conclusion

The computer memory hierarchy — L1, L2, RAM, disk — was engineered over decades to coordinate automatically, squeezing out performance without us ever having to think about it. Web rendering has no such automation. Nothing quietly picks CSR, SSR, SSG, ISR, or Streaming for each part of your page on your behalf.

That job belongs to the developer. Understanding the trade-offs of each strategy, choosing the right one for each page — and going further, choosing the right one for each part of a page — is where the real gains compound. A route isn't a single render unit; it's a component tree, and each branch can live at a different tier of the hierarchy.

References

• Rendering on the Web — web.dev
• Core Web Vitals — web.dev