Render Modes
← Module 2 · Next.js rendering

Incremental Static Regeneration

Static, but with a heartbeat. The first visitor after each revalidation window triggers a background regeneration. Everyone else still gets the cached version, no waiting.

Last regenerated atISR

2026-05-05T12:37:15.795Z

In production, hard-refresh every few seconds (Cmd+Shift+R / Ctrl+Shift+R). The timestamp updates roughly every 10 seconds, between regenerations the cached value stays.

What happens

  1. Build, the page is prerendered, like SSG.
  2. Request (fresh), the cached HTML is served instantly.
  3. Request (stale), after the revalidate window, the next request still gets the cached version, and Next.js re-renders in the background.
  4. Swap, subsequent requests get the freshly regenerated HTML.

The code

isr/page.tsx
// app/rendering/isr/page.tsx
"use cache";
import { cacheLife } from "next/cache";

export default async function Page() {
  cacheLife({ revalidate: 10, expire: 600 });
  // ↑ serve from cache for 10s, regenerate in background after that.
  //   expire must be ≥ 5 min or Next.js excludes it from prerender.
  const generatedAt = new Date().toISOString();
  return <span>{generatedAt}</span>;
}

The inline object form of cacheLife lets you set revalidate and expire in seconds. If expireis under 5 minutes, Next.js refuses to prerender the page (it becomes a “dynamic hole”),so we use 600 seconds here.

Trade-offs

  • Good: CDN-fast like SSG but content stays current. Great for high-traffic listings, leaderboards, news.
  • Bad: data is always slightly stale; revalidations cost money; not suitable for per-user data.