Incremental static regeneration, usually shortened to ISR, lets individual pages on a statically generated site rebuild after the initial deploy, without rebuilding the entire site. A page generates once at build time like any static page, keeps serving instantly from cache, and then regenerates in the background — either after a set amount of time or when triggered by a content update — so visitors eventually see fresh content without ever waiting on a rebuild themselves.
What changed in 2026
- On-demand revalidation became the default pattern, replacing pure time-based windows: a webhook from a headless CMS triggers regeneration the moment content is published, rather than waiting for a timer to expire.
- Per-path granularity improved. Frameworks now regenerate only the specific pages affected by a data change, instead of a broader group of pages sharing one revalidation setting.
- ISR spread beyond its original framework. What started as a single-framework feature is now a common pattern across several meta-frameworks and edge platforms, under different names but the same core idea.
- Stale-while-revalidate caching at the CDN layer converged with ISR, so the concept now shows up at the HTTP caching layer too, not just inside a specific framework.
How it actually works
- The page builds once, like any statically generated page, and is cached.
- A visitor requests the page and gets the cached version instantly — no wait, no rebuild happening in front of them.
- A revalidation window passes, or a webhook fires after a content update.
- The page regenerates in the background using fresh data.
- The cache swaps to the new version for the next visitor. Nobody sees a loading state or a delay caused by the rebuild.
This is the key detail people miss: no single visitor ever waits on a regeneration. They get either the current cached page or, immediately after a background regeneration finishes, the new one.
Why this exists at all
Pure static generation has one real weakness: content freshness. If your data changes and you have not rebuilt, visitors see stale content until the next full build runs. For a small blog that publishes weekly, that is a non-issue. For a product catalog with prices, an inventory count, or frequently edited pages, waiting for a full rebuild is not workable. ISR closes that gap without giving up the CDN-served, no-server-per-request model that makes static generation fast and cheap.
ISR compared with the alternatives
| Approach |
Freshness |
Server cost per visit |
| Pure static generation |
Only as fresh as the last full build |
None — pure file serving |
| Incremental static regeneration |
Refreshes per page, on schedule or on demand |
Near zero; regeneration happens occasionally, in the background |
| Server-side rendering |
Always current |
A render happens on every single request |
| Client-side fetching on a static shell |
Current at load time |
None server-side; cost shifts to the client and the API |
When to reach for it
ISR is the right tool when content changes regularly but not on every request, and when a short window of staleness — seconds to minutes, depending on configuration — is acceptable. It is the wrong tool for anything that must be correct in real time for every single visitor, such as account balances or live auction prices; that belongs in server-side rendering instead.
FAQ
Does ISR require a full server running at all times?
It requires a platform that can trigger and serve regenerated pages on demand, which is more than pure static hosting but far less than running a full application server for every request.
Is ISR the same as caching?
Related but not identical. Caching serves the same response until it is evicted. ISR specifically regenerates the underlying page from fresh data and replaces the cached version, rather than just expiring it.
Can every page on a site use ISR?
Technically yes, but it makes the most sense for pages that change periodically. Pages that never change are better as plain static generation; pages that must be live on every request need server-side rendering.
What triggers a regeneration in practice?
Either a time-based revalidation window you configure, or an on-demand trigger — commonly a webhook from a CMS firing the moment an editor publishes a change.
Where to go next