Incremental Static Regeneration (ISR)

What is Incremental Static Regeneration?

ISR resolves the classic tension between static sites (fast, cheap, stale) and server rendering (fresh, slow, expensive). Pages are pre-rendered to static HTML and served from a CDN; each page carries a revalidation window. When a request arrives after the window expires, the visitor still gets the cached page instantly — and the platform regenerates the page in the background, so the next visitor gets fresh content. Popularized by Next.js, the pattern now exists across frameworks (Nuxt, Astro’s equivalent modes) and hosts.

The stale-while-revalidate bargain

ISR is the HTTP stale-while-revalidate idea applied to page builds: nobody ever waits for a rebuild, at the cost that someone occasionally sees content up to one window old. For product catalogs, docs, and content sites, that bargain is nearly always right — a 60-second staleness bound is invisible, while the alternative (rebuilding a 50,000-page site on every CMS edit, or server-rendering every request) costs real money and latency. On-demand revalidation closes the loop: a CMS webhook triggers regeneration of exactly the changed pages, making staleness event-driven rather than time-boxed.

Where it doesn’t belong

Anything personalized or transactional: carts, dashboards, per-user pricing. ISR caches one rendering per path; per-user content behind ISR is a data-leak pattern (one user’s cached page served to another). Those routes stay dynamic; ISR handles the long tail of shared content around them.

What people get wrong

• Revalidation windows as freshness guarantees — the window bounds staleness triggering, not delivery; the stale copy is still served once during regeneration.
• Forgetting fallback behavior: paths never built yet either block, 404, or serve a shell depending on configuration — an on-call surprise during traffic spikes to new content.
• Applying it to authenticated pages — the cache key is the URL, not the user.

Primary source: Next.js documentation — Incremental Static Regeneration

ISR’s Position Between Static and Server-Rendered

ISR occupies a middle ground between fully static site generation (where every page is pre-built once at deploy time and never changes until the next full rebuild) and server-side rendering (where every request triggers fresh rendering on the server). By allowing individual pages to be regenerated on a schedule or on-demand after the initial build, ISR lets a site serve mostly cached static content — with all the performance and cost benefits that implies — while still keeping content reasonably fresh without requiring a full site rebuild for every content change. This makes it particularly well suited to content-heavy sites with a large number of pages where full rebuilds would be slow or expensive, but where content does need to update periodically rather than remaining permanently static, such as e-commerce product pages or content sites with frequently updated articles.