Incremental Static Regeneration (ISR)

🔍 What Is It?

Incremental Static Regeneration (ISR) is a hybrid between SSG and SSR:

• →Pages are pre-built as static HTML (like SSG) — fast CDN delivery
• →After a revalidation period, the next request triggers a background rebuild
• →The stale page is served while the fresh page is being built (stale-while-revalidate)
• →Once rebuilt, the fresh page replaces the stale one for subsequent requests

Two types of ISR:

1. Time-based — revalidate every N seconds (next: { revalidate: 3600 })
2. On-demand — trigger revalidation via revalidatePath() or revalidateTag() from a webhook

🎯 Why Do We Need It?

SSG is fast but stale. SSR is fresh but slow. ISR gives you both:

• →Static performance — CDN-served HTML, no server per request
• →Dynamic freshness — pages update automatically, no full rebuild needed
• →Scalable — only the changed pages rebuild, not the entire site
• →On-demand — CMS publish triggers immediate page update, not a full deploy

Without ISR, a 10,000-page product catalog would need either:

• →A full rebuild on every product change (slow CI/CD), or
• →SSR for every request (expensive at scale)

🏗️ What Happens in Real Projects?

ISR patterns in production:

• →Product pages — revalidate: 3600 (hourly) for prices and stock
• →Blog posts — on-demand revalidation from CMS publish webhook
• →News articles — revalidate: 300 (5 min) for breaking news sections
• →Homepage — on-demand revalidation when featured content changes
• →Documentation — on-demand revalidation on Git push

Real example: An e-commerce site with 200,000 products uses ISR with revalidate: 3600. When a product price changes, a webhook calls revalidatePath('/products/[slug]') for just that product — no full rebuild needed.

⚙️ How It Works

Time-based ISR flow:

1. Build time: page is pre-rendered as static HTML
2. Request 1 (within revalidation window): CDN serves cached HTML instantly
3. Revalidation window expires (e.g., 60 seconds)
4. Request 2 (after window): CDN serves stale HTML AND triggers background rebuild
5. Background rebuild: Next.js re-runs the Server Component, fetches fresh data
6. Request 3+: CDN serves the newly built HTML

On-demand ISR flow:

1. CMS editor publishes a new blog post
2. CMS sends a webhook to /api/revalidate?tag=blog
3. Route Handler calls revalidateTag('blog')
4. Next.js invalidates all pages tagged with 'blog'
5. Next request to any blog page triggers a fresh rebuild

💻 Example

Time-based and On-demand ISR — Both ISR patterns used together in a content-heavy application.

// app/products/[slug]/page.tsx
export default async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await fetch(
    `https://api.example.com/products/${params.slug}`,
    {
      next: {
        revalidate: 3600, // Revalidate every hour
        tags: ['products', `product-${params.slug}`], // Tag for on-demand revalidation
      },
    }
  ).then((r) => r.json());

  return (
    <div>
      <h1>{product.name}</h1>
      <p className="price">£{product.price}</p>
    </div>
  );
}

// Route is static at build time, revalidated every hour

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits