Incremental Static Regeneration (ISR)
Term 18 of 68 in the ERPStack technical glossary
What is Incremental Static Regeneration (ISR)?
Incremental Static Regeneration (ISR) is a Next.js rendering pattern that allows developers to update static pages in the background after site deployment without rebuilding the entire website.
Incremental Static Regeneration (ISR) at a glance
- What it solves
- Static speed with fresh data, without rebuilding 10,000 pages to change 1
- Mechanism
- Serve the cached page, regenerate in the background, replace it for the next request
- Invalidation
- Cache tags, so publishing 1 record revalidates the 2 or 3 routes that show it
- Framework
- Next.js 16 with React 19, the versions this site itself runs on
- Built with
- Next.js 16 and React 19 with cache tags and Tailwind CSS 4, content from Payload CMS on PostgreSQL 18 via Drizzle ORM 0.45, built by GitHub Actions in TypeScript 5.9, served from Vercel or AWS, errors in Sentry
- Numbers that matter
- 1 route regenerated instead of 10,000 rebuilt; 0 users waiting for regeneration; seconds of staleness; 2 or 3 routes touched per publish
- Compare with
- Full static generation, server rendering every request, client-side fetching in React 19 against a REST API, or Redis-cached HTML behind Docker
- Commonly paired with
- Payload CMS on PostgreSQL 18, a Headless CMS content model, Edge Caching / CDN on Vercel, Redis at the origin, Next.js 16 and React 19 rendering, Tailwind CSS 4 styling and Sentry monitoring
- Cache-tag design
- 1 tag per record plus 1 per index route; publishing 1 article revalidates 2 or 3 routes rather than all 10,000
- Caching layers around it
- Edge Caching / CDN on Vercel in front, Redis at the origin, Payload CMS content in PostgreSQL 18 behind, and Next.js 16 cache tags tying the 3 together.
How Incremental Static Regeneration (ISR) works in production
The ERPStack approach to Incremental Static Regeneration (ISR)
We implement on-demand ISR across all ERPStack programmatic pages. When a case study or term changes in the database, our webhook invalidates the page cache in under 300ms.
Frequently asked questions about Incremental Static Regeneration (ISR)
What problem does Incremental Static Regeneration solve?
The choice between fast and fresh. Fully static generation is quick to serve but requires rebuilding the site to change anything, which becomes impractical past a few thousand pages. Server rendering is always current but pays the cost on every request. Static Regeneration serves a cached page instantly and regenerates it in the background, so readers get static performance and editors get near-immediate updates.
How is ISR different from ordinary caching?
It regenerates rather than merely expiring. A conventional cache discards a stale entry, so the unlucky next visitor waits for a full render. Static Regeneration serves the existing page and rebuilds behind it, meaning no user pays the regeneration cost. Combined with cache tags, an editor's publish action can revalidate exactly the affected routes rather than waiting for a timer.
When should you not use ISR?
When the response is personal. Static Regeneration produces 1 shared page for everyone, so anything varying by user — a dashboard, a cart, tenant-scoped data — must be rendered per request or fetched on the client. Attempting to cache personalised output at this layer is how one customer ends up seeing another's information, which is a far worse outcome than a slower page.
How does ISR interact with a headless CMS?
It is the mechanism that makes the pairing work. A Headless CMS holds the content and Static Regeneration decides when the rendered page updates: publishing triggers revalidation of the affected routes, and everything else stays cached. Without it, a content-driven site either rebuilds entirely on every edit or renders every request from the database, and neither scales comfortably.