Notes on Next.js 16 Cache Components

About half a year ago, Next.js 16 was officially released on October 21, 2025.

The concept of Cache Components itself was introduced in Next.js 16, allowing caching to be explicitly controlled.

Only the places where the use cache directive is written are cached, and <Sunpense>component-level caching is now also possible.

Since this topic is already getting attention, this article primarily summarizes how to use "Cache Components" in Next.js 16, serving as a set of notes for my own reference!

The Four Caches in Next.js App Router

There are four types of caching in the Next.js App Router, as follows.

• Request Memoization: Deduplicates identical requests. Even if different components call the same fetch, it executes only once. This is a feature Next.js provides automatically.
• Data Cache: Controls caching behavior through fetch options.
• Full Route Cache: A per-page cache that works with static rendering (SSG, ISR). It caches on the server side, storing the RSC payload and HTML.
• Router Cache: A temporary cache that stores only the "RSC payload" in client-side memory. It works when using the Next.js component.

New feature in Next.js 16: "use cache"

About Cache Components, the new feature, and what it now makes possible.

• Simplifies cache configuration with use cache. Only the places where use cache is written are cached, giving you explicit control over caching.
• Wrapping content in <Suspense> separates components, enabling caching to be specified per component.

Up through Next.js 15, fetch was cached by default. It was hard to tell what was and wasn't cached, which made unexpected caching likely.

Because caching happened automatically by default, opting out required adding fetch(URL, { cache: 'no-store' }).

Next.js 16 changed the approach: when caching is needed, you specify use cache. This makes the approach clearly simpler.

Previously, the Next.js Data Cache could only be used through fetch. It can now be applied directly to async functions that don't use fetch, such as database queries.

Implementation

You need to enable Cache Components in the next.config.js file.

This setting makes the Cache Components feature available!

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

To cache a component, add the use cache directive at the top of the component. To cache only a specific function, write the directive inside the function.

'use cache'

async function getPosts() {
  const res = await fetch('<https://api.example.com/posts>')
  return res.json()
}

export default async function PostList() {
  const posts = await getPosts()
  return (
    <ul>
      {posts.map(post => <li>{post.title}</li>)}
    </ul>
  )
}

What happens if you don't add use cache to a fetch function?

Starting with Next.js 16, you need to add use cache to enable caching. But what happens if you add neither use cache nor the cache option?

If you set cacheComponents: true, it will result in an error. To intentionally disable caching, do not use fetch(url, { cache: 'no-store' }); simply wrap it with <Suspense>...! (When cacheComponents: false (default), no-store works as before.)

Function-Level Caching

Previously, caching could only be configured at the page level. By using use cache and , cache settings can now be applied at the component and function level.

What this means in practice: static and dynamic rendering can be mixed within a single page, allowing fast static delivery and dynamic content to coexist. This dramatically improves initial load speed and UX. (This is the PPR rendering method.)

Suspense

Its role is to allow it to be processed independently from the rest of the page, separate from <Suspense>the other parts.

By wrapping content in <Suspense>the component can be separated, so if you want to cache at the component level, specify it within the wrapped component.

About Rendering

The caching configuration determines the rendering method.

"How do you want to present this page and data?" (e.g., how often it updates)

↓

Decide the rendering method (SSG / ISR / SSR / PPR / CSR)

↓

Configure caching accordingly

This is the underlying concept.

There are several rendering approaches as well, but I'll skip them this time!

For example,

In the case of a "dynamic routing page that fetches data from microCMS and displays blog articles"

↓

SSG or ISR is the best rendering method, since the article content isn't updated frequently.

↓

Caching is the best choice, so add use cache.

You can implement it along those lines.

By the way, unless you set Cache Components to true in the next.config.js file, the traditional fetch cache option will continue to work as before.

Summary

When thinking about cache settings, the important workflow is to ask "how do we want this data or page to appear?" and then implement the optimal performance for that page.

Once that answer is clear, the decision of whether to use use cache naturally follows.

I think many people tend to understand cache, rendering methods, and data fetching as separate topics, but it feels like everything is connected!

It's important to think of these not as separate concepts, but as a single flow!