Next.js 16.4: Cache Components Are Now the Default

Next.js 16.4 is out, and the headline is a change of recommendation rather than a feature: Vercel now says Cache Components are the right choice for every Next.js app. New projects from create-next-app get them switched on, and Cache Components become the default in Next.js 17. If you run an existing App Router app, nothing breaks on upgrade, but you now have a deadline in the form of a roadmap.

The release landed on October 6, 2026. Two days later the team announced an out-of-band security update for October 14, which affects how you should schedule the upgrade. Both are covered below.

What Cache Components actually are

Cache Components are a model where you opt parts of the tree into caching with the 'use cache' directive. Think of it as the Cache-Control header, but attached to a component or function instead of a URL. Next.js caches the rendered UI in the browser during client navigations and, if you ask, on the server or at build time too.

async function Projects({ userId }) {
  'use cache';
  cacheLife('hours');

  const projects = await db.query.projects.findMany({
    where: eq(projectsTable.userId, userId),
  });
  // render the list
}

The model replaces the implicit caching of older App Router versions, which is the part that confused most teams. Before, you found out what was cached by reading docs or by shipping a stale page. Now caching is something you write down.

To use it in an existing app today, set two flags:

// next.config.ts
const nextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};
export default nextConfig;

Partial Prefetching used to be a separate idea. As of 16.4 it’s part of the model. If you already read our walkthrough of Next.js 16.3 Instant Navigations, this is the follow-through: navigations feel instant because the cached shell is already in the browser.

Why Vercel changed its recommendation

Earlier 16.x releases didn’t recommend Cache Components for everyone because some cases couldn’t match the cost and performance of the old model. Vercel says 16.4 closes those gaps, and three new APIs are where you can see it.

ensureStatic: a build-time guard

Mixing static and request-time content in one response is the point of the model. It’s also how a marketing page quietly becomes a server-rendered page: someone drops a UserAvatar that reads cookies, and now every visit costs compute.

ensureStatic is the guard. Export it from a route and the build fails if any dynamic content shows up:

export const ensureStatic = 'navigation';

There are three levels. 'shell' checks only what’s fetched when a route is first discovered, 'prefetch' covers links with explicit prefetching, and 'navigation' is the strictest. You can put it in a root layout to cover the whole site, then loosen it in nested layouts where a page needs dynamic data. For stores, blogs and landing pages, that is a cheap way to stop a cost regression in code review rather than on the invoice.

navigation() and prefetch(): choose when work happens

The second pair solves an over-fetching problem. Say an inbox links to hundreds of messages and you add <Link prefetch> so opening one has no spinner. Now every visible link prefetches its entire thread, including messages nobody opens.

The fix in 16.4 is to await navigation() inside the heavy component:

import { navigation } from 'next/cache';

async function Thread({ id }) {
  await navigation();
  const thread = await getThread(id);
  // render the thread
}

During a prefetch, the page renders the first message and skips the thread. The thread loads on a real navigation. prefetch() does the same one stage earlier, excluding content from a route’s shell until an explicit prefetch happens. My read: this is the most useful addition in the release, because the alternative was turning prefetching off and giving up the instant feel entirely.

Changes that arrive with every upgrade

Not everything is opt-in. These apply to all apps:

Change	What you get
Turbopack disk cache	20-25% less space, using Zstandard for bulk data and LZ4 for metadata
Lazy server HMR	Server updates compile only when a request needs them
Shared Turbopack runtime	One runtime chunk shared across routes, smaller downloads
Production CSS Modules	Shorter class names, plus export mangling for smaller bundles
React 19.3	Stable View Transitions and Fragment Refs, plus the new browser() API

React 19.3 deserves its own read, and we wrote it up in React 19.3: View Transitions and Fragment Refs Are Stable. Its changelog also includes behavior changes, such as effects double-invoking during hydration in Strict Mode, so test before you ship.

Agent upgrades and a note of caution

Next.js 16.4 adds next upgrade --agent, a command that prepares version-specific migration guides, codemods and verification steps for a coding agent to follow. A new experimental.agentUpgrade setting nudges you during next dev and next build when a relevant upgrade exists. The default policy, 'security', reminds you only about upgrades that fix known vulnerabilities affecting your installed version.

There’s also an experimental agent feedback workflow, on by default for new apps, where the agent drafts reports for you to review and send. It needs Next.js Telemetry on and doesn’t run in CI. Nothing goes out until you press send.

I’d treat all of this as convenience, not a substitute for reading the diff. An agent that migrates an app to Cache Components still has to decide what is safe to cache per user, and that’s a product decision.

Should you upgrade now?

Here’s the order I’d follow.

1. If you’re still on Next.js 15, deal with that first. Support for that line ends October 21, and our upgrade checklist for moving off Next.js 15 covers it.
2. Create a staging branch on 16.4 without turning on cacheComponents. Run the test suite and watch the Turbopack build.
3. Wait for the October 14 security update before promoting to production. Vercel says it fixes two Critical and one High vulnerability in upstream dependencies, and that two of those were postponed from the September release because of upstream coordination. The full advisories, affected versions and upgrade steps arrive with the update.
4. After that, pilot Cache Components on one low-risk route. Add ensureStatic to anything that must stay static.

Teams that migrated to Next.js 16 for Turbopack and Cache Components earlier this year already know the main trap: data that reads cookies or headers needs a Suspense boundary, or the build complains. Expect the same on older routes.

The takeaway: upgrade to 16.4 for the free Turbopack gains, but schedule it after October 14. Adopt Cache Components route by route before Next.js 17 makes the decision for you.