SSG, SSR, ISR: who builds the HTML, and when

Three answers to one question

Every rendering strategy is an answer to a single question: at what moment does a server turn your React tree into HTML? SSG (Static Site Generation) answers “at build time”: next build renders the page once, the output is a plain .html file (plus a payload for client navigation), and a CDN serves that file forever — TTFB is whatever the nearest edge node takes, typically 10–50ms, and your origin does zero work per request. SSR (Server-Side Rendering) answers “on every request”: each visitor pays for a fresh render — the server fetches data, runs your components, and streams HTML. You get perfect freshness and access to request-time context (cookies, headers, geo), and in exchange TTFB now includes your data layer: a page that waits on a 200ms database query has a 200ms+ TTFB floor, multiplied by every concurrent user. ISR (Incremental Static Regeneration) is the deliberate compromise: serve the cached static page immediately — even if it’s stale — and if the page is older than its revalidate window, trigger a re-render in the background. The visitor who triggered regeneration still gets the old page; the next visitor gets the new one. This is the stale-while-revalidate pattern applied to whole pages.

In the App Router you don’t pick a mode with a config flag — the route’s behavior falls out of how it fetches data:

// app/products/[id]/page.tsx

// ISR: this page is static, re-rendered in the background
// at most once every 60 seconds per path.
export const revalidate = 60;

export async function generateStaticParams() {
  // Pre-render the top 100 products at build time (SSG);
  // other ids render on first request, then cache (ISR on demand).
  const top = await getTopProducts(100);
  return top.map((p) => ({ id: p.id }));
}

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProduct(params.id);
  return <ProductView product={product} />;
}

// Flip to full SSR instead: every request renders fresh.
// export const dynamic = "force-dynamic";

One file expresses all three: paths from generateStaticParams are SSG, the revalidate export turns the cache into ISR, and force-dynamic (or reading cookies()/headers()) opts the route into per-request SSR. The danger is that this is implicit — adding one cookies() call deep in a shared component silently converts a static route into SSR, and your “static” page starts hammering the origin.

The tradeoff matrix: TTFB, freshness, infra cost

Lay the three strategies on three axes and the decision becomes mechanical. TTFB: SSG wins outright — a file from a CDN edge, 10–50ms, no origin involved. ISR is the same on the hot path (it is a cached file) with occasional background work. SSR is the only one where TTFB includes compute and data fetching: realistically 100–500ms from the origin region, worse cross-continent, and it degrades under load because every request consumes server CPU. Freshness: SSR is always current. ISR is bounded-stale — at most revalidate seconds plus regeneration lag. SSG is frozen until the next deploy; a typo on a fully static marketing page costs you a full build-and-deploy cycle, which on a large site can be 10–20 minutes. Infra cost: SSG is nearly free to serve at any scale — 10 requests or 10 million, the origin does the same work: none. ISR costs one render per path per window, independent of traffic — a beautiful property: 1M views/hour on a revalidate: 60 page is still ~60 renders/hour. SSR costs scale linearly with traffic; it is the only strategy where a traffic spike is also a compute spike, and the only one where you need to think about autoscaling and connection pools to survive the front page of Hacker News.

The honest selection rule is not “which is best” but “what staleness can this route afford”: docs and marketing → SSG; product listings, news, dashboards-for-everyone → ISR with a window matched to the data’s real change rate; anything personalized, paginated by user, or reading cookies → SSR (or, more precisely, dynamic rendering with cached data underneath).

Failure modes: stale-after-deploy and the thundering herd

Two production failures define this topic. First: ISR serving stale after a deploy. The ISR cache is keyed to a build. Self-hosted, the default cache lives on the filesystem of each instance — a new deploy starts with an empty cache (or worse, with several instances each holding a different cache, so users see different versions depending on which pod they hit). On Vercel the cache is shared and survives deploys for unchanged pages, but a changed page resets, and revalidate timers reset with it. Either way the mental model “deploying flushes everything to fresh” is wrong in both directions: some pages stay stale, others lose their cache entirely. The fix for multi-instance self-hosting is a shared cache handler (cacheHandler in next.config.js pointing at Redis or similar) so all pods agree on what’s cached. Second: thundering revalidation. When a popular page’s entry expires — or a deploy empties the cache — every concurrent request in that gap can become a render. Within one Next.js instance, in-flight regeneration is deduplicated; across instances it is not, unless your cache handler implements locking. Ten pods × one expired hot page × a CMS that rate-limits = the Hook’s 500s. Mitigations: stagger windows so thousands of pages don’t expire in sync, prefer on-demand revalidation (revalidatePath from a webhook) for change-driven data so windows can be long, and warm critical paths immediately after deploy instead of letting real users do it.