Next.js caching, explained without the confusion

Next.js caching causes more confusion than any other part of the framework, largely because there are several distinct caches with overlapping names and different lifetimes.

Knowing which one you are dealing with resolves most of the surprises.

The four caches

• Request memoization — deduplicates identical fetches within a single render pass. Lives for one request.
• The Data Cache — stores fetch results on the server, across requests and deploys until revalidated.
• The Full Route Cache — stores rendered HTML for static routes at build time.
• The Router Cache — client-side, holds payloads for routes the visitor has already visited.

"My content is stale" almost always means the Data Cache or the Full Route Cache. "It is stale only when navigating within the app" means the Router Cache.

Static versus dynamic is decided for you

A route is static unless something forces it dynamic: reading cookies or headers, using search params, or an explicit `dynamic = "force-dynamic"`.

This catches people out because adding one innocuous call can flip a whole route from static to dynamic, and the symptom is a slower site rather than an error.

Pick a revalidation strategy deliberately

• Time-based — revalidate every N seconds. Simple, and content is stale for up to N.
• On-demand — revalidate a path or tag when the data actually changes. More work, and always current.
• Fully dynamic — render every request. Always current, and you pay for it on every visit.

For a CMS-driven site, on-demand revalidation from a publish webhook is usually the right answer. Fully dynamic is the honest choice when editors expect changes to appear instantly and the traffic does not justify the engineering.

Why does my page not update after I change the CMS?

Because the route was rendered once and cached. Either the Data Cache is holding the old fetch result or the Full Route Cache is holding the old HTML. Revalidate the relevant path or tag when content changes, or mark the route dynamic if freshness matters more than speed. Rebuilding also clears it, which is why it appears to work in development and not in production.

Should I just make everything dynamic?

It is a defensible trade for a small content site where editors expect instant changes — it costs a database query per request and removes an entire category of confusion. It stops being defensible once traffic is meaningful, because you are then paying for a render on every visit to serve content that changes weekly.

This site renders content pages dynamically for exactly that reason, which is a deliberate choice rather than an oversight — more on the stack in why we bet on Next.js and Payload.