Rendering Strategies
Date: 2026-08-16
Where the HTML gets built — at build time, on the server per request, at the edge, or in the browser. It’s the decision most other architecture decisions inherit from, and the one hardest to reverse.
What it is
A rendering strategy is the choice of when and where markup is generated. The options aren’t exclusive; a real site usually mixes them per route.
| Built | Best for | Weakness | |
|---|---|---|---|
| SSG — static generation | At build time | Content that rarely changes | Rebuild to update; slow builds at scale |
| SSR — server-side rendering | Per request, on the server | Personalised or fast-changing pages | Server cost; TTFB depends on your backend |
| ISR — incremental static regeneration | At build, then refreshed in the background | Large catalogues that change occasionally | Staleness window; framework-specific |
| CSR — client-side rendering | In the browser, after JS loads | App-like interfaces behind a login | Poor SEO, poor first paint, high JS cost |
| Streaming SSR | Per request, sent in chunks | Pages with a slow data dependency | More complex; needs framework support |
| Edge rendering | Per request, near the user | Geographic personalisation, redirects | Constrained runtime, no direct DB access |
The decision
Two questions settle it for most routes.
1. Does this page need to be indexed? If yes, the HTML must contain the content. Crawlers see raw HTML immediately and render JavaScript later, on a queue — sometimes days later, sometimes not at all. And AI crawlers don’t render JavaScript at all. See Rendering and SEO.
2. Is the content the same for everyone? If yes, generate it once and cache it. If no, decide how personal — a name in the header is different from a fully personalised catalogue, and the usual answer is to cache the shell and fetch the personal parts separately rather than abandon caching — CDN Caching.
indexed + same for everyone → SSG or ISR, cached hard
indexed + varies by user → SSR, with a cached shell
not indexed + app-like → CSR is fine
geographic or A/B decisions → edge
What each does to the metrics
- SSG gives the best Time to First Byte — the file already exists
- SSR puts your backend on the critical path. Fast SSR beats slow CSR; slow SSR beats nothing
- CSR is worst for Largest Contentful Paint: the browser fetches an empty shell, then a bundle, then data, then paints
- All server strategies still need Hydration if the page is interactive, and hydration is where the JavaScript cost reappears — JavaScript Execution Cost
In plain terms: server rendering gets content on screen sooner. It doesn’t reduce the JavaScript you ship, and if you hydrate the whole page you’ve paid for the markup twice — once as HTML, once as the data and code to make it interactive.
The ecommerce pattern
For a typical retail site:
homepage ISR or SSG, revalidated hourly
category pages ISR, revalidated on publish; facets handled server-side
product pages ISR at scale, SSR where stock and price must be live
search results SSR or CSR — not indexed, so either is defensible
basket / checkout SSR or CSR, never cached, never indexed
account CSR behind auth
The tension is stock and price. Both change, both matter commercially, and both are on pages you want cached. The common resolution: render the page statically, fetch price and availability client-side, accepting a brief flash of stale data — and reserving space for it so it doesn’t cause Cumulative Layout Shift.
Choosing badly
- CSR on indexable pages. The most expensive mistake in ecommerce architecture, and the hardest to undo
- SSR everywhere, including pages identical for every visitor, so you pay server cost for no benefit and lose CDN caching
- SSG on a 200,000-SKU catalogue, producing builds measured in hours
- Strategy chosen per framework rather than per route. Frameworks support all of these; the decision belongs to the page
- Ignoring the hydration bill. A server-rendered page that ships 600KB of JavaScript to become interactive has moved the problem, not solved it — Islands Architecture