Caching before Cache Components

The same tea shop, the older way

Cache Components is on in every new project since Next.js 16.4. Many apps were built before that, and still run the caching model Next.js had from version 13: caching set on each fetch, and options that set it for a whole route. Next.js 16.4.3 still runs that model when cacheComponents is off. Here is the tea shop's Teas page written that way, a real project built with next build and run with next start. Its next.config.ts sets no options, as create-next-app wrote it before 16.4:

1const api = process.env.SUPPLIER_API_URL;2 3export type Tea = { id: string; name: string; price: number };4 5export async function getMenu(): Promise<Tea[]> {6  const response = await fetch(`${api}/menu`, {7    cache: "force-cache",8    next: { revalidate: 3600, tags: ["menu"] },9  });10  return response.json();11}12 13export async function getStock(): Promise<{ boxes: number }> {14  const response = await fetch(`${api}/stock`, { cache: "no-store" });15  return response.json();16}

$ next build▲ Next.js 16.4.3 (Turbopack)   Creating an optimized production build ...✓ Compiled successfully  Running TypeScript ...  Finished TypeScript ...  Collecting page data ...✓ Generating static pages (4/4)  Finalizing page optimization ... Route (app)┌ ○ /├ ○ /_not-found└ ƒ /teas ○  (Static)   prerendered as static contentƒ  (Dynamic)  server-rendered on demand

lib/supplier.ts, the file shown first, asks the tea supplier's API, whose address is in SUPPLIER_API_URL. getMenu, on lines 5 to 11, passes options to fetch: line 7, cache: "force-cache", keeps the answer, and line 8 keeps it for at most an hour and names it menu. getStock, on lines 13 to 16, says cache: "no-store" on line 14: never keep this answer. app/teas/page.tsx shows a heading, the menu, and the stock inside Suspense, laid out as in Cache Components.

The Terminal tab says ƒ /teas: server-rendered on demand, for every visit. There's no line saying Cache Components is enabled. The supplier in the recording is a stand-in on the same computer, and it kept a list of the requests it got: /menu once, during the build, and /stock twice, once for each visit. So the page was made for each visit, but the menu inside it came from a cache, filled during the build. That's the older model in one page: whether the page is kept, and whether its data is kept, are separate questions, answered by separate caches. And one no-store request makes the whole route dynamic; the same page with Cache Components is ◐, a static shell with only the stock made for each visit.

fetch's cache option, next.revalidate and next.tags

On the server, Next.js extends fetch. In a browser, cache says how a request uses the browser's own HTTP cache. In Next.js's server code, it says how the request uses the server's cache of fetch answers, the Data Cache. The docs say a cached request matches on its URL, method, headers and body, and only answers with a 200 status are stored. Next.js also reads one more option, next, with a lifetime and names.

Each button below is one version of the Teas page with a single fetch of the menu, on line 4, or line 7 in the versions that read a cookie on line 6. Each was visited twice, with the cookie favorite=mint. Before you click, guess for each: does the build print ○ or ƒ, and how often does the supplier get /menu?

1const api = process.env.SUPPLIER_API_URL;2 3export default async function TeasPage() {4  const response = await fetch(`${api}/menu`);5  const teas: { id: string; name: string; price: number }[] = await response.json();6  return (7    <main>8      <h1>Our teas</h1>9      <ul>10        {teas.map((tea) => (11          <li key={tea.id}>{`${tea.name}: $${tea.price}`}</li>12        ))}13      </ul>14    </main>15  );16}

$ next build▲ Next.js 16.4.3 (Turbopack)   Creating an optimized production build ...✓ Compiled successfully  Running TypeScript ...  Finished TypeScript ...  Collecting page data ...✓ Generating static pages (4/4)  Finalizing page optimization ... Route (app)┌ ○ /├ ○ /_not-found└ ○ /teas ○  (Static)  prerendered as static content # The files next build wrote for the prerendered pages, in .next/server/app# (the server's .js code and the .json lists left out), with their sizes.next/server/app/_global-error.html  8.9 kB.next/server/app/_global-error.meta  676 bytes.next/server/app/_global-error.rsc  4.5 kB.next/server/app/_global-error.segments/__PAGE__.segment.rsc  4.2 kB.next/server/app/_global-error.segments/_full.segment.rsc  4.5 kB.next/server/app/_global-error.segments/_tree.segment.rsc  110 bytes.next/server/app/_not-found.html  7.3 kB.next/server/app/_not-found.meta  766 bytes.next/server/app/_not-found.rsc  4.5 kB.next/server/app/_not-found.segments/_full.segment.rsc  4.5 kB.next/server/app/_not-found.segments/_not-found/__PAGE__.segment.rsc  4.0 kB.next/server/app/_not-found.segments/_tree.segment.rsc  164 bytes.next/server/app/index.html  4.9 kB.next/server/app/index.meta  595 bytes.next/server/app/index.rsc  3.1 kB.next/server/app/index.segments/__PAGE__.segment.rsc  2.8 kB.next/server/app/index.segments/_full.segment.rsc  3.1 kB.next/server/app/index.segments/_tree.segment.rsc  110 bytes.next/server/app/teas.html  5.6 kB.next/server/app/teas.meta  713 bytes.next/server/app/teas.rsc  3.6 kB.next/server/app/teas.segments/_full.segment.rsc  3.6 kB.next/server/app/teas.segments/_tree.segment.rsc  157 bytes.next/server/app/teas.segments/teas/__PAGE__.segment.rsc  3.0 kB

The supplier's list of requests is the clearest way to read the results. Each row of the picture is one version, and each card says who gave the page its menu:

• No option is not "no cache". The page read nothing from the request, so the build made it, fetch and all, and kept the whole page: ○. The menu came from the page, not from the Data Cache. The Network tab shows it: the response was teas.html, as the build wrote it.
• With a cookie, the page is made for each visit, and an option-less fetch runs each time. Only force-cache kept the menu: fetched on the first visit, and taken from the Data Cache on the second.
• no-store runs the fetch for every request, and so makes the page dynamic even without a cookie.

Each row is one option: what the docs say it does, and what the recordings showed.

A few rules from the docs:

• The lowest lifetime wins. A fetch with a shorter revalidate than its route's makes the whole route revalidate that often. Two fetches of the same URL with different lifetimes use the lower one.
• Conflicting options are ignored. { revalidate: 3600, cache: "no-store" } sets neither, and next dev prints a warning.
• Tags name answers. next: { tags: ["menu"] } lets revalidateTag("menu", "max") mark them out of date after an edit; Revalidating cached data covers it.

unstable_cache for work that isn't fetch

Next.js wires fetch into the Data Cache for you, through its options. A database query, an ORM, or a file read doesn't go through fetch, so it needs another way in: unstable_cache from next/cache, which wraps an async function and keeps what it returns in the same Data Cache. Here the shop's teas are in a file, data/teas.json, standing in for a database, and the Teas page also reads the favorite cookie, so the page is made for each visit:

import { readFile } from "node:fs/promises";
import { unstable_cache } from "next/cache";
import type { Tea } from "./tea";

export const getTeas = unstable_cache(
  async (): Promise<Tea[]> => {
    console.log("Reading data/teas.json");
    return JSON.parse(await readFile("data/teas.json", "utf8"));
  },
  ["teas"],
  { revalidate: 3600, tags: ["teas"] },
);

Line 5 wraps the function on lines 6 to 9. Line 7 prints a line each time the function really runs, so the recording can count the runs. Line 10, ["teas"], is the key parts: extra values for the cache key. The docs say the function's arguments and its code already make the key, so key parts are only needed for outside values the function uses without taking them as arguments. Line 11 sets a lifetime of an hour and the tag teas. Compare it with the same function unwrapped:

import { readFile } from "node:fs/promises";
import type { Tea } from "./tea";

export async function getTeas(): Promise<Tea[]> {
  console.log("Reading data/teas.json");
  return JSON.parse(await readFile("data/teas.json", "utf8"));
}

1import { readFile } from "node:fs/promises";2import type { Tea } from "./tea";3 4export async function getTeas(): Promise<Tea[]> {5  console.log("Reading data/teas.json");6  return JSON.parse(await readFile("data/teas.json", "utf8"));7}

$ next build▲ Next.js 16.4.3 (Turbopack)   Creating an optimized production build ...✓ Compiled successfully  Running TypeScript ...  Finished TypeScript ...  Collecting page data ...✓ Generating static pages (4/4)  Finalizing page optimization ... Route (app)┌ ○ /├ ○ /_not-found└ ƒ /teas ○  (Static)   prerendered as static contentƒ  (Dynamic)  server-rendered on demand $ next start▲ Next.js 16.4.3- Local:         http://127.0.0.1:3000- Network:       http://127.0.0.1:3000✓ ReadyReading data/teas.jsonReading data/teas.jsonReading data/teas.json

Without unstable_cache, three visits printed Reading data/teas.json three times. With it, once: the first visit ran the function, and the next two got its copy, while each visitor still saw their own favorite. Two rules from the docs:

• No request data inside. The wrapped function can't call cookies() or headers(). Read them outside, and pass the values in as arguments, so they become part of the key.
• It's been replaced. The docs say "use cache" replaced unstable_cache in Next.js 16, and recommend moving to it with Cache Components.

One more tool shows up next to it in older code: React's cache, which shares a function's result within one render, like request memoization does for fetch. It keeps nothing between requests.

Route segment config: dynamic, revalidate and fetchCache

Route segment config is an option a page, layout or Route Handler sets by exporting a constant, read by Next.js for that part of the address. In the older model, three of them set caching for a whole route:

• dynamic: "auto" (the default), "force-dynamic" to make the route for every request, "force-static" to make it during the build no matter what, or "error" to make it during the build and fail if anything stops that.
• revalidate: false (the default, kept until something revalidates it), 0 to make the route for every request, or a number of seconds: the route's lifetime, which makes it ISR (Incremental Static Regeneration).
• fetchCache: "auto" by default, or one of six values that change the cache option of every fetch in the route: "default-cache", "only-cache" and "force-cache" lean toward keeping answers, "default-no-store", "only-no-store" and "force-no-store" toward not keeping them. default- changes only fetches with no option, only- also fails on a fetch that asks for the other, and force- overrides every fetch. The docs call it an advanced option, only for overriding the default.

Each button is the Teas page with one option. The first four read the cookie; the last two don't, so you can see an option change a page that would otherwise be ○. Before you click, guess what force-static does with the cookie.

1import { cookies } from "next/headers";2 3const api = process.env.SUPPLIER_API_URL;4 5export default async function TeasPage() {6  const favorite = (await cookies()).get("favorite")?.value;7  const response = await fetch(`${api}/menu`);8  const teas: { id: string; name: string; price: number }[] = await response.json();9  return (10    <main>11      <h1>Our teas</h1>12      <p>{favorite ? `Your favorite: ${favorite}` : "Pick a favorite tea"}</p>13      <ul>14        {teas.map((tea) => (15          <li key={tea.id}>{`${tea.name}: $${tea.price}`}</li>16        ))}17      </ul>18    </main>19  );20}

$ next build▲ Next.js 16.4.3 (Turbopack)   Creating an optimized production build ...✓ Compiled successfully  Running TypeScript ...  Finished TypeScript ...  Collecting page data ...✓ Generating static pages (4/4)  Finalizing page optimization ... Route (app)┌ ○ /├ ○ /_not-found└ ƒ /teas ○  (Static)   prerendered as static contentƒ  (Dynamic)  server-rendered on demand

force-static built ○ /teas, and both visits said Pick a favorite tea, though they sent favorite=mint: the docs say it makes cookies(), headers() and useSearchParams() return empty values. "error" stopped the build at the cookie. fetchCache = "default-cache" left the page dynamic but kept the menu. Two more rules from the docs:

• The lowest revalidate wins across a route's layouts and page, so a page can't be kept longer than its layout allows.
• The value must be a plain number: revalidate = 600 works, revalidate = 60 * 10 doesn't, because Next.js reads it without running your code.

Those three aren't the only exports. Each row is one route segment option an older app may have, and what Next.js 16.4.3 does with it once Cache Components is on, from its source (react_server_components.rs, lines 935 to 970) and the recordings:

import { cookies } from "next/headers";

const api = process.env.SUPPLIER_API_URL;

export const dynamic = "force-static";

export default async function TeasPage() {
  const favorite = (await cookies()).get("favorite")?.value;

Line 5 is the option, and line 8 reads the cookie. With force-static, line 8 gets nothing at build time, and the page made then is the one every visitor gets.

The four caches

Next.js's docs for version 15 describe the older model as four caches, and the name stuck: you'll meet "the four caches" in many articles and code reviews. Each row is one of them, from those docs:

Request memoization

Two components on one page often need the same data. Here, MenuCount and MenuList both call getMenu(), which fetches with no-store:

1const api = process.env.SUPPLIER_API_URL;2 3type Tea = { id: string; name: string; price: number };4 5async function getMenu(): Promise<Tea[]> {6  const response = await fetch(`${api}/menu`, { cache: "no-store" });7  return response.json();8}9 10async function MenuCount() {11  const teas = await getMenu();12  return <p>{teas.length} teas today</p>;13}14 15async function MenuList() {16  const teas = await getMenu();17  return (18    <ul>19      {teas.map((tea) => (20        <li key={tea.id}>{`${tea.name}: $${tea.price}`}</li>21      ))}22    </ul>23  );24}25 26export default function TeasPage() {27  return (28    <main>29      <h1>Our teas</h1>30      <MenuCount />31      <MenuList />32    </main>33  );34}

Line 6 is the one fetch; lines 11 and 16 call it from two components. The page was visited twice, and the supplier got /menu twice, not four times. Within one render, the second call to the same GET got the first call's answer. The docs say this is React's doing, not Next.js's, that it only covers GET, and that it doesn't apply in Route Handlers, which aren't part of a React render. It lasts one render, so no-store still fetched again on the next visit.

The Data Cache and the Full Route Cache

The Data Cache is what force-cache, next.revalidate and unstable_cache fill. The docs say it lasts across requests and across deployments. In Next.js 16.4.3, the default cache writes it to files in .next/cache/fetch-cache, outside the build's own output, so it can outlive a new build; that folder is an internal of this version. The Full Route Cache is the pages the build made, like the teas.html the No option version was served from. A new deployment clears it. The two are linked: the docs say revalidating data in the Data Cache also clears the kept pages made from it, so they're made again, and a page made for each request can still read from the Data Cache, as the force-cache, and a cookie version did.

The Router Cache

The fourth cache is in the browser. After a client-side navigation, the router keeps the page's RSC payload, React's description of what the Server Components rendered, so going back doesn't ask the server again (Linking and navigating showed the requests). How long it keeps a page changed in Next.js 15, in the next part.

What Next.js 15 changed

The older model started out caching as much as it could. Next.js 15, released on October 21, 2024, changed three defaults. Its release post says fetch requests, GET Route Handlers and client navigations are no longer cached by default. Each row is one of them, from the post and the version 15 upgrade guide:

The first row is in the fetch playground above: with a cookie and no option, the menu was fetched on every visit. The second is a Route Handler that answers GET /api/menu with the menu. Before you click, guess which version asks the supplier on each call.

1const api = process.env.SUPPLIER_API_URL;2 3export async function GET() {4  const response = await fetch(`${api}/menu`);5  return Response.json(await response.json());6}

[{"id":"green","name":"Green tea","price":4},{"id":"mint","name":"Mint tea","price":3}]

With no option, ƒ /api/menu: each call ran the handler, and the supplier got /menu twice. With export const dynamic = "force-static", ○ /api/menu: made during the build, and both calls got the stored answer with x-nextjs-cache: HIT. The release post adds that special Route Handlers like sitemap.ts and opengraph-image.tsx stay static by default.

The third row needs a browser. Each version below was clicked through in real Chrome: open Home, click Teas, click Home, and click Teas again. The Teas page fetches with no-store, so it's dynamic. The second version adds this to next.config.ts:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  experimental: {
    staleTimes: { dynamic: 3600 },
  },
};

export default nextConfig;

Lines 4 to 6 set experimental.staleTimes.dynamic: how long, in seconds, the router may reuse a dynamic page it already has. Before Next.js 15 the default was 30 seconds. The recording uses 3,600, an hour, on purpose: four clicks take a few seconds, so the second click on Teas can't land after the window, however slow the computer. Open the Steps tab on the last click in each version:

1import type { NextConfig } from "next";2 3const nextConfig: NextConfig = {4  /* config options here */5};6 7export default nextConfig;

By default, the last click sent one request: /teas again, with the router's rsc header. With staleTimes.dynamic: 3600, it sent none. The staleTimes docs list the change: dynamic went from 30 seconds to 0 in Next.js 15, and static, for pages made ahead or fully prefetched, stays at 5 minutes. In Next.js 16.4.3's code, the build turns the option into a number the router reads, 0 when it isn't set (define-env.ts, lines 235 to 244), and the router adds it to the time a page arrived to get the moment it goes stale (bfcache.ts, lines 17 to 24). The release post says what didn't change: shared layouts aren't fetched again, Back and Forward still restore from the cache, and a loading.js is kept for 5 minutes. The option is still under experimental, as its name in the config says.

Moving to Cache Components

Cache Components needs Next.js 16, so an app on 15 or older upgrades first. Then the migration guide's steps are short: turn on cacheComponents, replace each route segment config the build rejects, then follow what the build and next dev report, caching data with "use cache" or streaming it in Suspense. Here is the older shop, moved one step at a time. Before you click, guess which step stops the build.

1const api = process.env.SUPPLIER_API_URL;2 3export type Tea = { id: string; name: string; price: number };4 5export async function getMenu(): Promise<Tea[]> {6  const response = await fetch(`${api}/menu`, {7    cache: "force-cache",8    next: { revalidate: 3600, tags: ["menu"] },9  });10  return response.json();11}12 13export async function getStock(): Promise<{ boxes: number }> {14  const response = await fetch(`${api}/stock`, { cache: "no-store" });15  return response.json();16}

$ next build▲ Next.js 16.4.3 (Turbopack)   Creating an optimized production build ...✓ Compiled successfully  Running TypeScript ...  Finished TypeScript ...  Collecting page data ...✓ Generating static pages (4/4)  Finalizing page optimization ... Route (app)┌ ○ /├ ○ /_not-found└ ƒ /teas ○  (Static)   prerendered as static contentƒ  (Dynamic)  server-rendered on demand

Step by step:

1. The older shop is ƒ /teas, as in the overview.
2. Cache Components on, nothing else changed. It builds: ◐ /teas 1h 1y. The migration guide says your existing fetch and unstable_cache caching keeps working, and the recording agrees: the force-cache menu was fetched once, during the build, and is in the static shell, while the no-store stock streams in.
3. A route option stops it. Many apps upgraded from Next.js 14 added export const fetchCache = "default-cache" to the root layout, as the version 15 upgrade guide suggests for keeping the older default. With Cache Components on, the build stopped at ./app/layout.tsx:4:14: Route segment config "fetchCache" is not compatible with nextConfig.cacheComponents. Please remove it. Cache Components recorded the same for dynamic and revalidate, and export const runtime = "nodejs" stopped this shop's build too, though nodejs is the default. export const maxDuration = 5 built.
4. Moved. getMenu gets "use cache", cacheLife("hours") and cacheTag("menu"), and both fetches lose their options. ◐ /teas 1h 1d: the Expire time is now the hours profile's day, instead of the older default of a year.

import { cacheLife, cacheTag } from "next/cache";

const api = process.env.SUPPLIER_API_URL;

export type Tea = { id: string; name: string; price: number };

export async function getMenu(): Promise<Tea[]> {
  "use cache";
  cacheLife("hours");
  cacheTag("menu");
  const response = await fetch(`${api}/menu`);
  return response.json();
}

export async function getStock(): Promise<{ boxes: number }> {
  const response = await fetch(`${api}/stock`);
  return response.json();
}

Line 8 caches what getMenu returns, line 9 gives it the hours profile, and line 10 names it menu, so revalidateTag("menu", "max") still works. Line 16 fetches the stock with no option: with Cache Components, it's fresh for each request, and the Suspense on the page streams it. Each option maps to a replacement:

Three more things from the migration guide:

• Where the cache lives changes. The Data Cache and unstable_cache keep entries across deployments. "use cache" keeps them in memory by default, for one deployment; "use cache: remote" or a cache handler stores them elsewhere (Private and remote caches).
• One route at a time. export const instant = false on a segment lets it block while you work on others, and a codemod, cache-components-instant-false, adds it everywhere. It doesn't clear errors about values like new Date().
• Revalidation. revalidateTag now takes a profile, like revalidateTag("menu", "max"), and updateTag is there for a Server Action whose user must see the change at once. revalidatePath is unchanged.

Reading an older codebase

Before turning Cache Components on in an older app, search it for the options above: cache:, next: {, unstable_cache, unstable_noStore, and export const lines named dynamic, revalidate, fetchCache, runtime and dynamicParams. Each one tells you what the page relied on. Sort these lines by what happens to them when Cache Components is turned on:

Fix the ones that stop the build first; they're the only ones you must change. Then move fetch options and unstable_cache to "use cache" when you're ready, page by page, checking the route table after each change.

Common mix-ups

• "A fetch with no option is never cached." No. On a page that reads nothing from the request, the build made the page with the fetch in it, and both visits got that page. The answer wasn't in the Data Cache, but the page was kept.
• "A dynamic page can't use cached data." No. With a cookie, the page was ƒ, and force-cache still kept the menu.
• "force-static caches the page, and still reads the cookie." No. It makes cookies() empty: every visitor got Pick a favorite tea.
• "Two components fetching the same URL make two requests." No. Within one render, the second GET gets the first one's answer.
• "Turning on Cache Components breaks every fetch option." No. The older shop built with its force-cache menu in the shell. What stops the build is five route options: dynamic, dynamicParams, revalidate, fetchCache and runtime.
• ""use cache" stores data the way the Data Cache did." No. By default it keeps entries in memory, for one deployment; the Data Cache lasts across deployments.

Practice exercises

These exercises are about Next.js projects, which can't run inside this page. Answer first, then use the hints.

const api = process.env.SUPPLIER_API_URL;

export default async function TeasPage() {
  const response = await fetch(`${api}/menu`, { cache: "no-store" });
  const teas: { id: string; name: string; price: number }[] = await response.json();
  return (
    <main>
      <h1>Our teas</h1>
      <ul>
        {teas.map((tea) => (
          <li key={tea.id}>{`${tea.name}: $${tea.price}`}</li>
        ))}
      </ul>
    </main>
  );
}

import { cookies } from "next/headers";

const api = process.env.SUPPLIER_API_URL;

export const dynamic = "force-static";

export default async function TeasPage() {
  const favorite = (await cookies()).get("favorite")?.value;
  const response = await fetch(`${api}/menu`);
  const teas: { id: string; name: string; price: number }[] = await response.json();
  return (
    <main>
      <h1>Our teas</h1>
      <p>{favorite ? `Your favorite: ${favorite}` : "Pick a favorite tea"}</p>
      <ul>
        {teas.map((tea) => (
          <li key={tea.id}>{`${tea.name}: $${tea.price}`}</li>
        ))}
      </ul>
    </main>
  );
}

import { cookies } from "next/headers";

const api = process.env.SUPPLIER_API_URL;

export default async function TeasPage() {
  const favorite = (await cookies()).get("favorite")?.value;
  const response = await fetch(`${api}/menu`);
  const teas: { id: string; name: string; price: number }[] = await response.json();
  return (
    <main>
      <h1>Our teas</h1>
      <p>{favorite ? `Your favorite: ${favorite}` : "Pick a favorite tea"}</p>
      <ul>
        {teas.map((tea) => (
          <li key={tea.id}>{`${tea.name}: $${tea.price}`}</li>
        ))}
      </ul>
    </main>
  );
}

import { cookies } from "next/headers";

const api = process.env.SUPPLIER_API_URL;

export default async function TeasPage() {
  const favorite = (await cookies()).get("favorite")?.value;
  const response = await fetch(`${api}/menu`, { cache: "force-cache" });
  const teas: { id: string; name: string; price: number }[] = await response.json();
  return (
    <main>
      <h1>Our teas</h1>
      <p>{favorite ? `Your favorite: ${favorite}` : "Pick a favorite tea"}</p>
      <ul>
        {teas.map((tea) => (
          <li key={tea.id}>{`${tea.name}: $${tea.price}`}</li>
        ))}
      </ul>
    </main>
  );
}

import { readFile } from "node:fs/promises";
import type { Tea } from "./tea";

export async function getTeas(): Promise<Tea[]> {
  console.log("Reading data/teas.json");
  return JSON.parse(await readFile("data/teas.json", "utf8"));
}

import { readFile } from "node:fs/promises";
import { unstable_cache } from "next/cache";
import type { Tea } from "./tea";

export const getTeas = unstable_cache(
  async (): Promise<Tea[]> => {
    console.log("Reading data/teas.json");
    return JSON.parse(await readFile("data/teas.json", "utf8"));
  },
  ["teas"],
  { revalidate: 3600, tags: ["teas"] },
);

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  experimental: {
    staleTimes: { dynamic: 3600 },
  },
};

export default nextConfig;

const api = process.env.SUPPLIER_API_URL;

export type Tea = { id: string; name: string; price: number };

export async function getMenu(): Promise<Tea[]> {
  const response = await fetch(`${api}/menu`, {
    cache: "force-cache",
    next: { revalidate: 3600, tags: ["menu"] },
  });
  return response.json();
}

export async function getStock(): Promise<{ boxes: number }> {
  const response = await fetch(`${api}/stock`, { cache: "no-store" });
  return response.json();
}

import { cacheLife, cacheTag } from "next/cache";

const api = process.env.SUPPLIER_API_URL;

export type Tea = { id: string; name: string; price: number };

export async function getMenu(): Promise<Tea[]> {
  "use cache";
  cacheLife("hours");
  cacheTag("menu");
  const response = await fetch(`${api}/menu`);
  return response.json();
}

export async function getStock(): Promise<{ boxes: number }> {
  const response = await fetch(`${api}/stock`);
  return response.json();
}

Check your understanding

For each question, ask two things: is the page made during the build or for each request, and is the data kept?

Key takeaways

• Without Cache Components, caching is set on each fetch (cache, next.revalidate, next.tags), with unstable_cache for other functions, and for each route with dynamic, revalidate and fetchCache.
• Whether the page is kept and whether its data is kept are separate questions: a dynamic page can read cached data, and a static page keeps uncached data inside it.
• Four caches: request memoization for one render, the Data Cache across requests and deployments, the Full Route Cache for whole pages, and the Router Cache in the browser.
• Next.js 15 stopped caching fetch answers, GET Route Handlers and dynamic pages in the router by default.
• With Cache Components on, dynamic, dynamicParams, revalidate, fetchCache and runtime stop the build, while maxDuration still works; fetch options and unstable_cache keep working until you move them to "use cache", cacheLife and cacheTag.

Coming next: Parallel routes, the first lesson of the Building real apps stage: several pages in one layout, each with its own loading and error states.