Glossary term
Incremental Static Regeneration (ISR)
Incremental Static Regeneration (ISR) rebuilds individual static pages after deployment on a schedule, combining static speed with fresh data.
What Incremental Static Regeneration (ISR) means
Incremental Static Regeneration, abbreviated ISR, is a rendering strategy that lets a website serve pre-rendered static pages while still updating them with fresh data after the site has been deployed — without rebuilding the entire site. It is the bridge between pure Static Site Generation, which is fast but frozen at build time, and server-side rendering on demand, which is always fresh but pays a rendering cost on every request. ISR keeps the speed and cacheability of static pages while adding bounded, automatic freshness.
The mechanism revolves around a revalidation window. A page is generated statically and served from cache exactly like an ordinary static page, but it carries a time-to-live: after a configured interval has elapsed, the next request triggers the framework to regenerate that page in the background. Crucially, the user who triggers the regeneration is usually still served the existing cached page immediately; the freshly built version replaces it for subsequent visitors once it is ready. This stale-while-revalidate behavior means visitors almost never wait for a rebuild, yet the content never drifts further out of date than the revalidation window allows.
The problem ISR solves is the rebuild bottleneck of large or data-driven sites. If a site has many thousands of pages whose underlying data changes periodically, regenerating every page on every change — the pure-static approach — becomes slow and wasteful, while rendering each page fresh on every request — the fully-dynamic approach — wastes work re-rendering pages that did not change between requests. ISR regenerates only the pages that are actually requested, and only after their window expires, so the cost scales with traffic and staleness tolerance rather than with the total page count. A page nobody visits is never needlessly rebuilt; a popular page stays fresh within its window at the cost of an occasional background regeneration.
Choosing the revalidation window is the central design decision, and it is a trade-off between freshness and load. A short window keeps data current but triggers more frequent regenerations and more upstream data fetches; a long window reduces that load but tolerates more staleness. The right value depends on how quickly the underlying data changes and how stale the page can acceptably be. Reference content that updates a few times a day can tolerate a window of hours; data that shifts by the minute belongs to a different strategy entirely.
ISR also interacts carefully with content that genuinely must be live or per-request. Truly real-time data — a value that must be exactly correct at the instant of the request — is a poor fit for any cached strategy, because caching by definition admits some staleness. For those cases, a fully dynamic render or a separate client-side fetch is more appropriate, and modern frameworks let a developer mix ISR pages with dynamic ones in the same application, picking the mode per route. There are also subtleties around how regeneration is isolated so that one stale page does not block the rendering of others, and around the interplay between ISR and the loading states a page shows while data is being fetched.
Whisper Canon uses incremental regeneration for entity pages whose facts come from the live infrastructure graph and change over time but do not need to be exact-to-the-second. An ASN page, a hostname page, or a prefix page is rendered statically for speed and revalidated on a window so that the routing, DNS, and registration facts it shows stay reasonably current as the underlying graph updates — without the cost of rendering every page on every request or rebuilding the whole directory whenever the graph changes. Content that is intrinsically static, such as this glossary, is generated fully statically instead, and content that must be precomputed for performance is handled by background jobs rather than at render time. ISR is the middle path: static delivery with a freshness guarantee, chosen precisely when data evolves but a few minutes or hours of staleness is acceptable.
Examples in Whisper Canon
Concrete pages in the directory that illustrate Incremental Static Regeneration (ISR).