ISR (Incremental Static Regeneration) in NextJS - Deep Dive

Overview - ISR (Incremental Static Regeneration)

What is it?

ISR stands for Incremental Static Regeneration. It is a feature in Next.js that lets you update static pages after you build your website, without rebuilding the whole site. This means pages can stay fast and static but also show fresh content. It works by regenerating pages in the background when users visit them.

Why it matters

Without ISR, websites with static pages would need a full rebuild to update content, which can be slow and costly. ISR solves this by allowing pages to update incrementally, keeping sites fast and scalable while showing up-to-date information. This improves user experience and reduces developer workload.

Where it fits

Before learning ISR, you should understand static site generation (SSG) and server-side rendering (SSR) in Next.js. After ISR, you can explore advanced caching strategies and serverless functions to further optimize dynamic content delivery.

Mental Model

Core Idea

ISR lets static pages refresh themselves quietly in the background so users always see fast pages with fresh content.

Think of it like...

Imagine a bakery that bakes a batch of cookies early in the morning (static pages). When a customer buys the last cookie, the bakery quietly bakes a new batch without closing the shop or making customers wait (ISR regenerates pages in the background).

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Build Static  │──────▶│ Serve Static  │──────▶│ User Visits   │
│ Pages (SSG)   │       │ Pages Fast    │       │ Page          │
└───────────────┘       └───────────────┘       └───────────────┘
                                   │
                                   ▼
                        ┌─────────────────────┐
                        │ Check Revalidate Time│
                        └─────────────────────┘
                                   │
                  ┌────────────────┬─────────────────┐
                  │                                │
                  ▼                                ▼
       ┌───────────────────┐           ┌─────────────────────┐
       │ Serve Cached Page │           │ Regenerate Page in   │
       │ Immediately       │           │ Background          │
       └───────────────────┘           └─────────────────────┘

Build-Up - 7 Steps

1

Foundation

Static Site Generation Basics

Concept: Learn what static site generation means and how Next.js builds pages ahead of time.

Static Site Generation (SSG) means creating HTML pages during build time, so they load very fast for users. Next.js runs your page code once when you build your app and saves the HTML. When users visit, they get this pre-built page instantly.

Result

Pages load very fast because they are ready-made and served as simple files.

Understanding SSG is key because ISR builds on this idea by updating these static pages after build time.

2

Foundation

Why Static Pages Need Updates

Concept: Static pages are fast but can become outdated if content changes after build.

Imagine a blog built with SSG. If you add a new post, the static pages won't show it until you rebuild the whole site. This delay can frustrate users and slow down content updates.

Result

Static pages can become stale and not reflect the latest content.

Knowing this problem sets the stage for why ISR is needed to keep static pages fresh.

3

Intermediate

How ISR Works in Next.js

🤔Before reading on: do you think ISR updates pages immediately on every request or in the background? Commit to your answer.

Concept: ISR lets Next.js regenerate static pages in the background after a set time, serving old pages instantly while updating quietly.

In Next.js, you add a 'revalidate' property to your page's data fetching function. This tells Next.js how many seconds to wait before regenerating the page. When a user visits after that time, Next.js serves the old page immediately and starts regenerating the new page in the background. The next visitor gets the fresh page.

Result

Users see fast pages always, and content updates happen without delays or downtime.

Understanding background regeneration explains how ISR balances speed and freshness without blocking users.

4

Intermediate

Implementing ISR with getStaticProps

🤔Before reading on: do you think ISR requires a new API or just changes to existing functions? Commit to your answer.

Concept: ISR is enabled by adding a 'revalidate' field in the existing getStaticProps function in Next.js pages.

In your page file, export an async function called getStaticProps. Return your data plus a 'revalidate' number in seconds. For example: export async function getStaticProps() { const data = await fetchData(); return { props: { data }, revalidate: 10, // regenerate page at most every 10 seconds }; } This tells Next.js to regenerate the page in the background if 10 seconds have passed since last build.

Result

Your static page updates automatically after the specified time without manual rebuilds.

Knowing ISR uses existing Next.js APIs makes it easy to adopt without learning new tools.

5

Intermediate

Handling User Experience During Regeneration

🤔Before reading on: do you think users see a loading screen during ISR regeneration? Commit to your answer.

Concept: ISR serves the old page instantly while regenerating the new page in the background, so users never wait.

When a user visits a page that needs regeneration, Next.js serves the cached static page immediately. Meanwhile, it triggers regeneration behind the scenes. The user sees no delay or loading state. The next visitor gets the updated page.

Result

Users always get a fast page load with no waiting, even during updates.

Understanding this behavior helps avoid confusion about page loading and ensures smooth user experience.

6

Advanced

ISR and On-Demand Revalidation

🤔Before reading on: do you think ISR can update pages instantly on demand or only after time intervals? Commit to your answer.

Concept: Next.js supports on-demand ISR to regenerate pages instantly via API calls, bypassing the timer.

Besides timed regeneration, Next.js lets you trigger page regeneration manually using API routes. You call a special API endpoint with the page path, and Next.js regenerates that page immediately. This is useful for content updates triggered by events like publishing a blog post.

Result

Pages can update instantly when needed, combining scheduled and event-driven updates.

Knowing on-demand ISR adds flexibility for real-time content updates beyond fixed intervals.

7

Expert

ISR Internals and Cache Management

🤔Before reading on: do you think ISR stores regenerated pages in memory or on disk? Commit to your answer.

Concept: ISR stores regenerated pages as static files on the server filesystem and manages cache invalidation based on revalidate timing.

When ISR regenerates a page, Next.js runs getStaticProps, creates new HTML and JSON files, and replaces the old static files atomically. This ensures no downtime or partial updates. The server tracks timestamps to decide when to regenerate. This file-based cache system scales well and works with CDN caching.

Result

ISR provides reliable, atomic updates to static pages with minimal overhead.

Understanding file-based regeneration and atomic swaps explains ISR's robustness and performance.

Under the Hood

ISR works by combining static generation with a background regeneration process. When a page is first built, Next.js generates static HTML and JSON files. After deployment, when a user visits a page past its revalidate time, Next.js serves the existing static files immediately and triggers a server-side regeneration. The regeneration runs getStaticProps again, writes new static files atomically, and updates the cache. This process is transparent to users and integrates with CDN caching layers.

Why designed this way?

ISR was designed to solve the tradeoff between static site speed and dynamic content freshness. Traditional static sites are fast but stale; server-rendered sites are fresh but slower. ISR blends both by regenerating pages incrementally and asynchronously, avoiding full rebuilds and downtime. The file-based cache and atomic updates ensure stability and scalability, fitting well with existing static hosting and CDN infrastructure.

┌───────────────┐
│ Initial Build │
│ Generates     │
│ Static Files  │
└──────┬────────┘
       │
       ▼
┌───────────────┐          ┌─────────────────────┐
│ User Requests │─────────▶│ Serve Cached Static  │
│ Page         │          │ HTML & JSON Files    │
└──────┬────────┘          └─────────┬───────────┘
       │                              │
       │                              ▼
       │                  ┌────────────────────────┐
       │                  │ Check Revalidate Timer │
       │                  └─────────┬──────────────┘
       │                            Yes│No
       │                               │
       │                               ▼
       │                  ┌────────────────────────┐
       │                  │ Trigger Background      │
       │                  │ Regeneration            │
       │                  └─────────┬──────────────┘
       │                            │
       │                            ▼
       │                  ┌────────────────────────┐
       │                  │ Run getStaticProps      │
       │                  │ Generate New Static     │
       │                  │ Files Atomically        │
       │                  └────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does ISR block users from seeing pages while regenerating? Commit yes or no.

Common Belief: ISR makes users wait for the page to regenerate before showing anything.

Reality: ISR serves the old static page immediately and regenerates the new page in the background without blocking users.

Why it matters: Believing this causes developers to avoid ISR fearing slow user experience, missing out on its speed benefits.

Quick: Does ISR rebuild the entire site when one page changes? Commit yes or no.

Common Belief: ISR rebuilds the whole site incrementally page by page.

Reality: ISR regenerates only the specific page requested, not the entire site.

Why it matters: Thinking ISR rebuilds everything leads to unnecessary complexity and wrong deployment strategies.

Quick: Can ISR be used without getStaticProps? Commit yes or no.

Common Belief: ISR works with any page, even those without getStaticProps.

Reality: ISR requires getStaticProps because it depends on static generation to regenerate pages.

Why it matters: Misunderstanding this causes confusion about how to implement ISR and why it doesn't work on dynamic-only pages.

Quick: Does ISR guarantee instant content updates on every change? Commit yes or no.

Common Belief: ISR updates pages instantly whenever content changes.

Reality: ISR updates pages after the revalidate interval or via on-demand revalidation, not instantly by default.

Why it matters: Expecting instant updates without on-demand revalidation can cause stale content to persist longer than expected.

Expert Zone

1

ISR regeneration is atomic, meaning new static files replace old ones only after successful generation, preventing partial updates or broken pages.

2

ISR works seamlessly with CDN caching, but cache invalidation strategies must align with ISR revalidation to avoid serving stale content.

3

On-demand ISR requires secure API routes to prevent unauthorized regeneration requests, which can cause performance issues or security risks.

When NOT to use

ISR is not suitable for highly personalized pages that change per user or require real-time data. For those, use server-side rendering (SSR) or client-side rendering (CSR) instead. Also, if your content updates extremely frequently (multiple times per second), ISR's revalidation intervals may not be fast enough.

Production Patterns

In production, ISR is often combined with headless CMS webhooks triggering on-demand revalidation to update pages instantly after content changes. Teams use ISR for blogs, marketing sites, and e-commerce product pages where content updates regularly but not every second. Monitoring regeneration times and cache hit ratios helps optimize performance.

Connections

Caching Strategies

ISR builds on caching principles by serving cached static pages and regenerating them based on time or events.

Understanding caching helps grasp how ISR balances speed and freshness by controlling when to update cached pages.

Event-Driven Architecture

On-demand ISR uses event triggers (like CMS webhooks) to regenerate pages immediately, similar to event-driven systems.

Knowing event-driven patterns clarifies how ISR can react instantly to content changes without polling or full rebuilds.

Supply Chain Inventory Replenishment

ISR's background regeneration is like restocking inventory only when needed, avoiding overproduction and shortages.

This connection shows how efficient resource management in supply chains parallels ISR's balance of freshness and performance.

Common Pitfalls

#1 Setting revalidate too low causing excessive regeneration.

Wrong approach:

export async function getStaticProps() {
const data = await fetchData();
return {
props: { data },
revalidate: 1, // regenerates every second
};
}

Correct approach:

export async function getStaticProps() {
const data = await fetchData();
return {
props: { data },
revalidate: 60, // regenerates every minute
};
}

Root cause:

Misunderstanding that very low revalidate values cause high server load and negate ISR's performance benefits.

#2 Using ISR on pages without getStaticProps.

Wrong approach:

export default function Page() {
return Hello;
}
// No getStaticProps, but expecting ISR to work

Correct approach:

export async function getStaticProps() {
return { props: {} , revalidate: 10 };
}
export default function Page() {
return Hello;
}

Root cause:

Not realizing ISR depends on static generation lifecycle provided by getStaticProps.

#3 Expecting users to see updated content immediately without on-demand revalidation.

Wrong approach:

export async function getStaticProps() {
const data = await fetchData();
return {
props: { data },
revalidate: 3600, // 1 hour
};
}
// Content changes but users see old page for up to an hour

Correct approach:

// Use on-demand revalidation API to update instantly when content changes
// alongside revalidate for fallback

Root cause:

Ignoring that revalidate sets max stale time and on-demand revalidation is needed for instant updates.

Key Takeaways

ISR lets static pages update themselves quietly in the background, combining speed with fresh content.

It works by setting a revalidate time in getStaticProps, telling Next.js when to regenerate pages.

Users always get fast page loads because ISR serves cached pages immediately during regeneration.

On-demand revalidation allows instant page updates triggered by external events like CMS changes.

ISR uses atomic file replacement and integrates with CDN caching for reliable and scalable updates.

Practice

1. What is the main purpose of Incremental Static Regeneration (ISR) in Next.js?

easy

A. To disable static generation completely

B. To generate pages only on the client side

C. To update static pages after build without rebuilding the entire site

D. To force server-side rendering on every request

Solution

1. Step 1: Understand ISR concept

   ISR allows static pages to be updated after the initial build without rebuilding the whole site.

2. Step 2: Compare options

   Options B, C, and D describe client-side rendering, disabling static generation, or forcing server-side rendering, which are not ISR features.

3. Final Answer:

   To update static pages after build without rebuilding the entire site -> Option C

4. Quick Check:

   ISR updates static pages incrementally = A [OK]

Hint: ISR updates static pages without full rebuilds [OK]

Common Mistakes:

• Confusing ISR with client-side rendering
• Thinking ISR disables static generation
• Believing ISR forces server-side rendering

2. Which Next.js function should you use to enable ISR by specifying a revalidation time?

easy

A. getServerSideProps

B. getStaticProps

C. getInitialProps

D. useEffect

Solution

1. Step 1: Identify ISR enabling function

   ISR is enabled by returning a revalidate property inside getStaticProps.

2. Step 2: Check other options

   getServerSideProps is for server-side rendering, getInitialProps is legacy, and useEffect is a React hook for client-side effects.

3. Final Answer:

   getStaticProps -> Option B

4. Quick Check:

   ISR uses getStaticProps with revalidate = D [OK]

Hint: Use getStaticProps with revalidate for ISR [OK]

Common Mistakes:

• Using getServerSideProps instead of getStaticProps
• Confusing client-side hooks with data fetching
• Using deprecated getInitialProps for ISR

3. Given this code snippet, what will be the behavior of the page?

export async function getStaticProps() {
  return {
    props: { time: Date.now() },
    revalidate: 10,
  };
}

medium

A. The page throws a syntax error

B. The page never updates after build

C. The page updates on every request

D. The page updates every 10 seconds with new time

Solution

1. Step 1: Analyze revalidate property

   The revalidate: 10 means Next.js will regenerate the page at most every 10 seconds.

2. Step 2: Understand page update behavior

   The page will serve the static content initially, then update the static page in the background every 10 seconds.

3. Final Answer:

   The page updates every 10 seconds with new time -> Option D

4. Quick Check:

   revalidate 10 means update every 10 seconds = A [OK]

Hint: revalidate sets update interval in seconds [OK]

Common Mistakes:

• Thinking page never updates after build
• Confusing ISR with server-side rendering
• Assuming syntax error due to revalidate

4. Identify the error in this ISR setup:

export async function getStaticProps() {
  return {
    props: { data: 'Hello' },
    revalidate: '60',
  };
}

medium

A. revalidate must be a number, not a string

B. props must be a function, not an object

C. getStaticProps cannot be async

D. Missing fallback property

Solution

1. Step 1: Check revalidate type

   The revalidate property must be a number representing seconds, not a string.

2. Step 2: Verify other parts

   props is correctly an object, getStaticProps can be async, and fallback is unrelated here.

3. Final Answer:

   revalidate must be a number, not a string -> Option A

4. Quick Check:

   revalidate type must be number = C [OK]

Hint: revalidate must be numeric seconds, not string [OK]

Common Mistakes:

• Passing revalidate as string instead of number
• Thinking getStaticProps can't be async
• Confusing fallback with revalidate

5. You want a blog page to update its static content every 5 minutes but also show a fallback loading page on first visit to new posts. Which ISR setup is correct?

hard

A. Use getStaticProps with revalidate: 300 and fallback: 'blocking' in getStaticPaths

B. Use getServerSideProps with revalidate: 300

C. Use getStaticProps with revalidate: '300' and no fallback

D. Use getStaticPaths with fallback: false and no revalidate

Solution

1. Step 1: Understand ISR with fallback

   To update static pages every 5 minutes (300 seconds) and show fallback loading for new pages, use revalidate: 300 in getStaticProps and fallback: 'blocking' in getStaticPaths.

2. Step 2: Check other options

   Use getServerSideProps with revalidate: 300 uses server-side rendering, not ISR. Use getStaticProps with revalidate: '300' and no fallback has revalidate as string and no fallback. Use getStaticPaths with fallback: false and no revalidate disables fallback and revalidate, so no ISR updates or loading fallback.

3. Final Answer:

   Use getStaticProps with revalidate: 300 and fallback: 'blocking' in getStaticPaths -> Option A

4. Quick Check:

   ISR with fallback blocking and revalidate 300 = B [OK]

Hint: Combine revalidate with fallback: 'blocking' for ISR + loading [OK]

Common Mistakes:

• Using server-side rendering instead of ISR
• Passing revalidate as string
• Setting fallback to false disables loading fallback