Next.js ISR (Incremental Static Regeneration) in 2026: App Router + Pages Router Guide

What is Incremental Static Regeneration (ISR) in Next.js?

• Incremental Static Regeneration is a Next.js rendering and caching model rooted in the Jamstack approach, where pages are served statically and regenerated in the background when content becomes stale.

• Use ISR when performance, SEO, and controlled content freshness matter, and when you want to avoid full rebuilds. It builds on core Next.js benefits such as static delivery, scalable caching, and predictable rendering for content-driven and ecommerce platforms.

When Should You Use ISR vs SSG vs SSR in Next.js?

Static Site Generation (SSG)

Pages are generated at build time and served as static assets. Updates require a full rebuild and redeploy. Best suited for content that rarely changes.

Server-Side Rendering (SSR)

Pages are rendered on every request. Content is always fresh but response times and infrastructure costs are higher. Used for highly dynamic or personalized pages.

Incremental Static Regeneration (ISR)

Pages are served from cache as static files and regenerated in the background when stale. Updates do not require rebuilding the entire application. Suitable for content that changes regularly but does not require per-request rendering.

How Does Next.js ISR Work Step by Step?

Incremental Static Regeneration follows a stale-while-revalidate flow: Next.js serves cached content first, then regenerates in the background when the cache is stale. 

1. A page is generated and cached

The first version is produced during build or on first request, depending on the route and data strategy, and then stored as the cached response.

2. Requests are served from cache

Users get the cached HTML immediately, with static delivery characteristics.

3. The cache becomes stale

Staleness is triggered by either:

• a time-based revalidation interval, or

• an on-demand invalidation signal (path or tag).

4. The next request receives the stale cached response

Next.js continues to serve the cached version to keep latency stable.

5. Regeneration starts in the background

In parallel, Next.js regenerates the page or the cached data and prepares an updated version without blocking the user response.

6. Cache is updated and subsequent requests get the new version 

Once regeneration succeeds, the cache is updated and future requests receive the refreshed output.

Default caching behavior (source: nextjs.org)

How is ISR implemented in the Next.js App Router?

In the App Router, ISR is implemented through data fetching and caching configuration rather than page-level lifecycle functions. This approach provides finer control over caching and revalidation and aligns with how modern Next.js applications manage data and rendering.

How does time-based revalidation work in the App Router?

Data is cached and reused across requests. After the specified interval, the cache becomes stale. The next request is served from cache, while regeneration happens in the background.

This approach works well for content that changes on a predictable schedule, such as blog posts, documentation, marketing pages, and ecommerce product or category pages built with Next.js.

How does on-demand revalidation work in the App Router?

In the App Router, this is handled using:

• revalidatePath to invalidate a specific route

• revalidateTag to invalidate all cached data associated with a tag

Tag-based revalidation is typically used in larger applications, where content updates need to affect multiple pages without tracking individual URLs. This pattern is common in headless CMS setups and ecommerce platforms such as Shopify-based storefronts built with Next.js.

How Does ISR Work in the Pages Router?

Incremental Static Regeneration is available in the Pages Router and continues to be supported in existing Next.js projects. It relies on page-level data fetching during build and serves statically generated pages that are refreshed when revalidation is triggered.

Time-based revalidation with getStaticProps

A page is generated at build time and served as a static asset. After the revalidation interval expires, the next request triggers background regeneration while the cached version continues to be served.

This approach is commonly used in Pages Router projects with editorial content, marketing pages, or product listings that do not require request-level personalization.

On-demand revalidation with res.revalidate

This is handled through API routes using res.revalidate(). External systems such as headless CMS platforms or ecommerce backends can trigger revalidation when content changes.

This pattern is often used to refresh product pages, category pages, or landing pages without rebuilding the entire application.

How to Choose Revalidation Times in Next.js

Short intervals reduce the risk of stale content but increase regeneration frequency. Longer intervals reduce regeneration cost but delay updates. In practice, time-based revalidation is often combined with on-demand invalidation.

Practical revalidation intervals for typical page types

• Editorial content and blogsLonger intervals are usually sufficient, as content changes infrequently after publication.

• Marketing and campaign pagesModerate intervals work well, often combined with on-demand revalidation when content is updated.

• Ecommerce product and category pagesShort intervals or on-demand revalidation are commonly used for pricing, availability, and promotion changes.

• High-traffic landing pagesConservative intervals help maintain performance during traffic spikes, with explicit revalidation for critical updates.

Revalidation decisions should balance how fresh content needs to be with performance impact and operational cost.

Why ISR “Works in Dev” But Fails in Production

Incremental Static Regeneration works reliably when its constraints are understood upfront. Problems usually appear when assumptions made during development no longer hold in production.

Static export limitations

ISR often looks correct during development, but issues surface after deployment when static export is enabled. In this setup, pages are generated once and shipped as static files. Without a runtime to handle regeneration, updates never occur. This typically becomes visible only when content changes fail to appear after launch.

Runtime considerations

Revalidation depends on a runtime capable of executing background work. When an incompatible or overly restricted runtime is selected, regeneration requests may succeed silently without updating cached output. These failures are easy to miss unless revalidation behavior is explicitly tested in production-like conditions.

Cache consistency across regions

In globally distributed environments, regeneration does not happen everywhere at the same moment. Some users may briefly receive updated content while others see an older version. This is expected behavior, but it can be misinterpreted as a caching error if regional propagation is not accounted for during planning.

How Does ISR Work with Headless CMS Webhooks?

Incremental Static Regeneration is commonly paired with headless CMS platforms to support frequent content updates without rebuilding the entire application.

In this pattern, content is managed in a headless CMS and delivered to a Next.js application as statically cached pages. When content is published or updated, the CMS triggers a webhook that initiates on-demand revalidation. This approach works across different CMS options used with Next.js and React-based platforms.

Webhooks typically invalidate cached content by path or tag, so only affected pages are regenerated. Updates remain fast and predictable, even on large sites with thousands of pages. This setup lets content teams publish changes independently while engineering teams retain control over performance, caching, and operational stability.