How it works
A page is generated once and cached like a static file. With a revalidate time of, say, 60 seconds, the first visitor after that minute still gets the cached page instantly while the server rebuilds it in the background, and the next visitor sees the fresh version. On-demand revalidation lets a CMS or a webhook refresh one page the moment its content changes.
Next.js introduced the term, and similar features exist in Nuxt route rules, SvelteKit on Vercel and plain CDN cache headers (stale-while-revalidate). Pages not built ahead of time can be generated on their first request. It needs a host that supports it: Vercel and Netlify handle it automatically, while self-hosting on several servers needs a shared cache.
Incremental static regeneration (ISR) pros and cons
Pros
- Static speed with content that stays reasonably fresh
- No full rebuild when one page changes
- Handles huge catalogues by building pages on first request
Cons
- Some visitors see slightly out-of-date content
- Caching behaviour is harder to reason about and debug
- Needs host support, and self-hosting takes extra setup
When to use Incremental static regeneration (ISR)
Pick it when
- Large stores, listings and news sites
- CMS-driven sites where editors publish often
Skip it when
- Data must be exact and live for every visitor (use SSR)
- A small site, where a quick full rebuild is simpler
Incremental static regeneration (ISR) vs the alternatives
Related terms
More in Rendering and architecture
Where pages are built