Incremental Static Regeneration (ISR)
A rendering strategy that serves pre-built static pages while regenerating them in the background — static-site speed with content that stays fresh.
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
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.