Skip to main content
Caching stores the result of data fetching and computations so that future requests can be served faster. Next.js uses the use cache directive to control what gets cached and for how long.
This page covers caching with Cache Components, enabled by setting cacheComponents: true in your next.config.ts. For the previous model, see the Caching and Revalidating (Previous Model) guide.

Enabling Cache Components

The use cache directive

The use cache directive caches the return value of async functions and components. Apply it at two levels:
  • Data-level: Cache a function that fetches or computes data
  • UI-level: Cache an entire component or page
Arguments and any closed-over values from parent scopes automatically become part of the cache key, so different inputs produce separate cache entries.

Data-level caching

Data-level caching is useful when the same data is used across multiple components, or when you want to cache the data independently from the UI.

UI-level caching

If you add 'use cache' at the top of a file, all exported functions in the file will be cached.

cacheLife profiles

cacheLife controls how long cached data remains valid. It accepts a profile name or a custom configuration object: For fine-grained control, pass a configuration object:

Streaming uncached data

For components that require fresh data on every request, do not use "use cache". Wrap them in <Suspense> instead — React renders the fallback immediately and streams in the resolved content:

Working with runtime APIs

Runtime APIs (cookies, headers, searchParams) are only available at request time. Components that access them should be wrapped in <Suspense>:

Passing runtime values to cached functions

Extract values from runtime APIs and pass them as arguments to cached functions:

How rendering works

At build time, Next.js renders your route’s component tree. How each component is handled depends on the APIs it uses:
  • use cache: the result is cached and included in the static shell
  • <Suspense>: the fallback UI is included in the static shell; content streams at request time
  • Deterministic operations (pure computations, module imports): automatically included in the static shell
This approach is called Partial Prerendering (PPR) — the default behavior with Cache Components.

Complete example

Here’s how static content, cached dynamic content, and streaming dynamic content work together:

Opting out of the static shell

Placing an empty <Suspense> fallback above the document body causes the entire app to defer to request time:
Because the fallback is null, there is no static shell to send immediately. Every request blocks until the page is fully rendered. Use this sparingly and only for specific routes.