We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Web & Content Delivery
Incremental Static Regeneration: a Next.js feature that re-generates static pages in the background after a specified time interval, combining SSG speed with fresh data.
In short
Incremental Static Regeneration (ISR) is a Next.js rendering strategy that serves a pre-built static HTML page instantly, then rebuilds that page in the background on a schedule or on demand so the cached version stays fresh without a full site redeploy. It gives you the speed of static pages with data that updates over time.
In short
Incremental Static Regeneration (ISR) is a Next.js rendering strategy that serves a pre-built static HTML page instantly, then rebuilds that page in the background on a schedule or on demand so the cached version stays fresh without a full site redeploy. It gives you the speed of static pages with data that updates over time.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers ISR across a run of lessons, not one page. These 3 alone are about 54 minutes of step-by-step reading, every one with a quiz.
Updating static pages after build time without rebuilding the entire site, the best of SSG and SSR combined.
Pre-building HTML pages at build time, the fastest possible delivery for content that does not change per request.
Keep the business running during disruptions, beyond IT into organizational resilience.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Incremental Static Regeneration (ISR)pay once,
yours for life
Static Site Generation (SSG) builds every page once at deploy time. That is fast for visitors because the CDN serves plain HTML, but the page is frozen until the next build. If you have 754 pages and one fact changes, you either rebuild all 754 or live with stale content.
ISR fixes that. You mark a page with a revalidation time, for example one hour. The first visitor after that hour still gets the old cached page immediately, and Next.js quietly regenerates a fresh copy in the background. The next visitor gets the new one. This pattern is called stale-while-revalidate: serve stale, refresh behind the scenes.
The key idea is that no visitor ever waits for a rebuild. Pages are produced lazily, one at a time, instead of all at once during deployment. A page that nobody visits never gets regenerated, which keeps compute cheap.
In the Next.js App Router you set export const revalidate = 3600 in a page or route segment, where the number is seconds. The framework caches the rendered output (the HTML plus the React Server Component payload and any fetch results) on the server and at the edge.
When a request arrives after the revalidate window has passed, Next.js returns the cached page and triggers a regeneration job. That job re-runs the server component, re-fetches data, and atomically swaps the cache entry. If regeneration fails, the old page keeps serving, so a broken data source does not take the page down.
Beyond time-based revalidation, Next.js supports on-demand revalidation. You call revalidatePath('/lessons/latency') or revalidateTag('courses') from a server action or webhook, and only the affected pages are invalidated. This is how a CMS publish button or a Stripe webhook can refresh exactly the pages that changed within seconds, with no redeploy.
ISR fits content that is read far more often than it is written and where minutes of staleness are acceptable: documentation, course lessons, product catalogs, blog posts, marketing pages. For a learning platform with hundreds of lesson pages, ISR means each page renders once on first visit and then serves from cache for everyone else.
Avoid ISR for content that must be correct to the millisecond, like a stock trading balance or a live auction price. Those want full server rendering or client fetching. Also avoid it for pages that are unique per user, since a shared cache cannot hold per-user state.
The main trade-offs: a visitor can see data that is up to one revalidation window old, and the first request after a deploy or after a cold page may be slightly slower while the initial render happens. On-demand revalidation removes most of the staleness concern but requires you to wire up the triggers correctly.
Imagine an e-commerce category page listing 200 products with prices. Pure SSG would freeze the prices until the next deploy. Pure SSR would hit the database on every single request, which is slow and expensive under traffic spikes.
With ISR you set revalidate to 60 seconds. A flash sale starts and 50,000 shoppers hit the page in a minute. They all get the same cached HTML from the CDN, so the database sees roughly one regeneration per minute instead of 50,000 queries. Prices are at most 60 seconds stale, which is fine for a catalog.
When an admin changes a price, the system fires revalidateTag('products') from the update handler, and the category page plus the affected product page refresh within a second rather than waiting out the 60 second window.
Vercel / Next.js
Vercel created ISR and runs it natively on its edge network; it powers static-plus-fresh pages for sites like the Next.js docs themselves.
Notion (public pages)
Notion-style published sites and many headless-CMS frontends regenerate pages on a revalidation timer so editors do not trigger a full rebuild on every edit.
HashiCorp (developer.hashicorp.com)
Serves large documentation sets as static pages that revalidate, keeping hundreds of docs pages fast without rebuilding the entire site per change.
systemdesign.academy
Renders all 754 lesson pages with ISR, so each lesson is built on first visit, cached at the edge, and refreshed on demand when content is republished.
SSG builds every page once at deploy time and the output stays frozen until the next build. ISR also serves pre-built static pages, but it regenerates them in the background after a set interval or on demand, so content stays fresh without a full redeploy.
No. ISR uses stale-while-revalidate: the visitor that triggers a refresh still gets the existing cached page instantly, and the new version is generated in the background and served to the next visitor.
Instead of waiting for a time interval, you call revalidatePath or revalidateTag from a server action or webhook to invalidate specific pages immediately. It is how a CMS publish or a payment webhook refreshes exactly the affected pages in about a second.
Avoid it for data that must be exact in real time, such as account balances or live auction bids, and for pages that are personalized per user, since the cache is shared across all visitors. Use server rendering or client fetching instead.
Add export const revalidate = N to a page or route segment, where N is the number of seconds before the cached page becomes eligible for background regeneration. Setting it to false disables revalidation and keeps the page fully static.
Static Site Generation (SSG)
Pre-rendering pages to static HTML at build time. The fastest possible page loads because there's no server-side computation on each request.
SSR
Server-Side Rendering: generating HTML on the server for each request. Slower than SSG but always returns fresh data. Good for personalized or frequently changing pages.
CDN
A network of servers distributed globally that caches content close to users. Netflix uses CDNs to stream video from servers near you, not from one central location.
Content Delivery
The process of distributing and serving content to users from locations geographically close to them for faster load times.
Edge Computing
Running computation at the network edge, close to the user, instead of in a central data center. Reduces latency for real-time applications like IoT and streaming.
HTTP Caching
Browser and proxy caching controlled by HTTP headers like Cache-Control, ETag, and Last-Modified. Eliminates redundant network requests for unchanged resources.
This page explains the idea. The "Incremental Static Regeneration (ISR)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Incremental Static Regeneration (ISR) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about ISR in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
