Frontend Beauty
ESC

Type to search the knowledge base.

ISR Mental Model

ISR in the App Router: time-based revalidation, on-demand tags, stale-while-revalidate behavior, and when to go fully dynamic.

intermediate3 min read
  • nextjs
  • isr-mental

Incremental Static Regeneration (ISR) means: serve a cached page (or fetch result), and refresh it in the background after a time window or on-demand invalidation. Users rarely wait on rebuilds for the whole site.

Docs: Revalidating, Caching.

Time-based

export const revalidate = 60; // segment

// or per fetch
await fetch(url, { next: { revalidate: 60 } });

After 60 seconds, the next request can trigger regeneration; subsequent users get the new version (stale-while-revalidate style behavior depending on platform).

On-demand

import { revalidatePath, revalidateTag } from 'next/cache';

export async function updateProduct(id: string) {
  await db.products.update(id);
  revalidateTag('product');
  revalidatePath(`/product/${id}`);
}

CMS webhooks often call a Route Handler that revalidates tags after publish.

Mental model

  1. Prefer static + revalidate for content that changes occasionally.
  2. Tag related fetches so one publish updates many surfaces.
  3. Use fully dynamic for per-user private data.
  4. Do not assume “ISR” is a single API — it is the outcome of caching + revalidation settings.

Pitfalls

  • Forgetting tags → stale UI after CMS edit.
  • Mixing no-store with ISR expectations.
  • Revalidating the wrong path (trailing slashes, locales).

Interview out-loud

“ISR serves cached output and regenerates after a time window or on-demand revalidation. In App Router I set revalidate on fetch or segments and call revalidateTag after mutations. Private personalized data stays dynamic instead.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Quick self-test

Explain the concept in 60 seconds, write a minimal code sample from memory, name one footgun, and point to the primary docs. If any of those fail, reread the worked example and rebuild it in a scratch file until the model sticks under interview pressure.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides