CONCEPT Cited by 3 sources
Incremental Static Regeneration¶
Definition¶
Incremental Static Regeneration (ISR) is a caching strategy — popularised by Next.js — in which a page is:
- Rendered on first request (or at deploy time).
- Cached with an explicit revalidation window.
- Served from cache to subsequent requests within the window.
- Re-rendered in the background when the window expires or an explicit revalidation is triggered.
Trades off freshness vs. render cost: ISR pays the render cost once per revalidation window, not once per request.
ISR in vinext¶
vinext supports ISR out of the box via the
KVCacheHandler plugged
into Next.js's setCacheHandler() API:
"After the first request to any page, it's cached and revalidated in the background, just like Next.js. That part works today."
Complementary to vinext's Traffic-aware Pre-Rendering: TPR pre-renders the high-traffic head at deploy time; ISR fills in the long tail on first request.
Cache substrate choice¶
vinext's cache layer is pluggable per patterns/pluggable-cache-handler:
- KV — good default for most apps.
- R2 — better for large cached payloads.
- Cloudflare Cache API — forthcoming, lower-config option.
Seen in¶
- sources/2026-02-24-cloudflare-how-we-rebuilt-nextjs-with-ai-in-one-week — ISR is vinext's primary caching primitive; paired with TPR for coverage across the power-law traffic distribution.
- sources/2024-08-01-vercel-how-google-handles-javascript-throughout-the-indexing-process
— ISR pages index correctly in Google. On
nextjs.org(which uses a mix of SSG / ISR / SSR / CSR), 100 % of indexable HTML pages render in the WRS. ISR's "serve cached HTML on hit; render-on-demand server-side on miss" pattern means Googlebot always sees a server-rendered HTML body — no SEO penalty relative to pure SSG. Extends concepts/rendering-strategy-crawl-efficiency-tradeoff with ISR's "Excellent" grade on crawl efficiency / rendering completeness / rendering time. - sources/2026-04-21-vercel-preventing-the-stampede-request-collapsing-in-the-vercel-cdn — canonical ISR cache-stampede failure mode and fix. ISR's revalidate-on-miss mechanic creates a concurrent-miss window at every TTL expiry on popular routes; "dozens of simultaneous invocations, all regenerating the same page" without coordination. Vercel's CDN now collapses these misses via a two-level (node + regional) lock + double- checked locking + [[concepts/lock-timeout-hedging|3 s lock timeout]], yielding one invocation per region. Production numbers: 3M+ collapsed requests/day on cache miss + 90M+/day on background revalidation; 100 % of Vercel ISR projects auto-enrolled via patterns/framework-inferred-cache-policy. Extends ISR's cost model: ISR pays regeneration cost once per TTL window per region, not once per request — but only because request collapsing enforces this. See systems/vercel-cdn for the full system.
Related¶
- concepts/traffic-aware-prerendering — the pre-render- at-deploy-time complement to ISR's render-on-first-request.
- concepts/build-time-scales-with-page-count — the pathology ISR partially addresses by deferring rendering until needed.
- concepts/cache-stampede — ISR's native failure mode at popular-key TTL expiry.
- concepts/request-collapsing — Vercel's structural fix for ISR cache stampedes at the CDN altitude.
- concepts/thundering-herd — the broader failure class.
- systems/vercel-cdn — the CDN that implements collapsing for every Vercel ISR project.
- patterns/framework-inferred-cache-policy — how the CDN learns which routes are ISR-cacheable without user config.
- systems/nextjs — original home of ISR.
- systems/vinext — the production consumer.
- systems/vinext-kv-cache-handler — the default implementation.
- patterns/pluggable-cache-handler — the pluggability pattern.