Next.js 16: Turbopack Is Now Default — What Changed and Why It Matters

Next.js 16 has been out since last October, but it's still the version most teams are actively migrating to, and this month brought a fresh update worth knowing about on top of it: an experimental Turbopack chunking control that ships smarter code-splitting for large sites. Between the stable release and this month's addition, there's enough new here to be worth a proper rundown — especially the breaking changes, which are easy to miss if you're upgrading from Next.js 15 in one jump.

Turbopack is no longer optional

The single biggest change in Next.js 16 is that Turbopack — Vercel's Rust-based bundler — is now the default for every new project, for both development and production builds. It's not experimental anymore either; it reached full stability in this release. The numbers Vercel has published are substantial: 2–5× faster production builds and up to 10× faster Fast Refresh during development. Adoption has apparently scaled quickly since the beta, with more than 50% of development sessions and 20% of production builds on Next.js 15.3+ already running on Turbopack before it even became the default. If you have a custom webpack setup you're not ready to migrate off, you can still opt back in with next dev --webpack or next build --webpack — but that's now the exception path, not the default one.

Cache Components: an explicit, opt-in caching model

Next.js 16 also introduces Cache Components, built around a new "use cache" directive that you enable explicitly in your config:

const nextConfig = {
  cacheComponents: true,
};

export default nextConfig;

The important shift here is philosophical as much as technical: caching in Next.js used to be implicit — the framework made decisions about what to cache and when, and developers had to learn its rules to predict behavior. Cache Components flip that. All dynamic code in a page, layout, or API route now executes at request time by default; caching only happens where you explicitly opt in with "use cache". That's a more predictable model, and it completes the story of Partial Prerendering (first introduced back in 2023) — letting you mix statically-fast page shells with dynamically-rendered sections without the old all-or-nothing choice between fully static and fully dynamic rendering.

New caching APIs worth knowing

Alongside Cache Components, the caching API surface got more precise. revalidateTag() now requires a cacheLife profile as its second argument to enable stale-while-revalidate behavior:

import { revalidateTag } from 'next/cache';

revalidateTag('blog-posts', 'max');       // recommended for most cases
revalidateTag('news-feed', 'hours');
revalidateTag('products', { expire: 3600 });

Two new Server Actions-only APIs round this out: updateTag(), which gives you read-your-writes semantics — expiring and immediately reading fresh data in the same request, ideal for forms and settings pages where a user needs to see their change reflected instantly — and refresh(), which refreshes uncached data only (notification counts, live metrics) without touching the cache layer at all.

This month's addition: smarter Turbopack chunking

On September 3, 2026, the Next.js team shipped experimental chunking controls for Turbopack, aimed specifically at large sites. The pitch is straightforward: better control over how JavaScript gets split into chunks means faster page loads and more code sharing across pages — the kind of optimization that matters more as a codebase grows past the point where default bundling heuristics stay optimal. If you're running a large Next.js site and haven't looked at Turbopack's chunking options yet, this is the update that makes it worth a look.

Breaking changes to check before you upgrade

This is the part that actually causes upgrade pain, so it's worth reading closely if you're still on Next.js 15 or earlier:

Node.js 20.9+ is now required — Node 18 support is gone, and TypeScript 5.1+ is now the minimum.
Async params and cookies are mandatory. Synchronous access to params, searchParams, cookies(), headers(), and draftMode() no longer works — everything needs await.
middleware.ts is deprecated in favor of proxy.ts — same logic, renamed export, clearer signal that it defines your app's network boundary. The old filename still works for now but is on its way out.
next lint is gone — next build no longer runs linting at all; use ESLint or Biome directly. A codemod (npx @next/codemod@canary next-lint-to-eslint-cli .) handles most of the migration automatically.
AMP support is fully removed, along with serverRuntimeConfig/publicRuntimeConfig (use environment variables instead).
Image defaults changed — images.minimumCacheTTL jumped from 60 seconds to 4 hours, and the default quality set narrowed to just [75].

For most of this, the automated upgrade path handles the mechanical parts: npx @next/codemod@canary upgrade latest will get you most of the way there, but budget real time to manually verify anything touching middleware, image config, or synchronous param access — those are the changes most likely to fail silently rather than throw a clear build error.

Should you upgrade now?

If you're starting a new project, there's no reason not to start on Next.js 16 — Turbopack-by-default and the simplified create-next-app flow (App Router, TypeScript, Tailwind, and ESLint out of the box) make it the obvious starting point. If you're maintaining an existing Next.js 15 app, the calculus is more about your team's bandwidth than urgency: nothing about staying on 15 is unsafe short-term, but the breaking changes list only grows the longer you wait, and Turbopack's build-speed gains compound daily for a team that upgrades sooner rather than later.