Caching in Next.js: A Practical Mental Model

Next.js caching has a reputation for being confusing, but for a content site it collapses into one question per route: how stale can this page afford to be?

Three answers, three strategies

• Never stale → render at request time with dynamic = "force-dynamic" and pay the latency on every hit.
• Stale for minutes is fine → prerender and revalidate with ISR. This is the sweet spot for CMS-backed pages.
• Changes only on deploy → fully static, no revalidation at all.

// ISR: serve the cached page instantly, refresh it in the
// background at most once every 60 seconds.
export const revalidate = 60;

export default async function BlogPage() {
  const posts = await getAllPosts(); // hits the CDN-cached CMS
  return <PostList posts={posts} />;
}

The part everyone forgets

Your CMS has its own cache. Sanity's CDN, for example, can serve content that is seconds behind the Studio. Stack the layers deliberately: a 60-second ISR window on top of a CDN-cached read is two caches, and your real staleness budget is their sum.

Write the budget down per route. 'Home page: fresh within two minutes' is a requirement you can implement and test — 'fast and fresh' is not.