Next.js 16 Is Here - What Developers Need to Know

Next.js 16 landed on 21st October 2025, and it is one of the most significant releases the framework has seen since the introduction of the App Router. Turbopack is now the default bundler, caching has been completely rethought, middleware has been renamed and repositioned, and React 19.2 brings new capabilities to the table.

As a team that builds with React and Next.js, we have been tracking these changes closely through the beta period. Here is what matters most and what you need to think about if you are planning an upgrade.

Turbopack Is Now the Default

This is the headline change for developer experience. Turbopack, the Rust-based bundler that has been in development for several years, has graduated from experimental to stable and is now the default bundler for all Next.js projects. You no longer need to opt in. Every new project and every existing project that upgrades will use Turbopack automatically.

The performance improvements are substantial. Production builds are 2-5x faster, and Fast Refresh in development is up to 10x faster. For teams working on large applications, this translates directly into less time waiting and more time building. By the time of the stable release, over 50% of development sessions on Next.js 15.3+ were already running on Turbopack.

If you have a custom webpack configuration, you can still use webpack by passing the --webpack flag to next dev or next build. But the direction of travel is clear, and teams should be thinking about migrating their webpack configurations sooner rather than later.

Alongside the stable release, Turbopack File System Caching is available in beta. This stores compiler artifacts on disk between development server restarts, making subsequent startups significantly faster on large projects. It is opt-in for now but already being used across Vercel's internal applications.

Cache Components Replace Implicit Caching

If you have worked with the App Router in Next.js 13, 14, or 15, you will know that caching behaviour has been one of the most debated aspects of the framework. Previous versions cached aggressively by default, which caught a lot of developers off guard. Next.js 16 takes a fundamentally different approach.

Cache Components introduce explicit, opt-in caching through a new "use cache" directive. All dynamic code now executes at request time by default. If you want something cached, you explicitly mark it. This is a much better mental model and aligns with what most developers expect from a full-stack framework.

The "use cache" directive can be applied at the page level, the component level, or the function level, and the compiler automatically generates cache keys wherever it is used. This also completes the story of Partial Pre-Rendering, which was introduced back in 2023. With Cache Components, you get granular control over which parts of a page are static and which are dynamic, without the all-or-nothing approach of previous versions.

The previous experimental.ppr flag has been removed in favour of the new cacheComponents configuration option. If you were experimenting with PPR, you will need to update your configuration.

Goodbye middleware.ts, Hello proxy.ts

This is the change that will require the most immediate attention for existing projects. middleware.ts has been deprecated and replaced by proxy.ts. The function logic stays the same, but you need to rename the file and change the exported function name.

This is not just cosmetic. The rename reflects a deliberate architectural decision. proxy.ts runs on the Node.js runtime rather than the Edge runtime, which gives you access to the full Node.js API. The previous middleware approach running on Edge had limitations that led to workarounds, unexpected behaviour, and in one notable case earlier in 2025, a security vulnerability where authentication in middleware could be bypassed under specific conditions.

The migration is straightforward for most projects: rename the file, rename the exported function to proxy, and update any configuration flags like skipMiddlewareUrlNormalize to skipProxyUrlNormalize. The automated codemod handles most of this. If you specifically need Edge runtime behaviour, middleware.ts still works for now, but it is deprecated and will be removed in a future version.

React 19.2 and the Compiler

Next.js 16 ships with React 19.2, which brings several notable additions. The <Activity> component allows you to control component visibility while preserving state, which is useful for tab interfaces or pre-rendering content the user is likely to visit. useEffectEvent creates stable callbacks that always access the latest props and state without adding them to the dependency array. And there is early support for the View Transitions API, enabling smooth animated page transitions with minimal code.

The React Compiler also reaches stable support in Next.js 16. It automatically memoises components, reducing unnecessary re-renders without any manual code changes. It is not enabled by default as it relies on Babel and increases compile times, but it is worth evaluating for applications with complex client-side component trees.

Routing and Navigation Improvements

The routing system has been overhauled with two key improvements. Layout deduplication means that when prefetching multiple URLs that share a layout, the layout is downloaded once rather than separately for each link. If you have a page with 50 product links sharing a layout, that is a significant reduction in network transfer.

Incremental prefetching means Next.js now only prefetches the parts of a page not already in cache, rather than fetching entire pages. The prefetch cache is smarter too, cancelling requests when links leave the viewport and re-prefetching when data is invalidated. These changes require no code modifications and should improve performance across all applications.

Breaking Changes to Be Aware Of

The minimum Node.js version is now 20.9.0, dropping support for Node.js 18. If your deployment environment or CI pipeline is pinned to an older version, this needs addressing before you upgrade. The minimum TypeScript version is 5.1.0.

Route parameters and search parameters are now fully asynchronous. If you were accessing params or searchParams synchronously, you will need to refactor those calls. The next/legacy/image component has been fully removed in favour of next/image. And next lint has been deprecated.

The good news is that the automated codemod at npx @next/codemod@canary upgrade latest handles the majority of these changes. Community feedback suggests most upgrades from Next.js 15 are straightforward, with some developers reporting large applications migrated in a matter of days with the help of codemods.

Our Take

Next.js 16 feels like the release where several years of architectural decisions come together. Turbopack graduating to stable removes the biggest friction point in the developer experience. The shift to explicit caching resolves one of the most common complaints about the App Router. And the move from middleware to proxy shows the team is willing to make breaking changes when they result in a better and more secure foundation.

If you are starting a new project, there is no reason not to use Next.js 16. If you are upgrading an existing application, the migration path is well documented and the codemods do most of the heavy lifting. The main thing to check is your Node.js version and any custom webpack configuration you might have.

If you are planning an upgrade or starting a new Next.js project and want some guidance, get in touch. We are always happy to talk through the best approach for your specific situation.