Rendering Strategies

Before this

• Next.js App Router — File-based routing, layouts, and the server/client boundary you must hold in your head.

Why this exists

A marketing page that changes twice a year and a stock ticker that changes every second should not be rendered the same way — one can be built once and served instantly from a CDN forever, the other must be computed fresh on every single request. Choosing the wrong strategy for either means either stale content masquerading as live, or unnecessary server work on every request for content that never changes.

The mental model

The real question behind all three strategies is one thing: WHEN does the render happen relative to the request? Static generation renders once, at build time, long before any request exists. Server-side rendering renders fresh, for every single request, at the moment it arrives. Incremental static regeneration renders once, then periodically re-renders in the background on a schedule, serving the last-built version in the meantime.

How it works

The mechanism

For static generation, the render happens once, entirely before any user ever visits, and the result is served as-is indefinitely. For ISR, that same one-time render is periodically redone on a timer in the background, with users seeing the previous version until the new one finishes and swaps in. For SSR, no pre-built version exists at all — every request triggers a full render right then, guaranteeing current data at the cost of that render's latency.

flowchart LR
  SSG[Static: build time, once] -->|served forever from CDN| U1[User]
  ISR[ISR: build time + periodic background regen] -->|serves cached, then swaps| U2[User]
  SSR[SSR: every request, live] -->|fresh render each time| U3[User]

What people get wrong

SSR is always better because it's always fresh, so it should be the default choice.

SSR costs real server compute on every single request, which is genuinely wasteful and slower for content that rarely or never changes — the 'always fresh' property is only valuable when the content actually changes often enough to matter. Defaulting to SSR for everything (like a static about page) adds real latency and server cost for zero actual freshness benefit, since the content wasn't going to change between requests anyway.

ISR means the content is always slightly stale by a fixed, known amount.

ISR serves the last-built version until the NEXT request after the regeneration interval triggers a fresh build — the actual staleness window depends on traffic patterns, not just the configured interval, and after that first post-interval request, subsequent requests get the fresh version until the next interval. Misunderstanding the exact mechanics can lead to assuming content updates precisely on a timer, when it actually depends on when a qualifying request happens to arrive after the interval elapses.

Static generation can't handle any dynamic or personalized content at all.

A statically generated page can still include client-side fetched data (via a Client Component making its own request after the page loads) for genuinely personalized or highly dynamic pieces — static generation applies to what's baked into the initial HTML, not necessarily every single thing on the page. This is what lets teams use static generation for the bulk of a page's content while still showing something like a personalized 'welcome back' message fetched client-side after load.

When not to use it

The content is identical for every visitor and changes rarely — documentation, a marketing page, a blog post.

Static generation — there's no reason to pay a per-request rendering cost for content that's the same for everyone and doesn't change between builds.

The content is specific to the requesting user's session and must never be shared across users, like an account balance.

Server-side rendering (or client-side fetching after a static shell loads) — this can't be pre-built once and shared, because it's different for every single request.

Terms

Static generation (SSG)

— Rendering a page once at build time, serving the resulting file as-is for every subsequent request, indefinitely.

Server-side rendering (SSR)

— Rendering a page fresh, on the server, for every single incoming request.

Incremental static regeneration (ISR)

— Serving a statically-built page while periodically regenerating it in the background on a schedule, without requiring a full site rebuild.

Time to first byte (TTFB)

— How quickly a server begins sending a response — typically fastest for static/cached content, slowest for a request requiring fresh server-side computation.

In an interview

Connected ideas

• CDNs & the Edge — Move the bytes closer to the user — the highest-leverage latency fix available.
• Cache Invalidation — TTLs, tags, stale-while-revalidate — the genuinely hard half of caching.