A team must choose between static generation, incremental regeneration, server rendering and client rendering for different parts of a product. What decides each, and what is the common mistake?

The four options and what each optimises

Static generation (SSG) — pages built at deploy time, served from a CDN. Fastest possible delivery and cheapest, with content frozen until the next build. Suits marketing pages, documentation and anything whose content changes on a deployment cadence. The failure mode is build time: a site with a hundred thousand pages takes an unacceptable time to build and every content change requires a full rebuild.

Incremental static regeneration (ISR) — pages generated on first request, cached, and regenerated in the background after a defined interval or on demand. Static performance with content freshness, and the build does not have to cover every page. This is the correct default for large content-heavy sites, and it solves SSG's build-time problem directly.

Server-side rendering (SSR) — rendered per request. Necessary when the content genuinely depends on the request: the authenticated user, real-time data, personalised results. Costs origin compute per request and adds latency that caching cannot remove.

Client-side rendering (CSR) — the browser fetches data and renders. Suits application-like interfaces behind authentication, where the first paint matters less than interaction responsiveness and where SEO is irrelevant.

What decides it, per route

• Does the content depend on the request? No → static or ISR. Yes → SSR or CSR.
• How fresh must it be? Deploy-cadence → SSG. Minutes → ISR. Per request → SSR.
• Does it need to be indexed or shared? If yes, the content must be in the initial HTML, which excludes CSR.
• Is the first paint or the interaction the thing that matters? A content page needs the first; an application dashboard needs the second.
• How many pages are there? Very large page counts push toward ISR regardless of other considerations.

The decision is per route, not per application — and a product will legitimately use all four.

The common mistake

Choosing one strategy for the whole application, usually server rendering, because it is the framework's default and it "works everywhere."

The result is origin compute spent rendering pages that are identical for every user, cache hit rates near zero on content that could have been static, and a scaling problem that is entirely self-inflicted. The marketing pages, the documentation and the product catalogue do not need per-request rendering, and rendering them per request is the largest avoidable cost in most frontend architectures.

The second mistake is the opposite: static generation for content that is genuinely personalised, producing either a flash of incorrect content or a client-side fetch that undoes the benefit.

The hybrid that usually wins

Static or ISR for the shell and the shared content; client-side or streamed server rendering for the personalised fragments. The user gets an immediate first paint from cache, and the personalised parts arrive without blocking it — which gets the SEO and speed of static with the freshness of dynamic, at the cost of a more complex rendering model and a visible loading state for the personalised regions.