Caching and Revalidation

Nothing in Next.js 10,514 changed more between version 14 and version 16 than caching. The old App Router shipped four or five interlocking caches that were on by default, and most questions people asked about Next.js were really questions about why a page would not update. Version 16 threw that away: rendering is now dynamic by default, and you opt individual functions, components, pages and layouts into caching with a directive.

The feature is called Cache Components. You turn it on with one flag, then mark cacheable work with "use cache", give each result a lifetime with cacheLife, label it with cacheTag, and invalidate it from a Server Action with updateTag or refresh. Everything Next.js can finish ahead of time becomes a static shell; everything it cannot streams in behind a <Suspense> fallback. That one mechanism replaces the Data Cache, the Full Route Cache, Incremental Static Regeneration and the experimental Partial Prerendering flag.

The payoff is that caching becomes something you can read off the source, and next build prints what it decided for every route. The cost is that you have to be explicit: the build fails rather than guesses when it meets data it cannot resolve.

One serialized payload, three places it can be stored
One serialized payload, three places it can be stored

Subsections