Incremental Static Regeneration

Static generation's problem was never speed — a pre-built HTML file served from a CDN edge is about as fast as a response can be. Its problem is scale: if the only way to reflect a content change is to rebuild the entire site, that's fine for a ten-page marketing site and completely impractical for a product catalog with a million pages, a fraction of which change on any given day. Incremental Static Regeneration (ISR) is the fix — static generation that regenerates individual pages on their own schedule, without a full rebuild.

The mechanism: stale-while-revalidate, per page

ISR borrows an idea from HTTP caching: serve what you already have immediately, and refresh it in the background rather than making anyone wait. Concretely, a page built with a revalidate window (say, 60 seconds) works like this:

Two variants matter in practice. Time-based revalidation (revalidate: 60) regenerates on a fixed schedule regardless of whether anything actually changed — simple, but you're accepting up to that window's worth of staleness even when content hasn't moved. On-demand revalidation (triggered by a webhook from your CMS, for instance) regenerates the instant content actually changes, which gets you SSR-like freshness with SSG-like cost — at the price of needing something to fire that webhook reliably.

What you're actually trading

ISR is not "SSG but always fresh" — it's a deliberate trade of a bounded staleness window for the ability to skip rebuilding everything. That trade is excellent for a product page that changes a few times a day (price updates, stock levels), acceptable for a blog post that gets a typo fix, and wrong for anything where staleness itself is the failure mode — a live auction, a stock ticker, an inventory count at the exact moment of checkout. Those want SSR (or a client-side subscription layered on top of a static shell), because the whole premise of ISR is that serving something slightly out of date is an acceptable, even preferable, trade for speed and cost.

There's also a subtler cost: first-request-after-expiry consistency. If your traffic is bursty, several requests can land in the small window before regeneration finishes, all getting the same stale page — which is usually fine, but worth knowing if you assumed "revalidate: 60" means "never more than 60 seconds stale" as a hard guarantee rather than a target.

Where this fits in the bigger picture

ISR is best understood as an operational answer to a business question: "how fresh does this really need to be, and what does it cost us if it's briefly wrong?" A news homepage might revalidate every 30 seconds. A product page might revalidate every hour, plus an on-demand hook when a price actually changes. A terms-of-service page might never revalidate at all, because it's SSG in the purest sense — nothing about ISR obligates you to use a short window everywhere. The skill being tested in an interview isn't knowing that ISR exists; it's picking the right revalidation strategy — or correctly ruling ISR out — for a specific piece of content.

What to remember

• ISR fixes SSG's scaling weakness: pages regenerate individually, on their own schedule, instead of requiring a full site rebuild.
• Stale content is served immediately while a fresh version regenerates in the background — nobody blocks on a rebuild.
• Time-based revalidation is simple but accepts staleness up to the window even when nothing changed; on-demand revalidation trades that for a dependency on a reliable trigger.
• ISR is wrong wherever staleness itself is unacceptable, even briefly — that's an SSR or live-subscription problem, not a caching one.