ISR (Incremental Static Regeneration)

ISR is the Next.js / Jamstack pattern where pages are statically generated but periodically (or on-demand) re-rendered + cached — combines SSG speed with SSR freshness without full rebuild.

Pure SSG (static site generation) is fastest but stale — change a CMS entry, the site stays stale until next build. Pure SSR (server rendering) is fresh but slow — every request hits the server. ISR splits the difference: pages are static-rendered to a CDN, but re-render on a schedule (revalidate every N seconds) or on-demand (webhook from CMS → revalidate this URL). Result: stale-while-revalidate UX — users get fast cached HTML, the cache refreshes in background. Implementations: Next.js (`revalidate: 60`, `revalidatePath()`), Astro (incremental builds + on-demand rendering), Gatsby Cloud (incremental builds). Production wins: SEO-friendly + fast + can update without full deploy. Production losses: cache invalidation can lag, complex routing edge cases.

When to use isr (incremental static regeneration)

• Content-heavy sites with CMS-backed updates.
• E-commerce listings that don't need second-by-second freshness.

Common mistakes

• Setting `revalidate` to seconds when minutes would do — wastes compute.
• Forgetting on-demand revalidation hooks — content updates lag behind CMS.

FAQ

Related terms

• Edge runtime — An edge runtime is the lightweight JS / Wasm runtime (V8 isolates, Workerd, Deno, Bun) running app code at network edge POPs — Vercel Edge, Cloudflare Workers, Netlify Edge, Deno Deploy are 2026 leaders.
• Edge function — An edge function is a small serverless function that runs at the network edge — geographically close to the user — typically on Cloudflare Workers, Deno Deploy, Vercel Edge, or AWS Lambda@Edge.

Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/isr.md.