Incremental Static Regeneration (ISR)

ISR enables granular control over static content freshness. Instead of triggering a full site rebuild when data changes, developers specify a time-to-live (TTL) for each page. When a request arrives after the TTL expires, the page is regenerated in the background while the stale (cached) version is served immediately. The next request receives the freshly generated page. This mechanism relies on surrogate keys and CDN edge caching to purge specific pages without affecting the rest of the site.

ISR implements the stale-while-revalidate caching pattern at the page level. The key behaviors are:

• First request after expiry: The user receives the stale, cached HTML instantly (zero latency).
• Background regeneration: The server asynchronously rebuilds the page with fresh data.
• Cache update: The newly generated page replaces the stale version in the CDN cache.
• Subsequent requests: All future visitors receive the updated page. This ensures users never experience build delays or cold-start latency.

Beyond time-based TTLs, ISR supports event-driven revalidation via API endpoints. When a headless CMS or database triggers a webhook (e.g., after a content update), the application can programmatically invalidate and regenerate a specific page. This bypasses the TTL timer entirely, ensuring that critical content changes—such as product prices or breaking news—propagate to the CDN in under a second without waiting for the next scheduled rebuild.

For pages with dynamic routes (e.g., /products/[slug]), ISR provides fallback modes to handle paths not generated at build time:

• fallback: 'blocking': The server renders the page on the first request and caches it. The user waits for the initial render but all subsequent requests are served from cache.
• fallback: true: A loading state is served immediately while the page is generated in the background. Once ready, the cached version is served. This enables sites with millions of product pages to scale without pre-rendering every possible path.

ISR integrates directly with edge caching infrastructure. Regenerated pages are pushed to the CDN's edge nodes, ensuring that the updated content is geographically distributed close to users. The cache operates on surrogate key groups, allowing developers to purge related pages (e.g., all pages referencing a specific product category) with a single API call. This edge-native design eliminates origin server bottlenecks during traffic spikes while maintaining sub-50ms Time to First Byte (TTFB).

The core value proposition of ISR is build-time decoupling. In traditional Static Site Generation (SSG), a single content change requires a full site rebuild—a process that can take hours for large sites. ISR eliminates this bottleneck by:

• Treating each page as an independent build unit
• Only regenerating pages that receive traffic (lazy regeneration)
• Preserving build output for unchanged pages This reduces deployment times from hours to milliseconds, enabling continuous content updates without CI/CD pipeline overhead.