Last month we published a preview release of 16.3 that let you try out SPA-like navigations, better AI tooling, and a much less memory-hungry dev server.
Today, we're excited to announce that Next.js 16.3 is here!
This release is packed with improvements for all existing Next.js apps:
next build can use TypeScript 7 for type checking.[lang] from any Server Component.It also includes Instant Navigations, an opt-in suite of tools that brings the responsiveness of client-driven SPAs to Next.js, without sacrificing the benefits that come with its server-driven model:
The behaviors behind Instant Navigations will become the default in a future major version, as they're part of our work over the last year to simplify Next.js back to its roots: dynamic by default, with no hidden or implicit caching.
16.3 also includes experimental features you can try today, such as the Rust-based React Compiler and network resilience.
This is our biggest update to the framework since Next.js 16.0 came out last November, and we can't wait for you to try it.
Upgrade by installing the latest version of next from npm:
...and keep reading to learn about everything that's new!
Next.js 16.3 includes improvements for all existing projects, including lower dev server memory usage, faster rendering, and better runtime performance, all with zero changes to your application code.
We recommend all apps upgrade to 16.3 to start getting these benefits today.
In 16.3, Turbopack uses up to 90% less memory when running next dev. The reduction comes from two new features that are now enabled by default: disk caching for dev (first introduced in 16.1), and memory eviction.
We've been hearing great reports from early adopters, and we're excited to bring these performance improvements to all Next apps.
Memory usage after compiling 50 routes
vercel.com (dashboard)~90% smaller
Before
21.5 GB
After
2 GB
nextjs.org~82% smaller
Before
4,600 MB
After
840 MB
Learn more about Turbopack's new memory eviction features.
The disk caching feature that's been speeding up dev since 16.1 now works with next build and is enabled by default. We've been dogfooding this in production at Vercel for months and are seeing some projects with 5.5x faster builds on CI.
Turbopack compile time for `next build`
nextjs.org~2.3× faster
Cold
21s
Cached
9.2s
vercel.com/home~1.4× faster
Cold
66s
Cached
46s
vercel.com/geist~5.5× faster
Cold
30s
Cached
5.5s
Learn more about setting up Turbopack's new FileSystem Cache.
Typescript 7 was released last month, which is a 10x faster native port of TypeScript with much faster type checking.
To start using TypeScript 7 for type checking during next build, just bump your project's local dependency:
Learn more about configuring TypeScript's CLI in Next.js.
We replaced web streams with native Node.js streams in the App Router rendering layer, removing the overhead of converting between the two during server-side rendering.
In our benchmarks, apps handle up to 22% more requests under load, with no changes to application code.
Requests handled under load
App Router server-side rendering~22% more
Web streams
baseline
Node.js streams
+22%
Read the native Node.js streams PR for more details.
AI coding agents now automatically read documentation that matches your project's version of Next.js.
Running next dev writes and maintains a version-matched AGENTS.md block that points directly to the bundled docs in your project's local node modules. With that knowledge now reaching agents directly, we're retiring our earlier Skills that existed solely to bring current documentation to your apps.
Learn more about setting up Next.js for AI coding agents.
In 16.3, prefetches below a certain payload size are automatically bundled together to reduce the overall amount of prefetch requests your app makes.
Prefetches for larger shared segments still remain separate, so they can be reused across multiple routes.
Learn more about prefetch inlining.
Immutable static assets can now be reused across deployments. Since they're immutable, they cannot suffer from issues related to skew.
Learn more about immutable static assets.
Previously, React error boundaries in Next.js interfered with application code that called notFound or redirect. They also could only reset client-side state, and gave you no way to retry Server Components that failed during rendering.
In Next.js 16.3, you can use catchError to define a custom error boundary that doesn't interfere with notFound or redirect:
The boundary also receive a retry() function that you can call to refetch the boundary's children, which can include rerendering any Server Components.
Learn more about custom error boundaries.
Turbopack now supports loading multiple modules from the file system using the Vite-compatible import.meta.glob API, which brings hot-module reloading and other benefits to Server Components that read from local files:
Learn more about glob imports.
Previously, the only way to access a dynamic route's params was to pass them down as props from the route's page.
This led to excessive prop-drilling for params defined above the root layout, which are effectively global and therefore likely to be used throughout your component tree.
Next.js 16.3 introduces a new feature for easily accessing these root params from any Server Component, without the need for passing props:
This makes it much more ergonomic for things like internationalization, where many shared utilities and deeply nested components need access to the current language. Additionally, root params also work inside of use cache scopes.
They're currently supported in Server Components, and we're planning on adding support for route handlers and Server Actions in a future release.
Learn more about root params.
So that's what's new for every app that upgrades today. But 16.3 includes an exciting set of opt-in features that are paving the way for the next major version of the framework, and we're excited to dig into those next.
Over the past year, we've been working on fixing the most frustrating things about building with Next.js.
Server Components helped apps ship less JavaScript and avoid network waterfalls, but they made navigations feel slow. The caching model was implicit, confusing, and not helpful for dynamic apps. Prefetching was too aggressive and costly.
Last November, we introduced a new caching primitive to the framework: the 'use cache' directive. It's more explicit and composable than our previous server-side caching APIs, and now, it also brings client-side caching to Next.js for the first time.
We've been building on this primitive to address the navigation, caching, and prefetching problems above, and we ended up with a simpler, more powerful programming model. Server Components and Suspense are still the two primary building blocks, and 'use cache' now integrates with them in a way that lets you build apps that are static, dynamic, or anywhere in between.
For a deeper dive on these new behaviors, read last month's announcement of Instant Navigations.
In 16.3, you can start using building with all these new features by enabling two flags:
And if you have existing projects to upgrade, you or your agent can migrate an app to Cache Components.
Here's a look at what's getting better in Next.js.
While Server Components made Next.js apps faster at fetching data and rendering complete pages, apps built with prior versions of Next.js often felt less responsive than their client-driven counterparts (like SPAs), since those apps could render instant loading states without fetching from the server whenever you clicked a link.
It was possible to do this using separate loading.tsx files for each route, but it was far too easy to forget one and end up with a slow navigation.
We've fixed this by letting components that render dynamic UI either define inline loading states with Suspense, or mark part of their UI as prerenderable with 'use cache'.
In either case, Next.js can extract this UI and load it into the client prior to a navigation, making your app feel as snappy as an SPA once users start clicking around it.
To ensure you don't miss a slow page, the Next.js DevTools now include Instant Insights, which surfaces any navigations you encounter that are not instant:
The new Instant Insights panel automatically surfaces slow navigations
Prefetching that UI ensures your server-rendered app always has some UI ready to show the moment a user clicks a link, similar to how you would model loading states in an SPA.
Each insight also provides a prompt that teaches your agent how to apply your chosen fix.
Learn more about Instant Insights.
Prior to 16.3, prefetching in Next.js was limiting: you could either define a reusable loading shell with loading.tsx, or opt-in to aggressive full-page prefetching with <Link prefetch={true}>. Many apps suffered from these implicit and restrictive APIs, and ended up with blocking navigations on link clicks as a result.
To fix this, 16.3 adds a new prefetching behavior we call Partial Prefetching. Next.js can extract reusable loading shells from any route's UI, and per-link prefetching via <Link prefetch={true}> can include as much or as little content from the target page as you like.
Learn how you or your agent can adopt Partial Prefetching in your app.
16.3 brings a new kind of Incremental Static Regeneration to dynamic, personalized apps. When you prerender only some of a route's pages at build time with generateStaticParams, the rest of the page faced a tradeoff. They could show a loading shell but never get prerendered, or skip the shell and block the first visitor.
Now you get both. A page you don't prerender serves an instant loading shell on its first visit, then upgrades to the fully prerendered page in the background. Every later visitor gets the final content from the cache.
We're also exploring an API to control how often a page upgrades, for example based on traffic.
Learn more about Incremental Static Regeneration with Cache Components.
Because Next.js disables prefetching in development, it can be hard to understand exactly what a user will see during a particular navigation's loading sequence.
The new Navigation Inspector lets you pause page loads and client-side navigations at the shell, so you can see exactly what loading state the user would see:
See our documentation on visualizing loading states with the Next.js DevTools.
Another common failure mode is a page that navigates instantly today becoming slow tomorrow. Maybe a component that reads cookies() gets added to a shared header and de-opts the route to request-time rendering, or a <Suspense> boundary moves during a refactor and part of the page starts blocking. Either way, UI that used to appear immediately no longer does.
The new instant() test helper lets you write Playwright tests that assert exactly what content should be instantly visible during a navigation. The test fails whenever the instant UI changes, no matter the cause:
Learn more about writing tests with the instant test helper.
That's everything that's new with Instant Navigations! We're excited for you to try out these new features and hear what you think.
Lastly, there's a few new experimental features shipping with 16.3.
Alongside the stable release, 16.3 ships a few experimental features you can opt into today behind configuration flags. They're still evolving, so let us know how they're working for you in the Next.js 16.3 feedback discussion.
The React Compiler optimizes your components at build time so you don't have to hand-tune memoization.
Until now, enabling the React Compiler meant running it through Babel in Node.js. The experimental Rust port instead runs directly inside Turbopack, avoiding the extra work of generating and reparsing code.
Enable the compiler and opt into the Rust version in your Next.js config:
In tests against large apps like v0, the Rust path cut the time from next dev to a ready page by 34% on a cold build and 46% on a warm one. These gains assume you've moved off Babel entirely. If you still run Babel for other transforms, the Rust compiler helps, but the gain is smaller.
Time from `next dev` to a ready page on v0
Cold build~34% faster
Babel
baseline
Rust
-34%
Warm build~46% faster
Babel
baseline
Rust
-46%
Learn more about the Rust React Compiler.
When the network drops, a soft navigation, data fetch, or Server Action normally throws. With experimental.useOffline enabled, Next.js keeps it pending instead and retries once the connection returns. Enable the flag in your Next.js config:
Because Partial Prefetching already caches a route's shell on the client, a prefetched route still renders that shell when you navigate to it offline, and its data streams in once you reconnect.
A new useOffline hook reports when the app is offline, so you can show the user what's happening:
Read our guide on handling connectivity drops.
We hope you're excited to try out Next.js 16.3!
Upgrade today:
And share your feedback to help shape the future of Next.js:
Next.js is the result of the combined work of thousands of individual developers. This release was brought to you by:
Huge thanks to @denesbeck, @ztanner, @ijjk, @lllomh, @devjiwonchoi, @lukesandberg, @wbinnssmith, @sokra, @unstubbable, @timneutkens, @feedthejim, @gnoff, @abhishekmardiya, @icyJoseph, @mischnic, @mmastrac, @acdlite, @eps1lon, @JamBalaya56562, @bgw, @gaojude, @bgub, @remcohaszing, @aurorascharff, @VedantMadane, @fireairforce, @dagecko, @ctate, @banchichen, @andrewimm, @wwenrr, @TooTallNate, @hamidrezahanafi, @hamedniroomand, @sleitor, @Badbird5907, @MukundaKatta, @styfle, @SukkaW, @awo00, @christopherkindl, @GuinsooRocky, @maximecolin, @lubieowoce, @zana-abdi2002, @samselikoff, @rishishanbhag, @armando-andre, @tim123abc, @publictheta, @unclebay143, @yavorpunchev, @kakadiadarpan, @SyMind, @igorbabko, @sampoder, @StanislavKozachenko, @kristiyan-velkov, @huozhi, @RazinShafayet2007, @SJvaca30, @danyalahmed1995, @karlhorky, @MikhailStn, @ifer47, @niketchandivade, @gilest, @jahanzaib-iqbal-dev, @owenpearson, @davidgg, @fhfournier, @parkhojeong, @gaearon, @TariqulislamTuhin, @thsid, @jimmyhmiller, @Partha-Shankar, @M4cM4rco, @chippleh1392, @Pranav18M, @marcoshernanz, @manoraj, @ankurdotio, @WildChargerTV, @ZaforAbdullah, @wasim-builds, @petehunt, @DavidIlie, and @adhamfayrouzamf for helping!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。