Incremental Static Regeneration (ISR)

ISR allows developers to update individual static pages without triggering a full site rebuild. When a request arrives for a page that has exceeded its revalidate window, the framework serves the stale cached version instantly while triggering a background regeneration. The newly generated page replaces the stale cache for all subsequent requests. This granularity is critical for large-scale content sites where rebuilding millions of pages is computationally prohibitive.

The primary control mechanism for ISR is the revalidate property, which defines a time-to-live (TTL) in seconds for a cached page. Once this duration elapses, the next incoming request triggers a regeneration. This model is ideal for content that changes predictably, such as:

• Product inventory pages updated every 60 seconds
• Blog posts revalidated every hour
• Marketing landing pages refreshed daily

Beyond time-based triggers, ISR supports event-driven cache purging via an API endpoint. When a headless CMS updates a record, a webhook can call a specific revalidation route, instantly marking the associated page as stale. This bypasses the revalidate timer entirely, ensuring that critical content changes—like a price correction or breaking news update—propagate to the static cache immediately without waiting for the TTL to expire.

ISR implements a stale-while-revalidate caching pattern. Users never see a build process or a loading spinner. The framework always serves a cached HTML file first, even if it is technically expired. The regeneration happens in the background. This guarantees zero downtime and consistent Time to First Byte (TTFB) regardless of traffic spikes, decoupling the user experience from the build duration.

For dynamic routes with millions of potential paths, pre-rendering all of them is impossible. ISR uses a fallback key to handle requests for paths not yet generated:

• fallback: blocking: The server renders the page on the first request and caches it. The user waits for the server response.
• fallback: true: The server immediately serves a lightweight loading shell, renders the page in the background, and streams the result to the client.

Once regenerated, ISR pages are typically persisted to a globally distributed edge cache. This means the freshly built static file is not just stored on the origin server but pushed to Points of Presence (PoPs) worldwide. Subsequent users requesting that page from any geographic region receive the updated static asset with near-zero latency, combining the freshness of dynamic rendering with the global performance of a CDN.

The foundational rendering strategy where all HTML pages are pre-built at compile time and served as immutable assets from a CDN. Unlike ISR, SSG requires a full site rebuild to update any content, making it ideal for purely static content but inefficient for frequently changing data. SSG provides the absolute lowest Time to First Byte (TTFB) but lacks the dynamic freshness that ISR introduces through on-demand revalidation.

A rendering strategy where HTML is generated dynamically on each request by the server before being sent to the client. SSR guarantees absolute data freshness but introduces compute latency on every page load. ISR bridges the gap between SSG and SSR by caching the rendered output and only regenerating when a revalidation threshold expires or an event triggers an on-demand update.

A programmatic trigger that forces ISR to immediately regenerate a specific page or set of pages without waiting for the time-based revalidation interval to expire. This is typically invoked via a webhook or API route when a headless CMS updates content. On-demand revalidation eliminates the staleness window inherent in time-based ISR, ensuring critical content updates propagate instantly while preserving the performance benefits of static caching.

The underlying storage layer that enables ISR to function across serverless and edge deployments where local filesystems are ephemeral. Instead of writing regenerated HTML to disk, ISR writes to a globally accessible key-value store like Amazon S3 or Redis. This ensures that subsequent requests to any compute instance receive the updated cached page, maintaining consistency across a horizontally scaled infrastructure without shared file mounts.