Next.js 16: The Version That Stops Pretending Cache Was Simple

If you've ever lost hours debugging why that page wasn't updating — or why the build was taking three minutes for a small project — Next.js 16 was released with you in mind.

There's a specific moment in the life of every dev using Next.js. You make a change. You run npm run build. You wait. You wait a bit longer. The terminal counts the seconds while you drink coffee. You start questioning your life choices.

And when the build finishes, you deploy — and the page looks exactly the same as before. Because the cache didn't invalidate. And you don't know why.

Next.js 16 doesn't solve all the problems in the universe. But it solves exactly these two. And it does so in a way that finally feels intentional — not a set of configurations you stumbled upon in a Reddit thread at 11 PM.

Turbopack: From "Experimental" to "This is It"

Since Next.js 13, Turbopack was that promise on the horizon. Faster than webpack, but too experimental for production use. You'd test it, find some compatibility issue, revert to webpack, and feel guilty.

In 16, the courtship period is over. Turbopack is the default bundler — both in development and production. No flag, no configuration, no hack.

These numbers are not from artificial benchmarks. More than 50% of development sessions in Next.js 15.3+ were already running Turbopack before the official release — which means it was tested at real scale, with real code, before becoming standard.

Have custom webpack in your project? The build will intentionally fail — so your configuration isn't silently ignored. You have two options: migrate the config to Turbopack, or explicitly run with next build --webpack while you migrate.

And there's more: Turbopack File System Caching entered beta. This means compilation artifacts are saved to disk between development server restarts. In a large project, the first next dev of the day will be slow once. After that, it flies.

// next.config.ts — habilitar caching em disco (beta)
const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForDev: true,
  },
};

export default nextConfig;

Cache Components: Cache You Can Understand

This is the most important change in 16. And also the hardest to explain without sounding like documentation.

In previous App Router versions, Next.js implicitly cached things. Static routes were cached. Data fetched with fetch was cached. The general rule existed, but exceptions seemed random — and when something didn't update, you were in the dark trying to understand which part of the system decided that data was 'static'.

Next.js 16 reverses this. By default, everything is dynamic. Nothing is cached unless you explicitly say you want it to be.

// next.config.ts — ativar Cache Components
const nextConfig = {
  cacheComponents: true,
};

export default nextConfig;

With this activated, you use the `"use cache"` directive to explicitly state what you want to cache — an entire page, a specific component, a data-fetching function:

// Cachear uma função de busca de dados
async function getPosts() {
  "use cache";
  const res = await fetch("https://api.blueprint.blog/posts");
  return res.json();
}

// Cachear um componente específico
async function Sidebar() {
  "use cache";
  const data = await getSidebarData();
  return <nav>{data}</nav>;
}

More explicit invalidation APIs have also arrived: revalidateTag() with time profiles and updateTag() for instant invalidation after mutations — perfect for dashboards and forms that need to reflect data immediately.

proxy.ts: Goodbye, middleware.ts

This one seems small. It isn't.

The middleware.ts was the file that intercepted requests before they reached your application. It worked — but it ran on the Edge Runtime, which limited what you could do. No native Node.js, no certain libs, no access to certain APIs.

The proxy.ts replaces it with a crucial difference: it runs on Node.js. The migration is mechanical — rename the file, rename the exported function, and the logic remains the same:

// Antes: middleware.ts
export function middleware(request) {
  return NextResponse.redirect(new URL("/home", request.url));
}

// Depois: proxy.ts
export default function proxy(request) {
  return NextResponse.redirect(new URL("/home", request.url));
}

The middleware.ts still exists for Edge Runtime cases — but it's deprecated. If you don't have a specific reason for Edge, go with proxy.ts.

Stable React Compiler + React 19.2

Two things that were intertwined have arrived stable in 16.

The React Compiler automatically memoizes components. You know that manual work of deciding where to put useMemo and useCallback? The compiler does it for you at build time — without changing a line of code, without new syntax, without extra configuration.

// next.config.ts — ativar React Compiler (não é padrão ainda)
const nextConfig = {
  reactCompiler: true,
};

export default nextConfig;

Meanwhile, React 19.2 brings three additions that will gradually appear in your daily work:

View Transitions — native animations between navigations, without a library. useEffectEvent — a clean way to extract non-reactive logic from Effects, solving that classic stale closure problem. And Activity — components that 'hibernate' while maintaining state, perfect for tabs and modals that need to persist without being visible.

DevTools MCP: Your AI Agent within Next.js

This is the most experimental on the list — but the most interesting depending on how you work.

Next.js 16 natively implements the Model Context Protocol. This means an AI agent connected to your development environment gains access to the real application context: unified browser and server logs, automatic stack traces, understanding of the active route, caching, and rendering behavior.

Instead of copying an error to paste into a chat, the agent sees what's happening. It's the first step towards AI-assisted debugging that doesn't rely on you translating the problem into words.

How to Update

Vercel has provided an automatic codemod that handles most migrations — including renaming middleware.ts to proxy.ts and adjusting asynchronous params APIs:

npx @next/codemod@canary upgrade latest

To update manually:

npm install next@latest react@latest react-dom@latest