Next.js Blog

Making Navigations Instant in v0

Invalid Date

Last month we shared a preview of some new tools in Next.js 16.3 that bring instant page navigations to apps built with React Server Components.

We've been adopting these tools in v0, Vercel's full-stack coding platform, and we shared this graph showing how much faster navigations got in production:

Page navigation times for v0 in production

Impressively, these results came from a coding agent using a new Skill to write failing tests, fix the slow navigations, and verify each route.

We'll go over how those tests can assert against slow navigations and how the Skill works.

But first, let's look at the approach Next.js 16.3 takes to making apps like v0 feel snappy, without needing to move any data-fetching or rendering code to the client.

Prerendering for dynamic apps

Previously, Next.js offered two main tools to ensure your app would have instant navigations:

Either you could statically prerender pages at build time (which is impractical for dynamic apps with personal data)
Or you could mark links as fully prefetched (which can be expensive and strain your servers)

This left dynamic, personalized apps like v0 without a good strategy for achieving instant navigations.

Next.js 16.3 fixes this by letting you prerender dynamic content while users browse your app, and caching that content entirely in the browser.

Components that render dynamic, personalized UI can now either define a loading state with Suspense, or mark part of that UI as prerenderable with 'use cache'. In either case, Next.js can extract this UI and load it into the client before a navigation, without needing to fully render the target page or keep that UI static.

This is the first time Next.js has given dynamic apps a way to take advantage of the technology behind Partial Prerendering. Here's what an engineer working on v0 had to say about it:

Slack

Martin Sione8:32 PM

yeah so much @jude.gao for leading this effort. for the blog/case study i think it'd be nice to make it clear that instant != ppr and also that it's much more achievable. even myself working here thought achieving instant would be a much bigger effort than it ended up being partially because i was thinking we'd have to make an effort comparable to doing [static] ppr

So, dynamic apps can partially prerender pages at runtime. And that's how they can achieve instant navigations, while still shipping minimal code to the browser.

Now you might be thinking that the only way to verify a navigation is instant would be to refactor your code, run your app, and then click a link to see for yourself. But one of the most novel things about Next.js 16.3 is that it ships with a new primitive that lets you or an agent know that you've made a route instant.

Thanks to this new primitive, agents are perfectly suited to achieve instant navigations in an existing app all on their own.

And that's exactly how we made v0 instant.

Using loops to make v0 instant

To bring these new capabilities to v0, we used an agent running in a loop. For each slow navigation, it wrote a failing test, applied a fix, re-ran the test, and tried again until it passed.

For the loop to run on its own, it needed:

A verifiable goal. A failing test, which terminated the loop once it passed.
Guardrails. A Skill with proven patterns that move the code closer to the goal.
Real feedback. Production metrics that confirm a successful loop had the intended effect.

   Define the goal, e.g. "Make the navigation from '/' to '/chats' instant"
              │
              ▼
   Write it as a test, and confirm it fails on the current app
              │
              ▼
   Apply a fix using patterns from the Skill ◀───┐
              │                                  │
              ▼                                  │  still not instant
   Rebuild and re-run the test               ────┘
              │
              ▼  instant
   Ship the test to CI to prevent regressions

The hardest part of this loop is writing a failing test for something fuzzy like "Make sure this navigation is instant".

Fortunately, Next.js 16.3 had exactly what we needed.

A test for "fast"

Next.js 16.3 includes an instant() test helper for Playwright.

This helper lets you write tests that pause a navigation and assert which parts of the UI are instantly visible to the user, without any network request:

e2e/navigation.spec.ts

import { expect, test } from '@playwright/test';
import { instant } from '@next/playwright';
 
test('navigating to the chats page is instant', async ({ page }) => {
  await page.goto('/');
 
  await instant(page, async () => {
    await page.getByRole('link', { name: 'Chats' }).click();
    await expect(page.getByTestId('app-title')).toBeVisible();
  });
});

If the expected content was blocked by the network, the test would fail.

With it, we were ready to kick off the loop.

Running the loop on v0

We now had everything we needed to fix slow navigations in v0.

Here's what our process looked like:

Gather the critical user journeys that are slow. We knew some important navigations in v0 were slow (clicking New Chat from the homepage, navigating around settings, and viewing your profile), so we focused on these. Next.js 16.3 also includes a new Instant Insights feature, which automatically surfaces any non-instant routes during development.
Write the failing tests. The agent wrote a failing test for each of our navigations using the instant() helper. On its own, the agent with the Skill will do its best to capture which part of the UI should be instantly visible, but you can also steer it to include specific parts, for example the "Chats" label on v0's new chat page.
Refactor until all the tests pass. The agent used the patterns in the Skill to apply idiomatic changes to our Next.js code, and kept working until each test was passing. In some cases this involved larger refactors that touched multiple features, which is why using a loop is so powerful.
Commit the changes and the tests. The tests not only helped the agent fix the problematic routes during the loop; they also ensured that future changes would never make these navigations slow again. So, we kept them in the project to run alongside the rest of our test suite in CI.

But what did the changes look like?

In many cases, unblocking a slow navigation just meant moving some dynamic data access below a Suspense boundary, and allowing the rest of the page's content to be included in the shell.

Here's an example:

app/settings/workspace/page.tsx

- export default async function WorkspacePage() {
-   const session = await getServerSession();
-   const team = await fetchTeam(session);
+ export default function WorkspacePage() {
    return (
      <SettingsPageLayout>
        <SettingsHeader title="Workspace" />
-       <TeamSettings team={team} />
+       <Suspense fallback={<WorkspaceSkeleton />}>
+         <WorkspaceContent />
+       </Suspense>
      </SettingsPageLayout>
    );
  }
 
+ async function WorkspaceContent() {
+   const session = await getServerSession();
+   const team = await fetchTeam(session);
+   return <TeamSettings team={team} />;
+ }

In other cases, there were larger refactorings that needed to happen, for example moving a blocking dependency out of the root layout and into the components that were using it.

Regardless of the changes needed, the agent was able to apply modern Next.js best practices using the patterns included in the Skill.

Fast, forever

By the end, the logged-in and logged-out versions of the homepage, the chat detail page, and every subpage under settings went from blocking to instant, thanks to the agent's work.

We ended up with 16 new tests that captured these results in our test suite. These tests guard against regressions as the codebase continues to change, which is especially important as agents make changes that could undo these optimizations.

Try it yourself

You can start taking advantage of Instant Navigations in your own Next.js apps today.

For existing Cache Components apps that have slow navigation sequences you want to polish, the next-cache-components-optimizer Skill has everything you need to run the same loop that we did on v0.

Install it:

npx skills add vercel/next.js --skill next-cache-components-optimizer

...then prompt your agent with a navigation you want to improve:

Prompt

Make the navigation from '/' to '/chats' instant using the next-cache-components-optimizer skill.

For apps that are not yet on Cache Components, the next-cache-components-adoption Skill will guide your agent through the process of migrating an existing app.

To see the docs for both skills, check out our guide on using AI agents with Next.js.

Why frameworks matter in the era of agents

Anyone who's been building with agents knows the importance of deterministic tests. The more your test suite captures about how you want your app to behave, the better your agents will be able to change and refactor it.

But certain behaviors can be hard to test. Everyone knows the difference between an app that feels polished and snappy versus one that feels janky and unresponsive, but this difference can be hard to capture in a deterministic way.

The instant() test helper is a novel example of how these fuzzier aspects of a high-quality app can be turned into something deterministic. Since it's deeply integrated with the framework, the helper is able to verify things about your app's UX that a generic test helper never could.

We think a verifier like this is one of the most useful things a framework can ship in the agent era, and we plan to continue adding more of them to Next.js.

It's also evidence that even with agents authoring so much of our code, frameworks still matter. An agent can write any code it wants to, but a framework's job is to constrain it so it produces better UIs than it would on its own.

That's the future we're building towards with Next.js.

Feedback and Community

Try it on your own app, and let us know how it goes:

Next.js 16.3

Invalid Date

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:

Less memory usage in dev. Long dev sessions now use up to 90% less RAM.
Faster builds. Repeat builds can read unchanged artifacts from cache.
Faster type checking. next build can use TypeScript 7 for type checking.
Faster server-side rendering. Next.js now handles up to 22% more requests under load.
Versioned docs for AI agents. Coding agents read version-matched docs with no setup.
Fewer prefetch requests. Links trigger fewer requests by bundling smaller payloads.
Better caching for static assets. Immutable assets can optionally be reused across deploys.
Custom error boundaries. Recover from server errors by re-fetching failed data.
Built-in glob imports. Import multiple files with a new Turbopack API.
Root params. Easily access root-level params like [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:

Instant Insights. A new devtool that automatically surfaces slow navigations.
Partial Prefetching. Fine-grained control over how much content a link should prefetch.
Better Incremental Static Regeneration. URLs omitted from build-time prerendering can now serve an instant loading shell to the first visitor.
Navigation Inspector. A new devtool that lets you visually inspect a navigation's loading shell.
Playwright test helper. Write regression tests that prevent refactors from making a navigation slow.

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:

terminal

npm install next@latest

...and keep reading to learn about everything that's new!

Improvements for today's apps

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.

Less memory usage in dev

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.

Faster builds

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.

Faster type checking with TypeScript 7

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:

pnpm add -D typescript@^7

Learn more about configuring TypeScript's CLI in Next.js.

Faster server-side rendering

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.

Versioned docs for AI agents

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.

Fewer prefetch requests

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.

Better caching for static assets

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.

Custom error boundaries

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:

app/my-error-boundary.tsx

'use client';
import { catchError, type ErrorInfo } from 'next/error';
 
function ErrorFallback(props: { title: string }, { error, retry }: ErrorInfo) {
  return (
    <div>
      <h2>{props.title}</h2>
      <p>{error.message}</p>
      <button onClick={() => retry()}>Try again</button>
    </div>
  );
}
 
export default catchError(ErrorFallback);

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.

Built-in glob imports

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:

app/blog/page.tsx

import matter from 'gray-matter';
 
export default function Page() {
  // .md needs a loader registered in next.config.js
  const posts = import.meta.glob('./posts/*.md', { eager: true });
 
  return (
    <ul>
      {Object.entries(posts).map(([path, mod]) => {
        const { data } = matter(mod.default);
        return <li key={path}>{data.title}</li>;
      })}
    </ul>
  );
}

Learn more about glob imports.

Root params

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:

app/[lang]/posts/[slug]/page.tsx

import { lang } from 'next/root-params';
 
export default async function PostPage(
  props: PageProps<'/[lang]/posts/[slug]'>,
) {
  const { slug } = await props.params;
  const language = await lang();
 
  return (
    <article>
      <p>Language: {language}</p>
      <p>Post: {slug}</p>
    </article>
  );
}

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.

Instant Navigations

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:

next.config.ts

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};
 
export default nextConfig;

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.

Instant Insights

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.

Partial Prefetching

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.

Better Incremental Static Regeneration (ISR)

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.

Playwright test helper

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:

e2e/instant-navigation.spec.ts

import { expect, test } from '@playwright/test';
import { instant } from '@next/playwright';
 
test('product title is available immediately', async ({ page }) => {
  await page.goto('/products/shoes');
 
  // Assert what's visible without waiting for network
  await instant(page, async () => {
    await page.click('a[href="/products/hats"]');
    await expect(page.locator('h1')).toContainText('Baseball Cap');
    await expect(page.getByText('Checking inventory...')).toBeVisible();
  });
 
  await expect(page.getByText('12 in stock')).toBeVisible();
});

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.

Experimental features

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.

Rust-based React Compiler

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:

next.config.ts

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};
 
export default nextConfig;

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.

Network resilience

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:

next.config.ts

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  experimental: {
    useOffline: true,
  },
};
 
export default nextConfig;

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:

app/offline-banner.tsx

'use client';
 
import { useOffline } from 'next/offline';
 
export function OfflineBanner() {
  const isOffline = useOffline();
 
  if (!isOffline) return null;
 
  return <div>You're offline. Retrying when you reconnect.</div>;
}

Read our guide on handling connectivity drops.

Feedback and Community

We hope you're excited to try out Next.js 16.3!

Upgrade today:

terminal

npm install next@latest

And share your feedback to help shape the future of Next.js:

Contributors

Next.js is the result of the combined work of thousands of individual developers. This release was brought to you by:

The Next.js team: Andrew, Aurora, Dan, Hendrik, Janka, Jiwon, Joseph, Josh, Jude, Pete, Sam, Sebbie, Tim, and Zack.
The Turbopack team: Andrew, Benjamin, Jimmy, Luke, Niklas, Tobias, and Will.

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!

Security

Invalid Date

The first monthly security releases are now available. Upgrade to 16.2.11 (Active LTS) or 15.5.21 (Maintenance LTS) now to address 4 HIGH and 5 MEDIUM severity vulnerabilities.

Security

Invalid Date

The first monthly security releases are now available. Upgrade to 16.2.11 (Active LTS) or 15.5.21 (Maintenance LTS) now to address 4 HIGH and 5 MEDIUM severity vulnerabilities.

Turbopack: What's New in Next.js 16.3

Invalid Date

As the Next.js 16.3 Preview nears a stable release, we're sharing a series of posts about what's inside. Our previous posts cover new Instant Navigation features and the latest AI improvements. This third post details the latest improvements to the Turbopack bundler within Next.js.

With Next.js 16.3, Turbopack's latest stable release focuses on compiler performance. Many of the newest features are centered around reducing CPU and Memory usage, speeding up build times, and improving runtime experience.

Reducing dev server memory usage by up to 90%
Persistent file system cache for faster builds
Experimental Rust React Compiler support
import.meta.glob API support
Faster HMR and dev startup

Reducing memory usage in dev mode

Turbopack's core design is focused on incremental compilation. By caching the work it previously did, it avoids recompiling files that haven't changed. When developing large Next.js applications, this means compile time is proportional to the size of your changes, not the size of your route.

In pursuing this design, we made a very deliberate trade-off: caching more results in memory, for reduced CPU usage. Since Turbopack first launched, though, memory usage has been at a premium. Coding agents, IDEs, typecheckers, and linters all run at dev time, and each consumes a significant chunk of system memory. Over the last three months, the Turbopack team has been committed to reducing its contribution to system memory pressure. With an upgrade to 16.3, developers should immediately see less memory usage for long-running dev sessions.

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

Much of this was achieved through small incremental wins: compressing data structures and avoiding storing data longer than was necessary. The biggest win, though, comes from a new ability to evict much of the in-memory cache. Leveraging the file-system persistence feature that was first introduced in Next.js 16.1, Turbopack is able to remove cached results from memory. This avoids unbounded growth of memory in dev sessions, since the memory cache no longer holds onto every visited route.

Memory eviction requires the development filesystem cache to be enabled. In 16.3, both of these options are on by default. It can be disabled when investigating cache or development performance with the experimental turbopackMemoryEviction config value:

const nextConfig = {
  experimental: {
    turbopackMemoryEviction: false, // disables memory eviction, default value is 'auto'
  },
};

There is no single reduction percentage that applies to every application. Individual results depend on the size of the route graph, how much of it was touched during the development session, and how long the session was running.

File System cache for builds

Persisting the Turbopack memory cache to disk has been speeding up next dev sessions since the 16.1 release. After months of hardening in production with Vercel's own sites, the same persisted cache is now available for next build, enabled by default.

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

With persistent disk cache, builds can take advantage of previously computed work and reduce the time it takes to compile your static assets. When Turbopack sees the cache at the start of a build, it reads entries from disk before compiling any new changes.

The cache lives in .next/cache, so CI builds only get faster if that directory is restored between runs.

See the turbopackFileSystemCacheForBuild reference for the opt-out and the full set of options.

Experimental Rust React compiler

Next.js has provided stable support for the React Compiler since the first 16.0 release. Until now, the React Compiler has only been available as a Babel transform. On larger applications, we observed that it could slow down builds while waiting for JS execution resources. Recently, the React team published a native Rust port of the compiler, which we were quick to integrate into Turbopack.

Promising early tests against large React apps like v0 showed compilation wins of 20-50%, so we are releasing the native compiler integration as an experimental feature to drive more adoption.

To test out the Rust React Compiler, enable the compiler and use the experimental turbopackRustReactCompiler flag to use the native version:

const nextConfig = {
  // enable the compiler
  reactCompiler: true,
  experimental: {
    // use the Rust version, instead of the OG Babel one
    turbopackRustReactCompiler: true,
  },
};

There are many ways to configure the React Compiler for features like opt-in functionality. You can read the full documentation for more details.

`import.meta.glob`

Turbopack now supports the Vite-compatible import.meta.glob API:

const posts = import.meta.glob('./posts/*.mdx');

This API can import all modules that match this pattern, without hardcoding their names. The result is an object keyed by the matching file paths. By default, each value is an async function that loads the module:

for (const path in posts) {
  const post = await posts[path]();
}

Use eager: true to import each match immediately:

const posts = import.meta.glob('./posts/*.mdx', {
  eager: true,
});

The implementation also supports named imports, multiple patterns, negative patterns, custom search path, query strings for loaders, and generated TypeScript types.

This functionality is powered by Turbopack's file watcher. When a file is added to or removed from this match set, it will trigger recompilation in dev mode, so your site always reflects the latest changes. This API is perfect for fetching sets of similar documents, like product descriptions or blog posts. We also expect that library developers will benefit from this API existing across the broader JS ecosystem.

import.meta.glob is available as a Turbopack feature, and will not work for Next.js apps built with the --webpack option.

See the import.meta.glob reference for all of the available options.

HMR improvements

By analyzing the performance of Turbopack in large Next.js apps at Vercel, we identified a number of performance improvements that could benefit all Turbopack users. Much of that investigation centered around making HMR subscriptions more efficient. One significant change streamlined the tracking of chunks that are loaded on a page. By reducing multiple subscriptions to a single one, we were able to reduce dev server cold start by over 15% on complex apps.

This is only the beginning of our HMR resource investigations, and we expect to deliver more memory and cold-start improvements in future Next.js releases.

Smaller runtime size

Turbopack ships runtime code to every route that allows it to resolve modules and dynamically fetch new chunks. This also includes code for loading WebAssembly, workers, and top-level async modules. Not every Next.js application uses that functionality, though. Now Turbopack will only ship those features when they're needed, and avoids shipping extra runtime code the rest of the time.

Local PostCSS configuration

Monorepos may need different PostCSS transforms for different packages.

The experimental turbopackLocalPostcssConfig option lets Turbopack resolve the configuration closest to each CSS file before falling back to the project root:

next.config.ts

const nextConfig = {
  experimental: {
    turbopackLocalPostcssConfig: true,
  },
};

This allows package-level CSS to use a local configuration while application CSS continues to use the root configuration.

Compatibility and reliability

Next.js 16.3 rolls up all of the fixes from the 16.2 patch line and adds more improvements across module resolution, tracing, and HMR, including:

Correct file URLs for import.meta.url on Windows
Retry chunk fetching on failure
Better support for createRequire(new URL(..., import.meta.url))
Correct worker_threads URL resolution
Support for the module-sync export condition
Better errors when webpack loaders crash
CSS HMR fixes in Safari

Next.js 16.3: AI Improvements

Invalid Date

As the Next.js 16.3 Preview nears a stable release, we're sharing a series of posts about what's inside. The first post, Instant Navigations, covers the new rendering and prefetching primitives. This second post focuses on AI improvements.

Next.js has grown a lot since the App Router went stable, and more and more of that growth is driven by code written through agents like Claude Code, Cursor, and Codex.

What would Next.js look like if it were designed primarily for agent-driven development? We're not all the way there yet, but we're getting closer with every release. Next.js 16 added the DevTools MCP server, and Next.js 16.2 brought bundled docs and next-browser, an experimental CLI for letting agents drive a real browser.

In Next.js 16.3, we're extending this with:

Bundled docs through AGENTS.md: Keeps agents reading version-matched docs instead of their training data
First-party Skills: Skills that help agents drive multi-step workflows
Agent Browser with React introspection: Drive a real browser and inspect React state from agent-browser
Actionable errors: Labeled fix menus in the overlay and terminal for Instant Insights, with a Copy prompt button and per-rule docs written for agents
A smaller, more focused MCP server: New build diagnostics tools, knowledge-base tools retired
Docs as Markdown: Append .md to any docs URL for a plain Markdown version

Bundled docs through AGENTS.md

In our previous 16.2 release, we started bundling the Next.js documentation into your project so agents can read it locally. Projects created with create-next-app on 16.2 or later already point AGENTS.md to those docs.

In 16.3, next dev writes and updates that pointer automatically, so existing projects stay current as you upgrade. On 16.1 or earlier, run the agents-md codemod manually:

terminal

npx @next/codemod@canary agents-md

Here's what next dev inserts into your AGENTS.md:

AGENTS.md

<!-- BEGIN:nextjs-agent-rules -->
 
# This is NOT the Next.js you know
 
This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in `node_modules/next/dist/docs/` (resolved from this file's directory; in monorepos the `next` package may not be visible from the repo root) before writing any code. Heed deprecation notices.
 
This block is written and re-added by `next dev` — verify at `node_modules/next/dist/server/lib/generate-agent-files.js`. Removing it from a diff only re-creates the uncommitted change; committing it with your work keeps the tree clean.
 
<!-- END:nextjs-agent-rules -->

The block is only written when next dev detects an AI coding agent in the environment and the markers aren't already there. Anything outside the markers is preserved, and you can opt out with agentRules: false in next.config.ts. Commit the block as-is, even if it shows up as an uncommitted change.

First-party Skills

Skills give agents framework-specific context. You may have installed our earlier knowledge Skills from skills.sh, which covered App Router conventions and caching APIs. With the bundled docs now reaching agents through the managed AGENTS.md block, we're retiring those Skills. Run npx skills update to remove them from your installed set.

Skills are still useful for multi-step workflows that docs alone can't drive end to end. Next.js 16.3 adds three new first-party Skills for those.

`next-dev-loop`

The next-dev-loop Skill gives your coding agent access to the full development feedback loop. It can drive the browser, read the console, follow network requests, and inspect the React tree as it iterates.

/_next/mcp, the framework's view of routes, server logs, and compilation issues.
agent-browser, the browser's view of the DOM, console, network, and React tree.

The Skill requires agent-browser version 0.27 or later.

terminal

npx skills add vercel/next.js --skill next-dev-loop

Then prompt your agent with something like:

Prompt

After every edit, verify the page still works at runtime using the next-dev-loop skill.

Claude editing, compiling, reloading, and inspecting the result through next-dev-loop.

`next-cache-components-adoption`

The next-cache-components-adoption Skill turns Cache Components on in your project and works through the app one feature at a time, checking in with you at the boundaries so you stay in control of the scope. It works in one of two modes:

Incremental. Lands a single mechanical PR up front that opts every route out of validation, so you can ship features as you go in follow-up PRs.
Direct. Adopts every route in place on one branch.

The per-feature loop is the same in both: the Skill reads the actionable error, fetches the per-error docs page it links to, applies that fix to the route, then drives the browser through next-dev-loop to confirm the static shell renders the right content.

terminal

npx skills add vercel/next.js --skill next-cache-components-adoption

Then prompt your agent with something like:

Prompt

Adopt Cache Components in this project using the next-cache-components-adoption skill.

Claude turning Cache Components on and adopting routes one feature at a time.

`next-cache-components-optimizer`

The next-cache-components-optimizer Skill takes a target route or set of routes under Cache Components, turns the UI you want on screen at click time into a failing instant() test, and works it to green. It checks both ways a route reaches the user:

Initial load. Checks that the route's static shell renders immediately when someone visits the page directly.
Client-side navigation. Checks that the next page renders immediately when someone follows a link.

The passing test is committed along with the route refactoring to catch future regressions.

terminal

npx skills add vercel/next.js --skill next-cache-components-optimizer

Then prompt your agent with something like:

Prompt

Make the navigation from `/settings` to `/dashboard` instant using the next-cache-components-optimizer skill. The header and the project list should be part of the instant UI.

Claude diagnosing what keeps the page's content out of its static shell.

Since this post, the stable Next.js 16.3 release adds a fourth Skill, next-partial-prefetching-adoption, which turns on Partial Prefetching and works through your app until every link reuses a shared loading shell.

Agent Browser with React introspection

The experimental next-browser from Next.js 16.2 has merged into the general-purpose agent-browser CLI. Everything next-browser did is now in agent-browser, and it works beyond Next.js too.

Version 0.27 adds React DevTools introspection on top of the existing DOM, console, network, and Web Vitals access. Agents can list the component tree with react tree, inspect a single component with react inspect <fiberId>, profile re-renders with react renders start and stop, and see what's holding a render with react suspense --only-dynamic --json. The next-dev-loop Skill launches agent-browser with React DevTools enabled so these commands are available during verification.

To install or upgrade, run npm install -g agent-browser@^0.27. The React commands require --enable react-devtools at launch.

Actionable errors

With Cache Components enabled, an await on the server is a choice. Instant Insights presents that choice as an error with three specific fixes:

Stream the data behind a <Suspense> boundary
Cache it with "use cache"
Block the route with export const instant = false

These are product decisions with trade-offs. Picking the right one needs context, whether you or your coding agent is making the choice.

Instant Insights fix prompts

An Instant Insight presents the error with labeled fixes, with a Copy prompt button that packages the chosen fix into a paste-ready prompt for your coding agent. The prompt walks the agent through identifying the failing code, reading the matching error page, applying the canonical pattern, and verifying the result at runtime through the next-dev-loop Skill.

For example, say we hit an uncached fetch() call in a page. We pick Stream and click Copy prompt, and get:

The prompt your agent can use

Apply the [Stream] "Wrap in or move into Suspense" fix to the Next.js Insight raised in this project.
 
Steps:
 
1. Make sure you can drive a browser before you start. The fix isn't verified until you've reloaded the route and looked at what renders. If you don't already have browser tooling set up, install the next-dev-loop skill (https://www.skills.sh/vercel/next.js/next-dev-loop) first.
 
2. Identify the failing code in the error block below. It may be a data-access call, a hook call, a metadata or viewport export, or a component. Keep the fix focused on that code. If you think a related refactor (a sibling component, a shared layout, a wrapping boundary) would make the result meaningfully better, name it and check with the user before doing it — don't expand the scope silently.
 
3. Read the rule docs at https://nextjs.org/docs/messages/blocking-prerender-dynamic for the full Insight explanation, then read the fix section at https://nextjs.org/docs/messages/blocking-prerender-dynamic#wrap-in-or-move-into-suspense. Pick the pattern under "### Patterns" that matches the failing code, then read "### Gotchas" before editing — they list constraints that are easy to miss. Use the canonical imports and code shape from the page; don't improvise variations.
 
4. Apply the chosen pattern to the code identified in step 2. Don't narrate the change with new comments — the code should explain itself. Only leave a comment when the *why* isn't clear (e.g. a deliberate Block with a reason).
 
5. Verify the fix at runtime. The Insight clearing in the dev overlay confirms the build is happy, but not what actually renders. Reload the route in a browser and confirm the static shell still paints first and any new <Suspense> fallback resolves to its real content.
 
6. Check the shell isn't empty. A <Suspense> boundary placed too high (around the whole page body, or with `fallback={null}`) can leave the build reporting a shell while the shell itself contains nothing and everything streams. If that's what you see, pull the boundary down closer to the actual dynamic read.
 
7. If the fix touched shared code (a layout, a wrapper, a sidebar), re-check the sibling routes too — a shell-level change can fix one route and break another. A before/after capture of the affected routes is a useful sanity check: the visible UI may look the same (the fix often just changes what's in the shell vs streamed), but if anything regressed visually, you'll see it.
 
When you reply to the user, just summarize what you changed and why in plain prose. Don't echo this checklist back as headers, sections, or bullet lists labeled "Verification" or "Scope" — those are your internal steps, not the user's report.
 
## Error Type
Blocking Route
 
## Error Message
Route "/products/[slug]": Next.js encountered uncached data during prerendering or a navigation.
 
`fetch(...)` or `connection()` accessed outside of `<Suspense>` prevents the route from being prerendered or the navigation from being instant, leading to a slower user experience.
    at ProductPage (app/products/[slug]/page.tsx:52:32)
 
## Code Frame
  50 |   props: PageProps<"/products/[slug]">,
  51 | ) {
> 52 |   const featured = await fetch(`/api/products/${slug}`);
     |                                ^
  53 |
  54 |   return (
  55 |     <div className="space-y-4">
 
Next.js version: 16.3.0 (Turbopack)

Structured console output

The same fix menu shows up in the terminal during next dev, and next build emits it when an error stops a prerender. That means an agent reading errors from next build, CI logs, or any terminal session where the dev overlay isn't available still gets the same labeled fixes, linked to the matching section of the error page:

terminal

Error: Route "/products/[slug]": Next.js encountered uncached data during prerendering or a navigation.
 
`fetch(...)` or `connection()` accessed outside of `<Suspense>` prevents the route from being prerendered or the navigation from being instant, leading to a slower user experience.
 
Ways to fix this:
  - [stream] Provide a placeholder with `<Suspense fallback={...}>` around the data access
    https://nextjs.org/docs/messages/blocking-prerender-dynamic#wrap-in-or-move-into-suspense
  - [cache] Cache the data access with `"use cache"` (does not apply to `connection()`)
    https://nextjs.org/docs/messages/blocking-prerender-dynamic#cache-the-component-or-data
  - [block] Set `export const instant = false` to silence this error and allow a blocking route
    https://nextjs.org/docs/messages/blocking-prerender-dynamic#allow-blocking-route
    at ProductPage (app/products/[slug]/page.tsx:52:32)
  50 |   props: PageProps<"/products/[slug]">,
  51 | ) {
> 52 |   const featured = await fetch(`/api/products/${slug}`);
     |                                ^
  53 |
  54 |   return (
  55 |     <div className="space-y-4">

Error pages written for agents

The overlay and console show you which fix to apply. But a fix is a pattern with constraints, edge cases, and trade-offs that don't fit in an error message. So errors get their own page on nextjs.org/docs/messages, written for agents to read. The fix sections follow the same shape: the canonical Patterns, the Trade-offs against the other fixes, and the Gotchas an agent is likely to miss on a first attempt.

For example, our uncached fetch() call lands on blocking-prerender-dynamic, with our Stream choice at Wrap in or move into Suspense. This is the most common one. There are 10+ similar pages under /docs/messages, each with its own considerations. An agent applying the fix on its own can read the trade-offs and pick what fits.

Together, the Copy prompt button, the structured console output, and the per-rule docs pages give agents the context to write performant, idiomatic Cache Components code.

A smaller, more focused MCP server

The DevTools MCP server used to include its own Next.js knowledge base, along with upgrade and Cache Components helpers. With the bundled docs now serving that purpose, we've removed those tools from the MCP server, as we did with the knowledge Skills.

In 16.3, the MCP server adds two new compilation tools: get_compilation_issues for the whole project, and compile_route for a single route. Agents often run next build just to check whether the code compiles, which is overkill while you're still editing. These tools answer the same question from the running dev server, much faster.

Skills like next-dev-loop call the underlying /_next/mcp endpoints directly, so they work without any extra setup. To use these tools from your own agent client, add next-devtools-mcp to your .mcp.json. The client finds the running next dev automatically.

Docs as Markdown

Append .md to any Next.js docs URL to get the page as plain markdown. This works for any page on nextjs.org/docs, including the per-error pages. Clients that send an Accept: text/markdown header get the markdown version too.

The full index is at /docs/llms.txt, and /docs/llms-full.txt bundles all doc pages into a single file. Both follow the llms.txt convention, so any agent that already reads llms.txt for other tools can read Next.js docs the same way.

Feedback and Community

Share your feedback and help shape the future of Next.js:

Next.js 16.3: Instant Navigations

Invalid Date

Next.js 16.3 is almost here, and it's packed with a ton of improvements: better rendering under stress thanks to native Node.js streams, faster startup times in local dev, and deeper integration with agent-based workflows.

We'll be covering these features in the coming weeks as we prepare a stable release. But today, we'd like to focus on one new feature we're calling Instant Navigations — a suite of tools that bring the responsiveness of client-driven SPAs to Next.js, without sacrificing the benefits that come with its server-driven model.

Let's see how this feature addresses the long-standing (and valid!) criticism that Server Components can make apps feel unresponsive.

Instant Navigations

One of the most common frustrations we hear about Next.js apps is that navigations feel slow.

In a server-driven app, navigating usually requires a network roundtrip:

You click a link.
Nothing happens.
Then the server responds, and the next page appears.

This is not necessarily bad, and it can work well for content-driven websites like newspapers and blogs. But it does make the experience "feel like a website". It's not snappy. Compare this to how client-driven apps do navigations:

You click a link.
Instantly, you see a shell of the next page (with some data still loading).
Then the server responds, and the next page fully reveals.

This is a common reason why many developers prefer to create SPAs (single-page apps). Even though the server-driven request/response paradigm has many advantages, instant navigations still feel better for many kinds of apps.

We're fixing this

We've heard your feedback about this loud and clear.

In Next.js 16.3, we are shipping new opt-in behaviors that let you have the best of both worlds: server-driven apps with instant navigations. You get the full benefits of a server, but navigations are instant like in a single-page app.

Let's have a look at how this works.

First, enable Cache Components

To try these new behaviors, enable the Cache Components flag:

next.config.ts

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  cacheComponents: true,
  // ...
};
 
export default nextConfig;

Over the last year, we've been simplifying Next.js back to its roots: dynamic by default, with no hidden or implicit caching. This flag enables those new behaviors, and it will become a default in a future major version of Next.js.

Stream, Cache, or Block

Now, when a route awaits some data on the server, you will be presented with a choice between a few options:

The new Instant Insights panel automatically surfaces slow navigations

What do these options mean?

To make a navigation instant, you "turn" an asynchronous operation into something that can be available instantly:

Stream with <Suspense>. The user will instantly see a loading state (with more UI streaming in after).
Cache with 'use cache'. The user will instantly see a previously cached UI (reused between requests).

In both cases above, the navigation will feel SPA-like and instant to the user.

However, sometimes you might want to make a certain navigation server-bound. For example, a blog might choose to never show a loading shell for posts. For those cases, you can tell Next.js that you want this navigation to Block:

// in page.tsx or layout.jsx
export const instant = false;

Then the error dialog will go away.

Notice how this puts you in control. If you want your server-driven app to react to link clicks instantly—without waiting for the network—then you Stream or Cache. If you want some routes to delay navigations, then you Block.

To learn more about how Instant Insights integrates with coding agents, read Next.js 16.3: AI Improvements.

Agent skill

If you're looking to adopt Cache Components for the first time in an existing app, we've put together a Skill you can use to have your agent walk you through the process.

Keeping navigations instant

With Instant Insights, we've made slow navigations an error in development. To more easily catch regressions to your instant routes after changes and refactorings, we have also provided an instant test helper for Playwright tests:

import { expect, test } from '@playwright/test';
import { instant } from '@next/playwright';
 
test('product title is available immediately', async ({ page }) => {
  await page.goto('/products/shoes');
 
  // Assert what's visible without waiting for network
  await instant(page, async () => {
    await page.click('a[href="/products/hats"]');
    await expect(page.locator('h1')).toContainText('Baseball Cap');
    await expect(page.getByText('Checking inventory...')).toBeVisible();
  });
 
  await expect(page.getByText('12 in stock')).toBeVisible();
});

This lets you (or your agent) assert more granularly what must be instantly visible after each link click.

We're also exploring ways to surface the errors you see in development during the build process, so any regressions in your instant routes would be caught at build time.

Rethinking prefetching

For navigations to feel truly instant (like SPAs), we've needed to close two different gaps:

The client needs to talk to the server. This can be slow if there's high latency between them.
Also, the server needs to generate a response. This can be slow if the server code is slow.

By Streaming or Caching the response, we get rid of the second gap: the server itself doesn't block. But there's still a gap between the client and the server. How could Next.js "know" the response instantly by the time the user clicks?

Previously, Next.js solved this by sending a prefetch request to the server for every link in the viewport. If you paid attention to the Network tab in the production mode, you might have noticed a flurry of requests on scroll:

In 16.2, Next.js makes a prefetch request for every link, even if those links point to the same route

Many of you told us that this looked ridiculous, and frankly, we agree.

We've been thinking about how single-page apps solve this. A single-page app is able to respond to each navigation instantly because it bundles all the code that's necessary to display the next page and ships it to the client. It might still need more data—so clicking doesn't display a complete page—but it's enough to display a "shell" of the page.

So we've decided to borrow this trick from single-page apps. Instead of prefetching a page per link, Next.js will now prefetch a reusable shell per route. Those shells will then be cached on the client so they're only fetched once.

For example, if you had a sidebar with twenty chat links, Next.js used to send a separate prefetch request per link. However, with the new behavior, it will only prefetch once per route: a shell for the /chat/[id] route, a shell for the /dashboard route, and so on. Conceptually this is similar to how single-page apps download code with per-route code splitting.

In 16.3, Next.js prefetches a single loading shell per route, and reuses it across links

Because shells are reused across links, they're also a foundation for offline navigation. In a future release, we'll be exploring how prefetched routes could remain navigable when the network briefly disappears.

Enabling Partial Prefetching

To try this new prefetching behavior, which we call Partial Prefetching, enable in your Next.js config:

next.config.ts

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
  // ...
};
 
export default nextConfig;

Like with cacheComponents, we plan to make partialPrefetching the default behavior in a future major release.

Inspecting the loading shell

To make this more visual, we've added a new Navigation Inspector to the Next.js DevTools.

It lets you pause every navigation at the shell so that you can see what gets prefetched for any route:

Then, when you click "Resume", the navigation will show the completed page. This lets you see during development which part of your route can be displayed instantly, and which can only be displayed after the network hop.

Like before, actual prefetching is only enabled in production.

Prefetching more than a shell

With Partial Prefetching on, we've reduced what Next.js prefetches by default.

Instead of firing off a prefetch request for every link, Next.js will now only prefetch a reusable shell per each distinct route in the viewport (one for Chat page, one for Settings page, and so on), and cache them throughout the session.

However, sometimes, you want to prefetch more than the shell. For example, you might want a chat header to "pop in" instantly on a Chat page. To opt into per-link prefetching, you can add <Link prefetch={true}> to some links.

Note that even in that case, Next.js will not attempt to render the entire route all the way deep. Instead, it will render down to content that's available synchronously, known from the URL (like params or searchParams), or marked with 'use cache'.

This means that you no longer have to make an "all or nothing" choice with prefetching. The instant shell gives you the baseline, and then <Link prefetch={true}> with 'use cache' lets you add additional per-link prefetching that may include more content.

We've been using it ourselves

We've been adopting these tools on v0 ahead of this release. v0 has lots of rich client features, but navigations had been falling short of feeling instant for a while.

Instant Insights pointed us at the routes that weren't navigating instantly. Here's how navigations got faster once we started working through the fixes:

Navigation times in v0 (from click to route change)

We'll share the specific patterns we landed on in a follow-up post. We're also still optimizing the prefetching improvements described earlier, so we expect these numbers to get closer to zero.

A demo to poke around

If you'd like to see these features in a smaller, open-source codebase, Next Beats is a music player built on the Next.js 16.3 Preview, with its source on GitHub. Cache Components is enabled, and Partial Prefetching prefetches a single reusable shell per route on the client. The result is navigations that feel instant, the way they would in a single-page app.

Recap

To sum up, we've been working to let your app have Instant Navigations similar to a SPA:

If you Stream with <Suspense> or Cache with 'use cache', navigations to your route will be instant.
If you Block by export const instant = false, you opt out of enforcing instant navigations to that route.
Next.js automatically generates a reusable shell for every instant route, and only prefetches it once.
You can use the instant() test helper to avoid regressions, and Navigation Inspector to visually inspect shells.
You can opt into a deeper per-link prefetching with <Link prefetch> and 'use cache'.

These changes are gated behind cacheComponents: true and partialPrefetching: true flags.

With these changes, we are making the Next.js first-click navigation experience just as good as in single-page apps, but without giving up the benefits of the server-centric mental model and the overall performance that it allows.

Try it today

To try out Instant Navigations for yourself, install the 16.3 Preview today:

npm install next@preview

Check out the docs for Instant Navigations for more information.

We'd love to hear any feedback you have on GitHub, and we'll continue to publish updates to the preview tag as we work towards a polished stable release.

Known issues

There are known issues in Preview that we're actively working on. These will be fixed prior to our stable release.

Fixed There are some cases where a blocking route won't get reported as an Instant Insight. When Partial Prefetching is enabled, accessing params inside of a shell will cause a route to block, but this won't be reported as an Instant Insight. The Navigation Inspector and instant() test helper are unaffected.
There are some issues with the Instant Insights tooling in Safari. In development, use Chrome or Firefox for best results.

Check back here to see when these issues get resolved.

Feedback and Community

Share your feedback and help shape the future of Next.js:

Next.js Across Platforms: Adapters, OpenNext, and Our Commitments

Invalid Date

Next.js 16.2 introduced a stable Adapter API, built in collaboration with OpenNext, Netlify, Cloudflare, AWS Amplify, and Google Cloud. This post covers how that happened, and the commitments we're making to ensure Next.js works well on every platform:

Adapter API (stable): A typed, versioned description of your application that any platform can target.
Test suite: Shared correctness tests for every adapter, including Vercel's.
Verified adapters: Open-source, community-owned adapters hosted under the Next.js organization.
Ecosystem Working Group: A standing forum for coordinating changes across providers.

How we got here

Many Next.js apps are deployed as a single Node.js server running next start. Hundreds of thousands of teams do this today across any number of platforms, without limitations.

But scaling apps usually involves running multiple server instances. When you do, some things need to work correctly out of the box: cached content needs to stay synchronized across instances, on-demand revalidation needs to propagate, and streaming needs to work reliably. These are functional requirements, not optimizations.

Then there are the performance choices you opt into: serving cached content from a global CDN, running compute at the edge, optimizing cold starts with serverless functions. Each of these adds architectural complexity on top of what already needs to be correct.

Depending on the platform and architecture, the full surface area adds up: streaming, Server Components, Partial Prerendering, middleware, Cache Components, on-demand revalidation. Each capability and how they interact with one another was never formally documented. For platform providers looking to support Next.js at full fidelity in a multi-tenant environment across evolving releases, these challenges compounded:

When the Next.js team reached out with an offer to discuss Netlify's challenges, we started compiling a laundry list of specific issues to share, but it quickly became clear that the common thread among 90% of these was simply the lack of a documented, stable mechanism to configure and read build output. That was what we needed above all. So that's what we told Jimmy, and we're glad we did.

— Philippe Serhal, Engineer at Netlify

The missing piece was an upstream, stable, public contract that providers could build against.

OpenNext built the bridge

OpenNext filled that gap. It translated Next.js build output into something providers could consume, mapping framework semantics onto each provider's primitives. What started as a compatibility layer became an early production-grade adapter, especially on AWS, with Cloudflare and Netlify joining the effort later. OpenNext showed that Next.js build output can serve as a stable, defined interface that adapters target directly.

That insight led to a broader collaboration between the Next.js team and the OpenNext maintainers, along with engineers from Netlify, Cloudflare, AWS Amplify, and Google Cloud. We published a Build Adapters RFC in April 2025, formed a working group, and have been working together with these partners since then to design, test, and validate the API.

The Adapter API

Next.js 16.2 ships with a stable, public Adapter API.

On build, Next.js now produces a typed, versioned description of your application: routes, prerenders, static assets, runtime targets, dependencies, caching rules, and routing decisions. The adapter consumes this output and maps it onto a provider's infrastructure.

Adapters implement two hooks: modifyConfig (when configuration loads) and onBuildComplete (when the full output is available). Breaking changes require a new major version of Next.js.

Vercel's adapter uses this same public contract, with no private hooks or special integration path. It is open source.

As part of the working group's feedback, we have also reworked large sections of our documentation to better explain the platform integration surface. New guides cover the Rendering Philosophy, the Deploying to Platforms feature matrix, PPR Platform Guide, How Revalidation Works, and CDN Caching.

The test suite

We have made the Next.js test suite available for adapter authors. It covers streaming behavior, caching interactions, client navigation, and real-world edge cases. When a new feature ships, its behavior is encoded in these tests.

You can read more in the adapter testing documentation.

Adapter authors can run the suite using any adapter and get a pass/fail answer for each feature. This is the same test suite Vercel uses for its own adapter, so the correctness bar is shared across all providers.

Verified adapters

To become a verified adapter (hosted under the Next.js GitHub organization and listed in the Deploying to Platforms docs), two things are required: it must be open source and pass the full test suite. By making the adapter open source it ensures there is a place for the maintenance of the adapter, so that issues can be reported and triaged. The test suite ensures the adapter's compatibility with Next.js can be measured.

Each verified adapter is owned by the team that builds it. Publishing rights, release cadence, and implementation decisions are theirs, because platforms can be very different and we can't prescribe a specific implementation.

Providers can also build and ship closed-source adapters on the same public API.

The public Adapters API ships today with:

Vercel adapter: open source, maps Next.js output to Vercel's serverless and CDN infrastructure.
Bun adapter: a reference adapter showing how to build a complete Next.js deployment target on an alternative runtime.

Adapters for Netlify, Cloudflare, and AWS through OpenNext are in active development, with expected releases later this year.

Cloudflare has been part of OpenNext since the beginning because we believed developers deserve a stable, open contract for deploying Next.js apps anywhere. The official Next.js Adapter API makes that vision real. Developers running Next.js on Cloudflare's global developer platform will now have a shared foundation to build on, one designed in collaboration with the Next.js team to keep pace as the framework evolves. We are excited to be partners in this shared effort.

— Fred K Schott, Engineer at Cloudflare

The ecosystem working group

We are establishing the Next.js Ecosystem Working Group, a standing forum between the Next.js team, hosting providers, and adapter maintainers. Meeting notes will be public. If you want to join the group, please reach out to Jimmy.

We want providers to have early visibility into upcoming changes, not find out after a release. Breaking changes come with lead time proportional to their scope. New features are tested across environments before release. The full governance document covers the commitments in detail.

Learn more

Next.js 16.2: AI Improvements

Invalid Date

Next.js 16.2 includes several improvements designed for AI-assisted development. These changes make it easier for agents to understand your project, debug issues from the terminal, and inspect running apps — all without requiring a browser.

Agent-ready create-next-app: Scaffold AI-ready projects out of the box
Browser Log Forwarding: Forward browser errors to the terminal for agent-powered debugging
Dev Server Lock File: Actionable error messages when a second dev server tries to start
Experimental Agent DevTools: Give AI agents terminal access to React DevTools and Next.js diagnostics

Agent-ready `create-next-app`

create-next-app now includes an AGENTS.md file by default, giving AI coding agents access to version-matched Next.js documentation from the start of your project.

This builds on our research into AGENTS.md, which found that giving agents access to bundled documentation achieved a 100% pass rate on Next.js evals — outperforming skill-based approaches that maxed out at 79%. The key insight: always-available context works better than on-demand retrieval, because agents often fail to recognize when they should search for documentation.

The AGENTS.md file is a short directive that tells agents to read the docs bundled at node_modules/next/dist/docs/ before writing any code. The Next.js npm package now includes the full documentation as plain Markdown files, giving agents accurate version-matched references locally without fetching external data.

For existing projects, the setup depends on your Next.js version.

On 16.2 or later, the docs are already bundled in the next package. Add these two files to the root of your project:

AGENTS.md

<!-- BEGIN:nextjs-agent-rules -->
 
# Next.js: ALWAYS read docs before coding
 
Before any Next.js work, find and read the relevant doc in `node_modules/next/dist/docs/`. Your training data is outdated — the docs are the source of truth.
 
<!-- END:nextjs-agent-rules -->

The comment markers delimit the Next.js-managed section. You can add your own project-specific instructions outside them — future updates will only replace content between the markers.

CLAUDE.md is the instruction file for Claude Code. The @ directive tells it to include AGENTS.md as additional context:

CLAUDE.md

@AGENTS.md

On earlier versions, use the codemod to generate these files automatically:

terminal

npx @next/codemod@latest agents-md

For more details, see the AI agents setup guide.

Browser Log Forwarding

Next.js now forwards browser errors to the terminal by default during development, so you can see client-side errors without switching to the browser console. This is especially helpful for AI agents that operate primarily through the terminal and can't access a browser console.

By default, only errors are forwarded to the terminal. You can control the level of forwarding with logging.browserToTerminal in your next.config.ts:

next.config.ts

const nextConfig = {
  logging: {
    browserToTerminal: true,
    // 'error' — errors only (default)
    // 'warn'  — warnings and errors
    // true    — all console output
    // false   — disabled
  },
};
 
export default nextConfig;

Dev Server Lock File

Next.js now writes the running dev server's PID, port, and URL into the .next/dev/lock file. When a second next dev process starts in the same project directory, Next.js reads the lock file and prints an actionable error:

terminal

Error: Another next dev server is already running.
 
- Local:        http://localhost:3000
- PID:          12345
- Dir:          /path/to/project
- Log:          .next/dev/logs/next-development.log
 
Run kill 12345 to stop it.

This is especially useful for AI coding agents, which frequently attempt to start next dev without knowing a server is already running. The structured error gives the agent the PID to kill the existing process or the URL to connect to it — no manual intervention required.

The lock file also prevents two next build processes from running simultaneously, which could otherwise corrupt build artifacts.

Experimental Agent DevTools

The features above help agents understand your project and debug issues. @vercel/next-browser extends this by letting agents inspect a running Next.js application.

next-browser is an experimental CLI that exposes browser-level data — screenshots, network requests, console logs — along with framework-specific insights from React DevTools and the Next.js dev overlay, like component trees, props, hooks, Partial Prerendering (PPR) shells, and errors. All returned as structured text via shell commands.

An LLM can't read a DevTools panel, but it can run next-browser tree, parse the output, and decide what to inspect next. Each command is a one-shot request against a persistent browser session, so agents can query the app repeatedly without managing browser state. This turns the browser into something an agent can reason about, instead of a UI it can't access.

What it can do today

The feature set is evolving quickly. As of this release, next-browser supports:

Inspect React component trees — view props, hooks, state, and source-mapped file locations
Analyze PPR shells — identify static vs dynamic regions and blocked Suspense boundaries
Access errors and logs — retrieve build and runtime issues from the dev server
Monitor network activity — track requests since navigation, including server actions
Capture visuals — take screenshots or record loading filmstrips

Getting started

Install it as a skill (a reusable capability for AI agents):

terminal

npx skills add vercel-labs/next-browser

Then type /next-browser in Claude Code, Cursor, or any AI agent that supports skills. The CLI manages a Chromium instance with React DevTools pre-loaded — no browser configuration required.

Example: Growing the static shell

With Partial Prerendering (PPR), Next.js can serve a static shell instantly from the edge — the parts of your page that don't depend on per-request data — then stream in the rest. The more content that fits in the static shell, the faster users see a meaningful page.

In practice, a single per-request fetch can accidentally make an entire page dynamic. Consider a blog post with a visitor counter:

app/blog/[slug]/page.tsx

export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}
 
export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
  const views = await getVisitorCount(params.slug); // per-request
 
  return (
    <article>
      <h1>{post.title}</h1>
      <span>{views} views</span>
      <div>{post.content}</div>
    </article>
  );
}

Every slug is enumerated in generateStaticParams, so the post content could be prerendered at build time. But getVisitorCount runs on every request — and because it sits at the top level of the component, it makes the entire page dynamic. As a result, the entire page waits behind a loading skeleton instead of streaming in progressively.

An agent can use next-browser to diagnose this. Locking PPR mode shows only the static shell — in this case, the app/blog/[slug]/loading.tsx skeleton, because nothing in the page made it into the shell:

terminal

next-browser ppr lock          # Enter PPR mode
next-browser goto /blog/hello  # The entire page is a loading skeleton

The agent then runs ppr unlock to find out what went wrong:

terminal

next-browser ppr unlock

terminal

# PPR Shell Analysis
# 1 dynamic hole, 1 static
 
blocked by:
  - getVisitorCount (server-fetch)
    owner: BlogPost at app/blog/[slug]/page.tsx:5
    next step: Push the fetch into a smaller Suspense leaf

The report tells the agent exactly what to do: getVisitorCount is the blocker, it lives in BlogPost, and the fix is to push it into its own Suspense boundary. The agent wraps just the counter:

app/blog/[slug]/page.tsx

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
 
  return (
    <article>
      <h1>{post.title}</h1>
      <Suspense fallback={<span>— views</span>}>
        <VisitorCount slug={params.slug} />
      </Suspense>
      <div>{post.content}</div>
    </article>
  );
}

Running ppr lock again confirms the shell grew — the post content now prerenders instantly. Only the visitor count shows a fallback:

next-browser is still evolving, but it points toward a future where agents can debug and optimize apps with the same visibility as a developer.

Feedback and Community

Share your feedback and help shape the future of Next.js:

Turbopack: What's New in Next.js 16.2

Invalid Date

Two releases after Turbopack became the default bundler for Next.js, we're focused on improving performance, fixing bugs, and increasing parity. Here are some of the latest features shipping as part of Next.js 16.2.

Server Fast Refresh: Fine-grained server-side hot reloading
Web Worker Origin: Increasing support for WASM libraries in Workers
Subresource Integrity Support: Subresource Integrity for JavaScript files
Tree Shaking of Dynamic Imports: Unused exports removed from dynamic import()
Inline Loader Configuration: Per-import loader configuration via import attributes
Lightning CSS Configuration: Experimental LightningCSS configuration options
Log Filtering: Suppressing noisy logs and warnings with ignoreIssue
postcss.config.ts Support: TypeScript PostCSS configuration
Performance Improvements and Bug Fixes: Over 200 changes and bug fixes

Looking forward towards our next release, we'll be focused on speeding up compiler performance and reducing memory usage.

Server Fast Refresh

We've reworked how server-side code is reloaded during development. The previous system cleared the require.cache for the changed module and all other modules in its import chain. This approach often reloaded more code than necessary, including unchanged node_modules.

The new system brings the same Fast Refresh approach used in the browser to your server code. Turbopack's knowledge of the module graph means only the module that actually changed is reloaded, leaving the rest intact. This makes server-side hot reloading significantly more efficient.

In real-world Next.js applications, we've seen 67-100% faster application refresh and 400-900% faster compile time inside Next.js. These results scale from the smallest "hello world" starter project to large sites like vercel.com.

Server refresh time on a sample Next.js site

375% faster

Before

40ms

19ms

59ms

After

2.7ms

9.7ms

12.4ms

Next.js (40ms → 2.7ms)

Application (19ms → 9.7ms)

Today we're enabling this feature for all developers, by default. Proxy and Route Handlers will use the existing system today, but support for those is arriving in a future release. Share your feedback or any issues with this new feature on GitHub.

Web Worker Origin

Previously, Web Workers were bootstrapped through a blob:// URL. This streamlined loading the worker, but it set an empty location.origin value. Web Worker code that tried to use importScripts() or fetch() (usually in third-party libraries) would have been unable to resolve the request without changes.

With the updated Worker bootstrap code, the origin correctly points to your domain name, and relative fetches succeed. This should unblock anyone who had trouble running WASM code inside a Worker in previous versions.

Subresource Integrity Support

Turbopack now supports Subresource Integrity (SRI). SRI generates cryptographic hashes of your JavaScript files at build time, allowing browsers to verify that files haven't been modified.

Browsers provide a technology called Content Security Policy that allows sites to restrict the JavaScript that can run, eliminating entire classes of security issues. However, the typical nonce-based method for implementing this requires all pages to be dynamically rendered, impacting performance. Subresource Integrity is an alternative that computes a hash of each script ahead of time, and only allows the browser to execute scripts with approved hashes.

next.config.js

const nextConfig = {
  experimental: {
    sri: {
      algorithm: 'sha256',
    },
  },
};
 
module.exports = nextConfig;

Tree Shaking of Dynamic Imports

Turbopack now tree shakes destructured dynamic imports the same way it does static imports. Unused exports are removed from the bundle:

const { cat } = await import('./lib');

This is now equivalent to a static import for tree shaking purposes — any exports from ./lib that aren't used will be tree-shaken.

Inline Loader Configuration

Turbopack now supports per-import loader configuration via import attributes. Instead of applying loaders globally through turbopack.rules, you can configure them on individual imports using the with clause:

import rawText from './data.txt' with {
  turbopackLoader: 'raw-loader',
  turbopackAs: '*.js',
};
import value from './data.js' with {
  turbopackLoader: 'string-replace-loader',
  turbopackLoaderOptions: '{"search":"PLACEHOLDER","replace":"replaced value"}',
};

This is useful when only a specific import needs special treatment, avoiding side effects on other imports of the same file type. The available attributes are turbopackLoader, turbopackLoaderOptions, turbopackAs, and turbopackModuleType.

You should still prefer configuring your loaders in next.config.ts when possible, since code using inline loaders is less portable. This option is more useful for code generated from plugins or loaders.

Lightning CSS Configuration

Lightning CSS is a fast, Rust-based CSS transformer used by Turbopack for CSS minification and prefixing. It also allows implementation of modern CSS features on older browsers, similar to what Babel or SWC do for JavaScript. Previously, the only way to toggle these settings was through a Browserslist configuration. Now with the experimental lightningCssFeatures option, you can force certain features to always or never transpile.

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  experimental: {
    useLightningcss: true,
    lightningCssFeatures: {
      include: ['light-dark', 'oklab-colors'],
      exclude: ['nesting'],
    },
  },
};
 
export default nextConfig;

Log Filtering

Turbopack can now suppress noisy or expected warnings from streaming logs with the turbopack.ignoreIssue config option. This is useful for suppressing warnings from third-party code, generated files, or optional dependencies, as well as hiding expected errors from the Next.js error overlay.

You can match logs generated from specific code paths, as well as filter for specific title/description strings or patterns.

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  turbopack: {
    ignoreIssue: [
      { path: '**/vendor/**' },
      { path: 'app/**', title: 'Module not found' },
      { path: /generated\/.*\.ts/, description: /expected error/i },
    ],
  },
};
 
export default nextConfig;

`postcss.config.ts` Support

Turbopack now supports postcss.config.ts in addition to the existing .js and .cjs variants.

Performance Improvements and Bug Fixes

We've continued to invest in improving Turbopack internals. Over 200 changes and bug fixes have improved stability and compatibility across a wide range of projects. Optimizations in data encoding, internal representation formats, and hashing algorithms have improved memory usage and build time. We've made error logs clearer and expanded diagnostics to help you better understand compiler errors. We've also used your GitHub Issues as a guide for which features were missing since the 16.1 release.

Feedback and Community

Share your feedback and help shape the future of Next.js:

Next.js 16.2

Invalid Date

Next.js 16.2 includes performance improvements, better debugging, improvements for Agents, and over 200 Turbopack fixes and improvements.

Faster Time-to-URL: ~400% faster next dev startup
Faster Rendering: ~50% faster rendering
New Default Error Page: Redesigned built-in 500 page
Server Function Logging: Dev terminal logs for Server Function execution
Hydration Diff Indicator: Clear server/client diff in the error overlay
--inspect for next start: Attach the Node.js debugger to your production server

We also published dedicated deep-dive posts for two major areas of this release:

Turbopack: Faster builds, SRI support, postcss.config.ts, tree shaking improvements, Server Fast Refresh, and 200+ bug fixes
AI Improvements: AGENTS.md in create-next-app, browser log forwarding, and next-browser (experimental)

Upgrade today, or get started with:

terminal

# Use the automated upgrade CLI
npx @next/codemod@canary upgrade latest
 
# ...or upgrade manually
npm install next@latest react@latest react-dom@latest
 
# ...or start a new project
npx create-next-app@latest

Faster Time-to-URL in Development

We've significantly improved the time it takes before localhost:3000 is ready during next dev. On the same machine and project, startup is ~87% faster compared to Next.js 16.1 on the default application.

Faster Rendering

We contributed a change to React that makes Server Components payload deserialization up to 350% faster. The previous implementation used a JSON.parse reviver callback, which crosses the C++/JavaScript boundary in V8 for every key-value pair in the parsed JSON. Even a trivial no-op reviver makes JSON.parse roughly 4x slower than without one.

The new approach uses a two-step process: plain JSON.parse() followed by a recursive walk in pure JavaScript. This eliminates the boundary-crossing overhead and adds optimizations like short-circuiting plain strings that don't need transformation.

In real-world Next.js applications, this translates to 25% to 60% faster rendering to HTML, depending on the RSC payload size.

Server render time

Server Component Table with 1000 items26% faster

Before

19ms

After

15ms

Server Component with nested Suspense33% faster

Before

80ms

After

60ms

Payload CMS homepage34% faster

Before

43ms

After

32ms

Payload CMS with rich text60% faster

Before

52ms

After

33ms

New Default Error Page

The default error page shown in production has been redesigned. When your application encounters an error and you haven't defined a custom global-error.tsx or error.tsx, Next.js renders a built-in fallback page. This fallback has been updated with a cleaner, more modern design.

The redesigned default error page in Next.js 16.2

Server Function Logging

Next.js now logs Server Function execution in the terminal during development. Each log shows the function name, its arguments, execution time, and the file it's defined in.

Server Function execution logs in the development terminal

Hydration Diff Indicator

When a hydration mismatch occurs, the error overlay now clearly labels which content came from the server and which from the client. The diff uses a + Client / - Server legend, making it immediately clear what diverged.

The hydration diff indicator showing client/server content differences

`--inspect` for `next start`

Next.js 16.1 introduced next dev --inspect for attaching the Node.js debugger during development. In 16.2, this extends to next start, allowing you to attach a Node.js debugger to your production server.

terminal

next start --inspect

This is useful for debugging issues or profiling CPU and memory usage.

For more information on how to use the Node.js debugger, see the Chrome documentation.

`transitionTypes` Prop for `next/link`

The <Link> component now accepts a transitionTypes prop — an array of strings that specifies the types of View Transitions to apply when navigating. Each type is passed to React.addTransitionType during the navigation Transition, allowing you to trigger different animations based on the navigation direction or context.

<Link href="/about" transitionTypes={['slide']}>
  About
</Link>

This is only supported in the App Router, since the Pages Router does not use React Transitions for navigation. transitionTypes on Pages Router links is silently ignored, so shared link components work across both routers.

To learn more about view transitions, see the documentation.

Faster `ImageResponse`

ImageResponse has been updated with significant improvements:

2x faster ImageResponse for basic images, up to 20x faster for complex images
Improved CSS and SVG coverage, including support for inline CSS variables, text-indent, text-decoration-skip-ink, box-sizing, display: contents, position: static, and percentage values for gap
Default font changed from Noto Sans to Geist Sans

Learn more about ImageResponse.

Error Causes in the Dev Overlay

The error overlay now displays Error.cause chains, making it easier to debug errors that wrap other errors. Causes are shown in a flat list below the top-level error, up to 5 levels deep.

The error overlay showing the full error cause chain

Adapters

Adapters are now stable. This is a new API that allows platforms to customize the build process.

This is useful for deployment platforms or custom build integrations that need to modify the Next.js configuration or process the build output.

We will share a more detailed overview of Adapters next week.

Multiple Icon Formats

Multiple icon files with the same base name but different extensions are now handled automatically in your app directory (e.g., icon.png and icon.svg). This is useful for browser fallback support. Modern browsers can use SVG icons while older browsers fall back to PNG. Both formats are rendered as separate <link> tags.

Experimental Features

`unstable_catchError()`

Extending the error recovery experience with the error.js file convention, unstable_catchError() provides more granular control of the error boundaries on the component level. By creating a custom error boundary using unstable_catchError(), you can place it anywhere in your component tree.

Compared to a custom React error boundary, unstable_catchError() is designed to work with Next.js out of the box:

Built-in error recovery: unstable_retry() re-renders the page from the server in transition.
Framework-aware integration: APIs like redirect() and notFound() work by throwing special errors under the hood. unstable_catchError() handles these seamlessly, so they're not accidentally caught by your error boundary.
Client navigation handling: The error state automatically clears when you do a client navigation to a different route.

The error boundary created by unstable_catchError() receives the props passed from the call site and the ErrorInfo value as the second argument, which is the same shape as the props passed to the error.js file convention.

Just like error.js, unstable_catchError() can only be called from Client Components.

app/custom-error-boundary.tsx

'use client';
 
import { unstable_catchError, type ErrorInfo } from 'next/error';
 
function CustomErrorBoundary(
  props: { title: string },
  { error, unstable_retry }: ErrorInfo,
) {
  return (
    <div>
      <h2>{props.title}</h2>
      <p>{error.message}</p>
      <button onClick={() => unstable_retry()}>Try again</button>
    </div>
  );
}
 
export default unstable_catchError(CustomErrorBoundary);

app/page.tsx

import CustomErrorBoundary from './custom-error-boundary';
 
export default function Page() {
  return (
    <CustomErrorBoundary title="Oops! Something went wrong!">
      <Component />
    </CustomErrorBoundary>
  );
}

`unstable_retry()` in `error.tsx`

A new unstable_retry() prop is now available in error.tsx components. Previously, the reset() prop only cleared the error state and re-rendered the children, which works for temporary rendering errors but doesn't help when the error originates from data fetching or the RSC phase.

unstable_retry() calls router.refresh() and reset() within a startTransition(), providing built-in retry logic that re-fetches data and re-renders the segment. This is expected to be preferred over reset() for most error recovery scenarios.

app/error.tsx

'use client';
 
import type { ErrorInfo } from 'next/error';
 
export default function Error({ error, unstable_retry }: ErrorInfo) {
  return (
    <div>
      <h2>Something went wrong</h2>
      <p>{error.message}</p>
      <button onClick={() => unstable_retry()}>Try again</button>
    </div>
  );
}

`experimental.prefetchInlining`

Next.js 16 introduced per-segment prefetching, where the client issues individual requests for each segment in the route tree. This improves cache efficiency as shared layouts between sibling routes are fetched once and reused, but increases request volume.

The new experimental.prefetchInlining option bundles all segment data for a route into a single response, reducing the number of prefetch requests to one per link. The trade-off is that shared layout data is duplicated across inlined responses rather than being cached and reused.

next.config.ts

const nextConfig = {
  experimental: {
    prefetchInlining: true,
  },
};
 
export default nextConfig;

This is a stepping stone toward a size-based heuristic where small segments are inlined automatically and larger segments remain separate.

`experimental.cachedNavigations`

This flag independently controls the Cached Navigations behavior, which caches static and dynamic Server Components data from navigations and the initial HTML loads so that repeat visits can be served instantly. Requires cacheComponents to be enabled.

`experimental.appNewScrollHandler`

A reworked scroll and focus management system for App Router using React Fragment refs. The new handler improves how focus is managed after navigations. Instead of focusing the first focusable descendant deep within a segment (which could skip past content), it now blurs the active element, matching how browser navigations work.

next.config.ts

const nextConfig = {
  experimental: {
    appNewScrollHandler: true,
  },
};
 
export default nextConfig;

Feedback and Community

Share your feedback and help shape the future of Next.js:

Contributors

Next.js is the result of the combined work of over 3,770 individual developers. This release was brought to you by:

The Next.js team: Andrew, Hendrik, Janka, Jiachi, Jimmy, Jiwon, JJ, Josh, Jude, Sam, Sebbie, Tim, and Zack.
The Turbopack team: Benjamin, Andrew, Luke, Niklas, Tobias, and Will.
The Next.js Docs team: Delba, Rich, Ismael, Joseph and Aurora.

Huge thanks to @acdlite, @unstubbable, @mischnic, @sokra, @ztanner, @mmastrac, @bgw, @lukesandberg, @wyattjoh, @huozhi, @eps1lon, @jwueller, @brookemosby, @delbaoliveira, @icyJoseph, @gaojude, @hanzala-sohrab, @dango0812, @ijjk, @msmx-mnakagawa, @Juneezee, @davidgolden, @LucianBuzzo, @devjiwonchoi, @alexcarpenter, @jaffarkeikei, @BradErz, @mintydev789, @naaa760, @Suhaib3100, @pavan-sh, @amannn, @fireairforce, @JamBalaya56562, @wheresrhys, @ericrav, @lubieowoce, @Thomas465xd, @bgub, @wbinnssmith, @Netail, @robert-j-webb, @bencmbrook, @shadcn, @sigmachirality, @abhishekmardiya, @vvscode, @feedthejim, @freek-boon-greenberry, @andrewimm, @alubbe, @FurryR, @01-binary, @andrewdamelio, @swarnava, @gnoff, @kristiyan-velkov, @styfle, @haydenbleasel, @rishishanbhag, @tdarthur, @lavanitha, and @karlhorky for helping!

Building Next.js for an agentic future

Invalid Date

We've spent the past year improving the Next.js agent experience. Along the way, we built and sunset an in-browser agent, shipped MCP integration, and learned that the real answer to better agent support is thinking from the agent's perspective.

Agents couldn't see the browser

Earlier this summer, we were working on improving the Next.js devtools when we noticed a pattern. Developers would see an error in the browser, copy the details, paste them into an AI editor, and ask the agent to fix it.

The problem was that agents can't see the browser. Runtime errors, client-side warnings, and rendered components are all invisible to them. When a user says "fix the error," the agent doesn't know what error they mean.

Our first response was updating the copy button to capture structured error data. Then we added a feature that forwards browser logs to the terminal. Small fixes, but they pointed toward a bigger realization. We needed to make Next.js itself visible to agents.

Experimenting with an in-browser agent

That led to an ambitious idea. What if we built an agent directly inside Next.js that worked like smart devtools?

We built an in-browser chat agent called Vector. Similar to react-grab but integrated with Next.js, Vector let you select elements on the page, see their source code, and prompt for changes. It had Next.js best practices baked in to help agents avoid hallucination.

Subtitle: Vector's interface showing error detection and suggested fixes.

Vector was useful, but it overlapped with general coding agents like Cursor and Claude Code. Most developers were already using those tools for all of their projects anyway, not just Next.js. The UI selection made it easy to point at exactly what you wanted to change, but it wasn't something people needed every day.

We sunset Vector, but took what made it useful (structured visibility and framework-specific knowledge) and decided to build those into Next.js itself.

MCP made Next.js state visible to agents

Around the Next.js v16 release in October 2025, users were struggling to debug with agents. The common prompt was "fix the error," asking agents to resolve issues from the browser overlay. But agents would request the page HTML and find nothing wrong.

Runtime failures, browser JavaScript errors, and async errors all lived in the browser, not in the HTML. The rendered page, layout segments, routes, and other internal state were invisible to agents.

MCP gave us a way to expose this data. The first version surfaced internal states like errors, routes, and rendered segments, but exposing data alone wasn't enough. Agents also needed to discover running dev servers and communicate with them, which led to next-devtools-mcp.

Subtitle: The Next.js MCP responding to "whats use cache?" with documentation and context.

The MCP also packages prompts and tools to help with upgrades and cache component migrations. There's a detailed talk about the MCP integration if you want to learn more.

The answer is to think like an agent

MCP confirmed what Vector taught us. Agents need visibility into what Next.js is doing, but that's only part of the story. The deeper lesson was treating agents as first-class users of Next.js and thinking from their perspective. What information do they need? When do they need it? How do they consume it?

This mindset led to practical changes. If agents read terminal output during development, then logging Server Action invocations and forwarding browser errors gives them the hints they need. If agents struggle with framework concepts not in their training data, then embedding a compressed docs index agents.md or providing structured workflows (Next.js skills) gives them better context than documentation alone.

Those questions run through everything we built. The need for visibility led to better logging, the need for knowledge led to agents.md, and the need for discovery led to MCP. When you treat agents as first-class users and meet them where they are, debugging becomes a tight feedback loop between code, runtime, and AI.

What's next

We're now working on making this easier to adopt. You can already run npx @next/codemod to generate an up-to-date docs index for your project, and we're expanding our eval suite to cover more Next.js 16 APIs so we can measure what actually helps agents. Longer term, we want this built into next dev so agents get the right context automatically without any setup.

We're eager to hear your feedback and ideas on how to make Next.js work even better with agents.

Inside Turbopack: Building Faster by Building Less

Invalid Date

Edit. Save. Refresh. Wait… Wait… Wait…

Compiling code usually means waiting, but Turbopack makes iteration loops fast with caching and incremental computation. Not every modern bundler uses an incremental approach, and that’s with good reason. Incremental computation can introduce significant complexity and opportunities for bugs. Caches require extra tracking and copies of data, adding both CPU and memory overhead. When applied poorly, caching can actually make performance worse.

Despite all of this, we took on these challenges because we knew that an incremental architecture would be critical to Turbopack’s success. Turbopack is the new default bundler for Next.js, a framework that is used to build some of the largest web applications in the world. We needed to enable instant builds and a fast as-you-type interactive React Fast Refresh experience, even for the largest and most challenging workloads. Our incremental architecture is core to achieving this.

A solution without caching slows down as the size of the application increases. Incremental computation can scale to large applications because it only depends on the size of small iterative changes.

Turbopack’s architecture was built ground-up with caching in mind. Its incremental design is based on over a decade of research. We built on first-hand experience from challenges in implementing caching in webpack and drew inspiration from Salsa (which powers Rust-Analyzer and Ruff), Parcel, the Rust compiler’s query system, Adapton, and many others.

Turbopack achieves a fine-grained cache by automatically tracking how internal functions are called and what values they depend on. When something changes we know how to recompute the results with minimal work.

Background: Manual incremental computation

Many build systems include explicit dependency graphs that must be manually populated when evaluating build rules. Explicitly declaring your dependency graph can theoretically give optimal results, but in practice it leaves room for errors.

The difficulty of specifying an explicit dependency graph means that usually caching is done at a coarse file-level granularity. This granularity does have some benefits: fewer incremental results means less data to cache, which might be worth it if you have limited disk space or memory.

An example of such an architecture is GNU Make, where output targets and prerequisites are manually configured and represented as files. Systems like GNU Make miss caching opportunities due to their coarse granularity: they do not understand and cannot cache internal data structures within the compiler.

Function-level fine-grained automatic incremental computation

In Turbopack, the relationship between input files and resulting build artifacts isn’t straightforward. Bundlers employ whole-program analysis for dead code elimination ("tree shaking") and clustering of common dependencies in the module graph. Consequently, the build artifacts (JavaScript files shared across multiple application routes) form complex many-to-many relationships with input files.

Turbopack uses a very fine-grained caching architecture. Because manually declaring and adding dependencies to a graph is prone to human errors, Turbopack needs an automated solution that can scale.

Tracking the compilation graph with value cells

To facilitate automatic caching and dependency tracking, Turbopack introduces a concept of “value cells” (Vc<…>). Each value cell represents a fine-grained piece of execution, like a cell in a spreadsheet. When reading a cell, it records the currently executing function and all of its cells as dependent on that cell. This is similar to how signals work in frameworks like SolidJS.

The value cells become tracked when awaited.

By not marking cells as dependencies until they are read, Turbopack achieves finer-grained caching than a traditional top-down memoization approach would provide. For example, an argument might be an object or mapping of many value cells. Instead of needing to recompute our tracked function when any part of the object or mapping changes, it only needs to recompute the tracked function when a cell that it has actually read changes.

Value cells represent nearly everything inside of Turbopack, such as a file on disk, an abstract syntax tree (AST), metadata about imports and exports of modules, or clustering information used for chunking and bundling.

Examples of types of data that could be stored inside a value cell.

Marking dirty and propagating changes

When Turbopack executes functions for the first time, it builds a graph of functions and the value cells they create or depend on. The graph’s roots are the requested outputs (bundled assets), and the leaves are source code files. There are intermediate representations in the middle, such as ASTs, metadata, partially-transformed modules, or chunking information.

When our file system watcher finds source code that has changed, it marks all functions that read the file’s value cell as “dirty” and queues them for re-computation.

The dirtied function reading the file might parse or transform the JavaScript module and produce a new intermediate representation. Recomputing the function update cells containing changed intermediate representations, which may mark more functions as dirty. Cell updates are skipped if the cell contents are equal. This propagation bubbles up the graph until all affected functions have been recomputed.

As an additional optimization, execution is "demand-driven," meaning the system defers re-execution of dirty functions until they become part of an "active query". In development, an active query could be a currently open webpage with hot reloading enabled. In builds, this is a request for the full production app.

These example call trees represent an initial (cold) execution, the “mark dirty” operation when a file has been changed, and the propagation from the leaf up to the root.

Aggregation graphs

While most operations, like the dirty propagation algorithm, only require information about adjacent edges and neighboring nodes in the graph, some operations need to query information about more significant portions of the dependency graph:

Finding all dirty nodes when a sub-graph becomes part of a new active query, so we can schedule re-computation.
Collecting errors, warnings, or lints of a sub-graph.
Waiting for computation of a sub-graph to finish.

Because we maintain a fine-grained cache, the graph can contain hundreds of thousands or even millions of intermediate results. Visiting significant portions of this graph would be expensive.

To make these queries efficient, Turbopack uses an additional data structure on top of the dependency graph, called the “aggregation graph”.

When we build or update the dependency graph, we maintain parallel nodes in the aggregation graph that summarize part of the dependency graph. Some frequently accessed information, like emitted errors or warnings, is attached to the aggregation nodes.

This aggregation graph has multiple layers of resolution, with higher aggregation layers referencing more functions in each node, decreasing the resolution, and reducing the number of nodes that must be traversed when collecting information.

Every potential active query (e.g. an application entrypoint or route) represents a root in the aggregation graph. At the final aggregation graph layer, each root represents the information for itself and all of the children in the original dependency graph. Adding roots to the dependency graph can require a reorganization of the aggregation graph, but that’s an infrequent operation.

Aggregation layers capture less detail than the original dependency graph, but are faster to traverse. At the final layer, aggregation root nodes contain all of the children in the original graph.

File system caching

Until our recent Next.js 16.1 release, all of these caches were stored only in memory.

In this new release, we shipped file system caching for next dev as stable and on-by-default. This cache allows us to persist the dependency graph, the aggregation graph, and all of the intermediate results stored in value cells to disk. When next dev is restarted, it can quickly resume from this warm cache.

File system caching came with its own set of challenges, and it took us over a year of dedicated work to meet our own high performance and quality bar. We'll dive into that soon in an upcoming engineering blog post.

Feedback and Community

Share your feedback and help shape the future of Next.js:

Next.js 16.1

Invalid Date

Next.js 16.1 focuses on faster development workflows and improved stability, with major updates to Turbopack and tooling.

Turbopack File System Caching for next dev (stable): Improved compile times for next dev by default.
Next.js Bundle Analyzer (experimental): Optimize your code with our new interactive tool.
Easier debugging: Debug your Next.js app with next dev --inspect.
Transitive external dependencies: Turbopack can automatically handle transitive external dependencies with no warnings.

Upgrade Today

terminal

# Use the automated upgrade CLI
npx @next/codemod@canary upgrade latest
 
# ...or upgrade manually
npm install next@latest react@latest react-dom@latest
 
# ...or start a new project
npx create-next-app@latest

Turbopack File System Caching for `next dev`

Turbopack file system caching for next dev is now stable and on by default. Compiler artifacts are stored on disk, leading to significantly faster compile times when restarting your development server, especially in large projects.

First route compile time

react.dev~10× faster

Cold

3.7s

Cached

380ms

nextjs.org~5× faster

Cold

3.5s

Cached

700ms

Large internal Vercel app~14× faster

Cold

15s

Cached

1.1s

Internal applications at Vercel have been dogfooding this for the past year. To learn more about how we built file system caching for Turbopack, watch Luke Sandberg's talk at Next.js Conf.

Following this release, we'll be stabilizing file system caching for next build. See our documentation for more information, and share your feedback on the dedicated GitHub discussion.

Next.js Bundle Analyzer (experimental)

Next.js 16.1 includes a new experimental Bundle Analyzer that works with Turbopack. It makes it easier to optimize bundle sizes for both server and client code—helping improve Core Web Vitals, reduce lambda cold start times, and identify bloated dependencies.

terminal

next experimental-analyze

Running the command launches an interactive UI to inspect production bundles, identify large modules, and see why they're included.

The Next.js Bundle Analyzer showing a treemap with TopNav.tsx selected, revealing its import chain.

Try it yourself: Open the interactive Bundle Analyzer demo to explore the module graph.

The Bundle Analyzer is deeply integrated into Next.js, allowing you to:

Filter bundles by route
View the full import chain showing why a module is included
Trace imports across server-to-client component boundaries and dynamic imports
View CSS and other imported asset sizes
Switch between client and server views

The Bundle Analyzer is in early development and will be improved further in future releases. Share your feedback on the dedicated GitHub discussion.

Easier Debugging with `next dev --inspect`

You can now enable the Node.js debugger by passing --inspect to next dev. Previously this required passing NODE_OPTIONS=--inspect and would attach the inspector to all processes spawned by Next.js instead of only to the process running your code.

Improved Handling of `serverExternalPackages`

Next.js allows you to keep dependencies unbundled using serverExternalPackages. Previously, this only worked reliably for direct dependencies. If you used a library that internally depends on something like sqlite, and needed to externalize sqlite, you'd have to add it to your own package.json—even though it's not your direct dependency. This workaround leaked internal implementation details, created maintenance burden, and could lead to impossible version conflicts when multiple packages required different versions of the same dependency.

Next.js 16.1 fixes this for Turbopack, which now correctly resolves and externalizes transitive dependencies in serverExternalPackages without additional configuration.

Other Updates

20MB smaller installs: Next.js installs are about 20MB smaller thanks to simplifications in the Turbopack file system caching layer.
New next upgrade command: A new next upgrade command makes upgrading easier. Going forward, you can just run this to upgrade Next.js versions.
MCP get_routes tool: The Next.js DevTools MCP server now has a get_routes tool to get the full list of routes in your application.
generateStaticParams timing: Time spent on generateStaticParams is now logged as part of the timings shown for requests in development.
Build worker logging: next build "Collecting page data" and "Generating static pages" now log the number of worker threads used.
Improved async import bundling: Turbopack has improved bundling of async imports in dev to reduce the number of chunks produced, avoiding certain pathological but real-world cases.
Relative source map paths: Turbopack now produces source maps with relative file paths for server-side code, improving compatibility with Node.js and other ecosystem tools.

Feedback and Community

Share your feedback and help shape the future of Next.js:

Contributors

Next.js is the result of the combined work of over 3,700 individual developers. This release was brought to you by:

The Next.js team: Andrew, Hendrik, Janka, Jiachi, Jimmy, Jiwon, JJ, Josh, Jude, Sam, Sebastian, Sebbie, Wyatt, and Zack.
The Turbopack team: Benjamin, Luke, Niklas, Tim, Tobias, and Will.
The Next.js Docs team: Delba, Rich, Ismael, and Joseph.

Huge thanks to @kdy1, @eps1lon, @SyMind, @bgw, @swarnava, @devjiwonchoi, @ztanner, @ijjk, @huozhi, @icyJoseph, @acdlite, @unstubbable, @gnoff, @gusfune, @lukesandberg, @sokra, @hayes, @shuding, @wyattjoh, @marjan-ahmed, @timneutkens, @ajstrongdev, @zigang93, @mischnic, @Nayeem-XTREME, @hamirmahal, @eli0shin, @tessamero, @gaojude, @jamesdaniels, @georgesfarah, @timeyoutakeit, @sequencerr, @Strernd, @lucasadrianof, @wbinnssmith, @hamidreza-nateghi, @jokokoloko, @dijonmusters, @H01001000, @xusd320, @lubieowoce, @KaziMahbuburRahman, @zhiyanzhaijie, @feedthejim, @that-one-arab, @JamBalaya56562, @shrink, @florianliebig, @allenzhou101, @benmerckx, @ymc9, @Marukome0743, @pyrytakala, @danpeleg4, @gaearon, @styfle, @jhuleatt, @muhammadsyaddad, @roelvan, and @SukkaW for helping!

Next.js Security Update: December 11, 2025

Invalid Date

Two additional vulnerabilities have been identified in the React Server Components (RSC) protocol. These issues were discovered while security researchers examined the patches for React2Shell. Importantly, neither of these new issues allow for Remote Code Execution. The patch for React2Shell remains fully effective.

These vulnerabilities originate in the upstream React implementation (CVE-2025-55183, CVE-2025-55184). This advisory tracks the downstream impact on Next.js applications using the App Router. For full details, see the React blog post.

Addendum: The initial fix for CVE-2025-55184 was incomplete. A complete fix has been issued under CVE-2025-67779. If you previously upgraded to one of the initially recommended versions, please upgrade again to the latest patched versions listed below.

Impact

Denial of Service: CVE-2025-55184 (High Severity)

A specifically crafted HTTP request can be sent to any App Router endpoint that, when deserialized, can cause an infinite loop that hangs the server process and prevents future HTTP requests from being served.

Note: The initial fix for this vulnerability was incomplete. A complete fix has been issued under CVE-2025-67779. Users who previously upgraded must upgrade again to the latest patched versions.

Source Code Exposure: CVE-2025-55183 (Medium Severity)

A specifically crafted HTTP request can cause a Server Function to return the compiled source code of other Server Functions in your application. This could reveal business logic. Secrets could also be exposed if they are defined directly in your code (rather than accessed via environment variables at runtime) and referenced within a Server Function. Depending on your bundler configuration, these values may be inlined into the compiled function output.

Affected and Fixed Next.js Versions

Applications using React Server Components with the App Router are affected. The table below shows which versions are affected by each vulnerability and the corresponding fix:

Version	DoS (CVE-2025-55184)	Source Code Exposure (CVE-2025-55183)	Fixed In
>=13.3	✓	—	Upgrade to 14.2.35
14.x	✓	—	14.2.35
15.0.x	✓	✓	15.0.7
15.1.x	✓	✓	15.1.11
15.2.x	✓	✓	15.2.8
15.3.x	✓	✓	15.3.8
15.4.x	✓	✓	15.4.10
15.5.x	✓	✓	15.5.9
15.x canary	✓	✓	15.6.0-canary.60
16.0.x	✓	✓	16.0.10
16.x canary	✓	✓	16.1.0-canary.19

Pages Router applications are not affected, but we still recommend upgrading to a patched version.

Required Action

All users should upgrade to the latest patched version in their release line:

If you are on Next.js >=13.3, 14.0.x, or 14.1.x, upgrade to the latest 14.2.x release.

Terminal

npm install next@14.2.35  # for 14.x
npm install next@15.0.7   # for 15.0.x
npm install next@15.1.11  # for 15.1.x
npm install next@15.2.8   # for 15.2.x
npm install next@15.3.8   # for 15.3.x
npm install next@15.4.10  # for 15.4.x
npm install next@15.5.9   # for 15.5.x
npm install next@16.0.10  # for 16.0.x
 
npm install next@15.6.0-canary.60   # for 15.x canary releases
npm install next@16.1.0-canary.19   # for 16.x canary releases

Run npx fix-react2shell-next to launch an interactive tool which can check versions and perform deterministic version bumps per the recommended versions above. See the GitHub repository for full details.

Terminal

npx fix-react2shell-next

There is no workaround. Upgrading to a patched version is required.

Resources

CVE-2025-67779 (Complete DoS Fix): CVE, Next.js
CVE-2025-55184 (DoS): React, Next.js
CVE-2025-55183 (Source Code Exposure): React, Next.js
React blog: Denial of Service and Source Code Exposure in React Server Components
Previous Security Advisory: CVE-2025-66478

Discovery

Thank you to RyotaK from GMO Flatt Security Inc. and Andrew MacPherson for discovering and responsibly disclosing these vulnerabilities. We are intentionally limiting technical detail in this advisory to protect developers who have not yet upgraded.

Security Advisory: CVE-2025-66478

Invalid Date

December 06, 9:05 PM PST: If your application was online and unpatched as of December 4th, 2025 at 1:00 PM PT, we strongly encourage you to rotate any secrets it uses, starting with your most critical ones.

December 06, 7:29 AM PST: An npm package has been released to update affected Next.js apps. Use npx fix-react2shell-next to update now, or visit the GitHub repository to learn more.

A critical vulnerability has been identified in the React Server Components (RSC) protocol. The issue is rated CVSS 10.0 and can allow remote code execution when processing attacker-controlled requests in unpatched environments.

This vulnerability originates in the upstream React implementation (CVE-2025-55182). This advisory (CVE-2025-66478) tracks the downstream impact on Next.js applications using the App Router.

Impact

The vulnerable RSC protocol allowed untrusted inputs to influence server-side execution behavior. Under specific conditions, an attacker could craft requests that trigger unintended server execution paths. This can result in remote code execution in unpatched environments.

All users should upgrade to a patched version immediately. See the required action section for specific instructions.

Affected Next.js Versions

Applications using React Server Components with the App Router are affected when running:

Next.js 15.x
Next.js 16.x
Next.js 14.3.0-canary.77 and later canary releases

Next.js 13.x, Next.js 14.x stable, Pages Router applications, and the Edge Runtime are not affected.

Fixed Versions

The vulnerability is fully resolved in the following patched Next.js releases:

15.0.5
15.1.9
15.2.6
15.3.6
15.4.8
15.5.7
16.0.7

We also released patched canary releases for Next.js 15 and 16:

15.6.0-canary.58 (for 15.x canary releases)
16.1.0-canary.12 (for 16.x canary releases)

These versions include the hardened React Server Components implementation.

Required Action

All users should upgrade to the latest patched version in their release line:

Terminal

npm install next@15.0.5   # for 15.0.x
npm install next@15.1.9   # for 15.1.x
npm install next@15.2.6   # for 15.2.x
npm install next@15.3.6   # for 15.3.x
npm install next@15.4.8   # for 15.4.x
npm install next@15.5.7   # for 15.5.x
npm install next@16.0.7   # for 16.0.x
 
npm install next@15.6.0-canary.58   # for 15.x canary releases
npm install next@16.1.0-canary.12   # for 16.x canary releases

If you are on Next.js 14.3.0-canary.77 or a later canary release, downgrade to the latest stable 14.x release:

Terminal

npm install next@14

If you're currently using canary releases to enable PPR, you can update to 15.6.0-canary.58, which includes a fix for the vulnerability while continuing to support PPR. For other ways to patch older versions, see this discussion post.

Terminal

npx fix-react2shell-next

There is no workaround—upgrading to a patched version is required.

Rotating environment variables

Once you have patched your version and re-deployed your application, we recommend rotating all your application secrets. Learn about working with environment variables in the documentation here.

Resources

Discovery

Thank you to Lachlan Davidson for discovering and responsibly disclosing this vulnerability. We are intentionally limiting technical detail in this advisory to protect developers who have not yet upgraded.

Next.js 16

Invalid Date

Ahead of our upcoming Next.js Conf 2025, Next.js 16 is now available.

This release provides the latest improvements to Turbopack, caching, and the Next.js architecture. Since the previous beta release, we added several new features and improvements:

Cache Components: New model using Partial Pre-Rendering (PPR) and use cache for instant navigation.
Next.js Devtools MCP: Model Context Protocol integration for improved debugging and workflow.
Proxy: Middleware replaced by proxy.ts to clarify network boundary.
DX: Improved logging for builds and development requests.

For reminder, those features were available since the previous beta release:

Turbopack (stable): Default bundler for all apps with up to 5-10x faster Fast Refresh, and 2-5x faster builds
Turbopack File System Caching (beta): Even faster startup and compile times for the largest apps
React Compiler Support (stable): Built-in integration for automatic memoization
Build Adapters API (alpha): Create custom adapters to modify the build process
Enhanced Routing: Optimized navigations and prefetching with layout deduplication and incremental prefetching
Improved Caching APIs: New updateTag() and refined revalidateTag()
React 19.2: View Transitions, useEffectEvent(), <Activity/>
Breaking Changes: Async params, next/image defaults, and more

Upgrade to Next.js 16:

terminal

# Use the automated upgrade CLI
npx @next/codemod@canary upgrade latest
 
# ...or upgrade manually
npm install next@latest react@latest react-dom@latest
 
# ...or start a new project
npx create-next-app@latest

For cases where the codemod can't fully migrate your code, please read the upgrade guide.

New Features and Improvements

Cache Components

Cache Components are a new set of features designed to make caching in Next.js both more explicit, and more flexible. They center around the new "use cache" directive, which can be used to cache pages, components, and functions, and which leverages the compiler to automatically generate cache keys wherever it’s used.

Unlike the implicit caching found in previous versions of the App Router, caching with Cache Components is entirely opt-in. All dynamic code in any page, layout, or API route is executed at request time by default, giving Next.js an out-of-the-box experience that’s better aligned with what developers expect from a full-stack application framework.

Cache Components also complete the story of Partial Prerendering (PPR), which was first introduced in 2023. Prior to PPR, Next.js had to choose whether to render each URL statically or dynamically; there was no middle ground. PPR eliminated this dichotomy, and let developers opt portions of their static pages into dynamic rendering (via Suspense) without sacrificing the fast initial load of fully static pages.

You can enable Cache Components in your next.config.ts file:

next.config.ts

const nextConfig = {
  cacheComponents: true,
};
 
export default nextConfig;

We will be sharing more about Cache Components and how to use them at Next.js Conf 2025 on October 22nd, and we will be sharing more content in our blog and documentation in the coming weeks.

Note: as previously announced in the beta release, the previous experimental experimental.ppr flag and configuration options have been removed in favor of the Cache Components configuration.

Learn more in the documentation here.

Next.js Devtools MCP

Next.js 16 introduces Next.js DevTools MCP, a Model Context Protocol integration for AI-assisted debugging with contextual insight into your application.

The Next.js DevTools MCP provides AI agents with:

Next.js knowledge: Routing, caching, and rendering behavior
Unified logs: Browser and server logs without switching contexts
Automatic error access: Detailed stack traces without manual copying
Page awareness: Contextual understanding of the active route

This enables AI agents to diagnose issues, explain behavior, and suggest fixes directly within your development workflow.

Learn more in the documentation here.

`proxy.ts` (formerly `middleware.ts`)

proxy.ts replaces middleware.ts and makes the app’s network boundary explicit. proxy.ts runs on the Node.js runtime.

What to do: Rename middleware.ts → proxy.ts and rename the exported function to proxy. Logic stays the same.
Why: Clearer naming and a single, predictable runtime for request interception.

proxy.ts

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

Note: The middleware.ts file is still available for Edge runtime use cases, but it is deprecated and will be removed in a future version.

Learn more in the documentation here.

Logging Improvements

In Next.js 16 the development request logs are extended showing where time is spent.

Compile: Routing and compilation
Render: Running your code and React rendering

The build is also extended to show where time is spent. Each step in the build process is now shown with the time it took to complete.

terminal

   ▲ Next.js 16 (Turbopack)
 
 ✓ Compiled successfully in 615ms
 ✓ Finished TypeScript in 1114ms
 ✓ Collecting page data in 208ms
 ✓ Generating static pages in 239ms
 ✓ Finalizing page optimization in 5ms

The following features were previously announced in the beta release:

Developer Experience

Turbopack (stable)

Turbopack has reached stability for both development and production builds, and is now the default bundler for all new Next.js projects. Since its beta release earlier this summer, adoption has scaled rapidly: more than 50% of development sessions and 20% of production builds on Next.js 15.3+ are already running on Turbopack.

With Turbopack, you can expect:

2–5× faster production builds
Up to 10× faster Fast Refresh

We're making Turbopack the default to bring these performance gains to every Next.js developer, no configuration required. For apps with custom webpack setups, you can continue using webpack by running:

terminal

next dev --webpack
next build --webpack

Turbopack File System Caching (beta)

Turbopack now supports filesystem caching in development, storing compiler artifacts on disk between runs for significantly faster compile times across restarts, especially in large projects.

Enable filesystem caching in your configuration:

next.config.ts

const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForDev: true,
  },
};
 
export default nextConfig;

All internal Vercel apps are already using this feature, and we’ve seen notable improvements in developer productivity across large repositories.

We’d love to hear your feedback as we iterate on filesystem caching. Please try it out and share your experience.

Simplified `create-next-app`

create-next-app has been redesigned with a simplified setup flow, updated project structure, and improved defaults. The new template includes the App Router by default, TypeScript-first configuration, Tailwind CSS, and ESLint.

Build Adapters API (alpha)

Following the Build Adapters RFC, we've worked with the community and deployment platforms to deliver the first alpha version of the Build Adapters API.

Build Adapters allow you to create custom adapters that hook into the build process, enabling deployment platforms and custom build integrations to modify Next.js configuration or process build output.

next.config.js

const nextConfig = {
  experimental: {
    adapterPath: require.resolve('./my-adapter.js'),
  },
};
 
module.exports = nextConfig;

Share your feedback in the RFC discussion.

React Compiler Support (stable)

Built-in support for the React Compiler is now stable in Next.js 16 following the React Compiler's 1.0 release. The React Compiler automatically memoizes components, reducing unnecessary re-renders with zero manual code changes.

The reactCompiler configuration option has been promoted from experimental to stable. It is not enabled by default as we continue gathering build performance data across different application types. Expect compile times in development and during builds to be higher when enabling this option as the React Compiler relies on Babel.

next.config.ts

const nextConfig = {
  reactCompiler: true,
};
 
export default nextConfig;

Install the latest version of the React Compiler plugin:

terminal

npm install babel-plugin-react-compiler@latest

Core Features & Architecture

Next.js 16 includes a complete overhaul of the routing and navigation system, making page transitions leaner and faster.

Layout deduplication: When prefetching multiple URLs with a shared layout, the layout is downloaded once instead of separately for each Link. For example, a page with 50 product links now downloads the shared layout once instead of 50 times, dramatically reducing the network transfer size.

Incremental prefetching: Next.js only prefetches parts not already in cache, rather than entire pages. The prefetch cache now:

Cancels requests when the link leaves the viewport
Prioritizes link prefetching on hover or when re-entering the viewport
Re-prefetches links when their data is invalidated
Works seamlessly with upcoming features like Cache Components

Trade-off: You may see more individual prefetch requests, but with much lower total transfer sizes. We believe this is the right trade-off for nearly all applications. If the increased request count causes issues, please let us know. We're working on additional optimizations to inline data chunks more efficiently.

These changes require no code modifications and are designed to improve performance across all apps.

Improved Caching APIs

Next.js 16 introduces refined caching APIs for more explicit control over cache behavior.

`revalidateTag()` (updated)

revalidateTag() now requires a cacheLife profile as the second argument to enable stale-while-revalidate (SWR) behavior:

import { revalidateTag } from 'next/cache';
 
// ✅ Use built-in cacheLife profile (we recommend 'max' for most cases)
revalidateTag('blog-posts', 'max');
 
// Or use other built-in profiles
revalidateTag('news-feed', 'hours');
revalidateTag('analytics', 'days');
 
// Or use an inline object with a custom revalidation time
revalidateTag('products', { expire: 3600 });
 
// ⚠️ Deprecated - single argument form
revalidateTag('blog-posts');

The profile argument accepts built-in cacheLife profile names (like 'max', 'hours', 'days') or custom profiles defined in your next.config. You can also pass an inline { expire: number } object. We recommend using 'max' for most cases, as it enables background revalidation for long-lived content. When users request tagged content, they receive cached data immediately while Next.js revalidates in the background.

Use revalidateTag() when you want to invalidate only properly tagged cached entries with stale-while-revalidate behavior. This is ideal for static content that can tolerate eventual consistency.

Migration guidance: Add the second argument with a cacheLife profile (we recommend 'max') for SWR behavior, or use updateTag() in Server Actions if you need read-your-writes semantics.

`updateTag()` (new)

updateTag() is a new Server Actions-only API that provides read-your-writes semantics, expiring and immediately reading fresh data within the same request:

'use server';
 
import { updateTag } from 'next/cache';
 
export async function updateUserProfile(userId: string, profile: Profile) {
  await db.users.update(userId, profile);
 
  // Expire cache and refresh immediately - user sees their changes right away
  updateTag(`user-${userId}`);
}

This ensures interactive features reflect changes immediately. Perfect for forms, user settings, and any workflow where users expect to see their updates instantly.

`refresh()` (new)

refresh() is a new Server Actions-only API for refreshing uncached data only. It doesn't touch the cache at all:

'use server';
 
import { refresh } from 'next/cache';
 
export async function markNotificationAsRead(notificationId: string) {
  // Update the notification in the database
  await db.notifications.markAsRead(notificationId);
 
  // Refresh the notification count displayed in the header
  // (which is fetched separately and not cached)
  refresh();
}

This API is complementary to the client-side router.refresh(). Use it when you need to refresh uncached data displayed elsewhere on the page after performing an action. Your cached page shells and static content remain fast while dynamic data like notification counts, live metrics, or status indicators refresh.

React 19.2 and Canary Features

The App Router in Next.js 16 uses the latest React Canary release, which includes the newly released React 19.2 features and other features being incrementally stabilized. Highlights include:

View Transitions: Animate elements that update inside a Transition or navigation
useEffectEvent: Extract non-reactive logic from Effects into reusable Effect Event functions
Activity: Render "background activity" by hiding UI with display: none while maintaining state and cleaning up Effects

Learn more in the React 19.2 announcement.

Breaking Changes and Other Updates

Version Requirements

Change	Details
Node.js 20.9+	Minimum version now 20.9.0 (LTS); Node.js 18 no longer supported
TypeScript 5+	Minimum version now 5.1.0
Browsers	Chrome 111+, Edge 111+, Firefox 111+, Safari 16.4+

Removals

These features were previously deprecated and are now removed:

Removed	Replacement
AMP support	All AMP APIs and configs removed (`useAmp`, `export const config = { amp: true }`)
`next lint` command	Use Biome or ESLint directly; `next build` no longer runs linting. A codemod is available: `npx @next/codemod@canary next-lint-to-eslint-cli .`
`devIndicators` options	`appIsrStatus`, `buildActivity`, `buildActivityPosition` removed from config. The indicator remains.
`serverRuntimeConfig`, `publicRuntimeConfig`	Use environment variables (`.env` files)
`experimental.turbopack` location	Config moved to top-level `turbopack` (no longer in `experimental`)
`experimental.dynamicIO` flag	Renamed to `cacheComponents`
`experimental.ppr` flag	PPR flag removed; evolving into Cache Components programming model
`export const experimental_ppr`	Route-level PPR export removed; evolving into Cache Components programming model
Automatic `scroll-behavior: smooth`	Add `data-scroll-behavior="smooth"` to HTML document to opt back in
`unstable_rootParams()`	We are working on an alternative API that we will ship in an upcoming minor
Sync `params`, `searchParams` props access	Must use async: `await params`, `await searchParams`
Sync `cookies()`, `headers()`, `draftMode()` access	Must use async: `await cookies()`, `await headers()`, `await draftMode()`
Metadata image route `params` argument	Changed to async `params`; `id` from `generateImageMetadata` now `Promise<string>`
`next/image` local src with query strings	Now requires `images.localPatterns` config to prevent enumeration attacks

Behavior Changes

These features have new default behaviors in Next.js 16:

Changed Behavior	Details
Default bundler	Turbopack is now the default bundler for all apps; opt out with `next build --webpack`
`images.minimumCacheTTL` default	Changed from 60s to 4 hours (14400s); reduces revalidation cost for images without cache-control headers
`images.imageSizes` default	Removed `16` from default sizes (used by only 4.2% of projects); reduces srcset size and API variations
`images.qualities` default	Changed from `[1..100]` to `[75]`; `quality` prop is now coerced to closest value in `images.qualities`
`images.dangerouslyAllowLocalIP`	New security restriction blocks local IP optimization by default; set to `true` for private networks only
`images.maximumRedirects` default	Changed from unlimited to 3 redirects maximum; set to `0` to disable or increase for rare edge cases
`@next/eslint-plugin-next` default	Now defaults to ESLint Flat Config format, aligning with ESLint v10 which will drop legacy config support
Prefetch cache behavior	Complete rewrite with layout deduplication and incremental prefetching
`revalidateTag()` signature	Now requires `cacheLife` profile as second argument for stale-while-revalidate behavior
Babel configuration in Turbopack	Automatically enables Babel if a babel config is found (previously exited with hard error)
Terminal output	Redesigned with clearer formatting, better error messages, and improved performance metrics
Dev and build output directories	`next dev` and `next build` now use separate output directories, enabling concurrent execution
Lockfile behavior	Added lockfile mechanism to prevent multiple `next dev` or `next build` instances on the same project
Parallel routes `default.js`	All parallel route slots now require explicit `default.js` files; builds fail without them. Create `default.js` that calls `notFound()` or returns `null` for previous behavior
Modern Sass API	Bumped `sass-loader` to v16, which supports modern Sass syntax and new features

Deprecations

These features are deprecated in Next.js 16 and will be removed in a future version:

Deprecated	Details
`middleware.ts` filename	Rename to `proxy.ts` to clarify network boundary and routing focus
`next/legacy/image` component	Use `next/image` instead for improved performance and features
`images.domains` config	Use `images.remotePatterns` config instead for improved security restriction
`revalidateTag()` single argument	Use `revalidateTag(tag, profile)` for SWR, or `updateTag(tag)` in Actions for read-your-writes

Additional Improvements

Performance improvements: Significant performance optimizations for next dev and next start commands
Node.js native TypeScript for next.config.ts: Run next dev, next build, and next start commands with --experimental-next-config-strip-types flag to enable native TypeScript for next.config.ts.

We'll aim to share a more comprehensive migration guide ahead of the stable release in our documentation.

Feedback and Community

Share your feedback and help shape the future of Next.js:

Contributors

Next.js is the result of the combined work of over 3,000 individual developers. This release was brought to you by:

The Next.js team: Andrew, Hendrik, Janka, Jiachi, Jimmy, Jiwon, JJ, Josh, Jude, Sam, Sebastian, Sebbie, Wyatt, and Zack.
The Turbopack team: Benjamin, Josh, Luke, Niklas, Tim, Tobias, and Will.
The Next.js Docs team: Delba, Rich, Ismael, and Joseph.

Huge thanks to @mischnic, @timneutkens, @unstubbable, @wyattjoh, @Cy-Tek, @lukesandberg, @OoMNoO, @ztanner, @icyJoseph, @huozhi, @gnoff, @ijjk, @povilasv, @dwrth, @obendev, @aymericzip, @devjiwonchoi, @SyMind, @vercel-release-bot, @Shireee, @eps1lon, @dharun36, @kachkaev, @bgw, @yousefdawood7, @TheAlexLichter, @sokra, @ericx0099, @leerob, @Copilot, @fireairforce, @fufuShih, @anvibanga, @hayes, @Milancen123, @martinfrancois, @lubieowoce, @gaojude, @lachlanjc, @liketiger, @styfle, @aaronbrown-vercel, @Samii2383, @FelipeChicaiza, @kevva, @m1abdullahh, @F7b5, @Anshuman71, @RobertFent, @poteto, @chloe-yan, @sireesha-siri, @brian-lou, @joao4xz, @stefanprobst, @samselikoff, @acdlite, @gwkline, @bgub, @brock-statsig, and @karlhorky for helping!

Next.js 16 (beta)

Invalid Date

Next.js 16 (beta) is now available. This early release provides access to the latest improvements to Turbopack, caching, and the Next.js architecture ahead of the stable release. Highlights for this release include:

Turbopack (stable): Default bundler for all apps with up to 5-10x faster Fast Refresh, and 2-5x faster builds
Turbopack File System Caching (beta): Even faster startup and compile times for the largest apps
React Compiler Support (stable): Built-in integration for automatic memoization
Build Adapters API (alpha): Create custom adapters to modify the build process
Enhanced Routing: Optimized navigations and prefetching with layout deduplication and incremental prefetching
Improved Caching APIs: New updateTag() and refined revalidateTag()
React 19.2: View Transitions, useEffectEvent(), <Activity/>
Breaking Changes: Async params, next/image defaults, and more

We encourage you to try the beta and share your feedback. Your testing helps us identify issues and improve Next.js before the stable release. Please report any bugs or issues you encounter on GitHub.

Upgrade to the beta:

terminal

# Use the automated upgrade CLI
npx @next/codemod@canary upgrade beta
 
# ...or upgrade manually
npm install next@beta react@latest react-dom@latest
 
# ...or start a new project
npx create-next-app@beta

Developer Experience

Turbopack (stable)

With Turbopack, you can expect:

2–5× faster production builds
Up to 10× faster Fast Refresh

terminal

next dev --webpack
next build --webpack

Turbopack File System Caching (beta)

Turbopack now supports filesystem caching in development, storing compiler artifacts on disk between runs for significantly faster compile times across restarts, especially in large projects.

Enable filesystem caching in your configuration:

next.config.ts

const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForDev: true,
  },
};
 
export default nextConfig;

All internal Vercel apps are already using this feature, and we’ve seen notable improvements in developer productivity across large repositories.

We’d love to hear your feedback as we iterate on filesystem caching. Please try it out and share your experience.

Simplified `create-next-app`

Build Adapters API (alpha)

Following the Build Adapters RFC, we've worked with the community and deployment platforms to deliver the first alpha version of the Build Adapters API.

next.config.js

const nextConfig = {
  experimental: {
    adapterPath: require.resolve('./my-adapter.js'),
  },
};
 
module.exports = nextConfig;

Share your feedback in the RFC discussion.

React Compiler Support (stable)

next.config.ts

const nextConfig = {
  reactCompiler: true,
};
 
export default nextConfig;

Install the latest version of the React Compiler plugin:

terminal

npm install babel-plugin-react-compiler@latest

Core Features & Architecture

Next.js 16 includes a complete overhaul of the routing and navigation system, making page transitions leaner and faster.

Incremental prefetching: Next.js only prefetches parts not already in cache, rather than entire pages. The prefetch cache now:

Cancels requests when the link leaves the viewport
Prioritizes link prefetching on hover or when re-entering the viewport
Re-prefetches links when their data is invalidated
Works seamlessly with upcoming features like Cache Components

These changes require no code modifications and are designed to improve performance across all apps.

PPR and Cache Components

Next.js 16 removes the experimental Partial Pre-Rendering (PPR) flag and configuration options. PPR is being integrated into Cache Components.

Starting with Next.js 16, you can opt into PPR using the experimental.cacheComponents configuration. There are differences in the implementation and Cache Components brings additional features and behaviors that will be documented and announced ahead of Next.js Conf and the Next.js 16 stable release.

If your application relies on PPR (experimental.ppr = true): Stay on the pinned version of Next.js canary you currently use. If you have trouble migrating, stay on your current version for now, and we will provide a migration guide ahead of the stable release.

Improved Caching APIs

Next.js 16 introduces refined caching APIs for more explicit control over cache behavior.

`revalidateTag()` (updated)

revalidateTag() now requires a cacheLife profile as the second argument to enable stale-while-revalidate (SWR) behavior:

import { revalidateTag } from 'next/cache';
 
// ✅ Use built-in cacheLife profile (we recommend 'max' for most cases)
revalidateTag('blog-posts', 'max');
 
// Or use other built-in profiles
revalidateTag('news-feed', 'hours');
revalidateTag('analytics', 'days');
 
// Or use an inline object with a custom revalidation time
revalidateTag('products', { revalidate: 3600 });
 
// ⚠️ Deprecated - single argument form
revalidateTag('blog-posts');

The profile argument accepts built-in cacheLife profile names (like 'max', 'hours', 'days') or custom profiles defined in your next.config. You can also pass an inline { revalidate: number } object. We recommend using 'max' for most cases, as it enables background revalidation for long-lived content. When users request tagged content, they receive cached data immediately while Next.js revalidates in the background.

Use revalidateTag() when you want to invalidate only properly tagged cached entries with stale-while-revalidate behavior. This is ideal for static content that can tolerate eventual consistency.

Migration guidance: Add the second argument with a cacheLife profile (we recommend 'max') for SWR behavior, or use updateTag() in Server Actions if you need read-your-writes semantics.

`updateTag()` (new)

updateTag() is a new Server Actions-only API that provides read-your-writes semantics, expiring and immediately refreshing cached data within the same request:

'use server';
 
import { updateTag } from 'next/cache';
 
export async function updateUserProfile(userId: string, profile: Profile) {
  await db.users.update(userId, profile);
 
  // Expire cache and refresh immediately - user sees their changes right away
  updateTag(`user-${userId}`);
}

This ensures interactive features reflect changes immediately. Perfect for forms, user settings, and any workflow where users expect to see their updates instantly.

`refresh()` (new)

refresh() is a new Server Actions-only API for refreshing uncached data only. It doesn't touch the cache at all:

'use server';
 
import { refresh } from 'next/cache';
 
export async function markNotificationAsRead(notificationId: string) {
  // Update the notification in the database
  await db.notifications.markAsRead(notificationId);
 
  // Refresh the notification count displayed in the header
  // (which is fetched separately and not cached)
  refresh();
}

React 19.2 and Canary Features

The App Router in Next.js 16 uses the latest React Canary release, which includes the newly released React 19.2 features and other features being incrementally stabilized. Highlights include:

View Transitions: Animate elements that update inside a Transition or navigation
useEffectEvent: Extract non-reactive logic from Effects into reusable Effect Event functions
Activity: Render "background activity" by hiding UI with display: none while maintaining state and cleaning up Effects

Learn more in the React 19.2 announcement.

Breaking Changes and Other Updates

Version Requirements

Change	Details
Node.js 20.9+	Minimum version now 20.9.0 (LTS); Node.js 18 no longer supported
TypeScript 5+	Minimum version now 5.1.0
Browsers	Chrome 111+, Edge 111+, Firefox 111+, Safari 16.4+

Removals

These features were previously deprecated and are now removed:

Removed	Replacement
AMP support	All AMP APIs and configs removed (`useAmp`, `export const config = { amp: true }`)
`next lint` command	Use Biome or ESLint directly; `next build` no longer runs linting. A codemod is available: `npx @next/codemod@canary next-lint-to-eslint-cli .`
`devIndicators` options	`appIsrStatus`, `buildActivity`, `buildActivityPosition` removed from config. The indicator remains.
`serverRuntimeConfig`, `publicRuntimeConfig`	Use environment variables (`.env` files)
`experimental.turbopack` location	Config moved to top-level `turbopack` (no longer in `experimental`)
`experimental.dynamicIO` flag	Renamed to `experimental.cacheComponents`
`experimental.ppr` flag	PPR flag removed; evolving into Cache Components programming model
`export const experimental_ppr`	Route-level PPR export removed; evolving into Cache Components programming model
Automatic `scroll-behavior: smooth`	Add `data-scroll-behavior="smooth"` to HTML document to opt back in
`unstable_rootParams()`	We are working on an alternative API that we will ship in an upcoming minor
Sync `params`, `searchParams` props access	Must use async: `await params`, `await searchParams`
Sync `cookies()`, `headers()`, `draftMode()` access	Must use async: `await cookies()`, `await headers()`, `await draftMode()`
Metadata image route `params` argument	Changed to async `params`; `id` from `generateImageMetadata` now `Promise<string>`
`next/image` local src with query strings	Now requires `images.localPatterns` config to prevent enumeration attacks

Behavior Changes

These features have new default behaviors in Next.js 16:

Changed Behavior	Details
Default bundler	Turbopack is now the default bundler for all apps; opt out with `next build --webpack`
`images.minimumCacheTTL` default	Changed from 60s to 4 hours (14400s); reduces revalidation cost for images without cache-control headers
`images.imageSizes` default	Removed `16` from default sizes (used by only 4.2% of projects); reduces srcset size and API variations
`images.qualities` default	Changed from `[1..100]` to `[75]`; `quality` prop is now coerced to closest value in `images.qualities`
`images.dangerouslyAllowLocalIP`	New security restriction blocks local IP optimization by default; set to `true` for private networks only
`images.maximumRedirects` default	Changed from unlimited to 3 redirects maximum; set to `0` to disable or increase for rare edge cases
`@next/eslint-plugin-next` default	Now defaults to ESLint Flat Config format, aligning with ESLint v10 which will drop legacy config support
Prefetch cache behavior	Complete rewrite with layout deduplication and incremental prefetching
`revalidateTag()` signature	Now requires `cacheLife` profile as second argument for stale-while-revalidate behavior
Babel configuration in Turbopack	Automatically enables Babel if a babel config is found (previously exited with hard error)
Terminal output	Redesigned with clearer formatting, better error messages, and improved performance metrics
Dev and build output directories	`next dev` and `next build` now use separate output directories, enabling concurrent execution
Lockfile behavior	Added lockfile mechanism to prevent multiple `next dev` or `next build` instances on the same project
Parallel routes `default.js`	All parallel route slots now require explicit `default.js` files; builds fail without them. Create `default.js` that calls `notFound()` or returns `null` for previous behavior
Modern Sass API	Bumped `sass-loader` to v16, which supports modern Sass syntax and new features

Deprecations

These features are deprecated in Next.js 16 and will be removed in a future version:

Deprecated	Details
`middleware.ts` filename	Rename to `proxy.ts` to clarify network boundary and routing focus
`next/legacy/image` component	Use `next/image` instead for improved performance and features
`images.domains` config	Use `images.remotePatterns` config instead for improved security restriction
`revalidateTag()` single argument	Use `revalidateTag(tag, profile)` for SWR, or `updateTag(tag)` in Actions for read-your-writes

Additional Improvements

Performance improvements: Significant performance optimizations for next dev and next start commands
Node.js native TypeScript for next.config.ts: Run next dev, next build, and next start commands with --experimental-next-config-strip-types flag to enable native TypeScript for next.config.ts.

We'll aim to share a more comprehensive migration guide ahead of the stable release in our documentation.

Feedback and Community

Share your feedback and help shape the future of Next.js:

Contributors

Next.js is the result of the combined work of over 3,000 individual developers. This release was brought to you by:

The Next.js team: Andrew, Hendrik, Janka, Jiachi, Jimmy, Jiwon, JJ, Josh, Jude, Sam, Sebastian, Sebbie, Wyatt, and Zack.
The Turbopack team: Benjamin, Josh, Luke, Niklas, Tim, Tobias, and Will.
The Next.js Docs team: Delba, Rich, Ismael, and Joseph.

Next.js 15.5

Invalid Date

Next.js 15.5 includes Turbopack builds in beta, stable Node.js middleware, TypeScript improvements, next lint deprecation, and deprecation warnings for Next.js 16. Highlights for this release include:

Turbopack Builds (beta): Production turbopack builds (next build --turbopack) now in beta
Node.js Middleware (stable): Node.js runtime support for middleware is now stable
TypeScript Improvements: Typed routes, route export validation, and route types helpers
next lint: Deprecation of next lint command
Next.js 16: Deprecation warnings for Next.js 16

Upgrade today, or get started with:

terminal

# Use the automated upgrade CLI
npx @next/codemod@canary upgrade latest
 
# ...or upgrade manually
npm install next@latest react@latest react-dom@latest
 
# ...or start a new project
npx create-next-app@latest

Turbopack Builds (beta)

We're excited to announce next build --turbopack in beta. Turbopack now powers Vercel websites including vercel.com, v0.app, and nextjs.org, accelerating iteration velocity through faster preview and production deployment builds.

These applications powered by Turbopack have been battle tested serving over 1.2 billion requests since the rollout.

Performance & Production Results

One of the original design goals for Turbopack was to be able to help developers scale build performance as their applications and codebases grow. To achieve this, Turbopack was designed from the ground up to take advantage of multiple CPU cores throughout all phases of the build.

We've deployed builds with Turbopack across many Vercel products and saw consistent improvements in compilation time:

Customer site: 2x faster on a 4 core machine
Customer site: 2.2x faster on a 14 core machine
Small site (10K modules): 4x faster on a 30 core machine
Medium site (40K modules): 2.5x faster on a 30 core machine
Large site (70K modules): 5x faster on a 30 core machine

As we rolled out Turbopack to our major web applications, we closely monitored for production performance regressions and breakages.

When compared with Webpack, our production metrics monitoring shows that sites built with Turbopack serve similar or smaller amounts of JavaScript and CSS across fewer requests, leading to comparable or better FCP, LCP and TTFB metrics.

For teams that have adopted Turbopack in development, we now recommend trying Turbopack for builds.

Known Differences

Smaller projects: On smaller machines or smaller projects, we measured marginal or neutral improvements to the build times due to Webpack's built-in persistent cache. We are currently working on a Persistent Caching solution for Turbopack to deliver on our design goal of making all builds incremental and fast.

Bundle optimization: In some edge cases, we measured that webpack produced more optimized bundles. We are tracking those scenarios and are working on closing the gap before the stable release. See the documentation on bundle sizes for more information.

CSS ordering: Due to different heuristics about side-effects handling in Turbopack, CSS files can be concatenated in a different order than webpack, leading to potential visual differences. See the documentation for a more detailed explanation and suggested solutions.

Note: These differences are documented and we're actively working on improvements. For detailed information and workarounds, see our Turbopack documentation.

As we iterate towards the stable release, please report any issues on GitHub.

Node.js Middleware (stable)

After introducing experimental support for the Node.js runtime in our 15.2 release and testing extensively on our production applications, we're excited to announce stable support for Node.js middleware runtime.

Previously, Next.js middleware only supported the Edge Runtime, which provided better performance and isolation but had limitations when integrating with Node.js-specific libraries and APIs.

middleware.ts

import { NextRequest, NextResponse } from 'next/server';
 
export const config = {
  runtime: 'nodejs', // Now stable!
};
 
export function middleware(request: NextRequest) {
  // Access to full Node.js APIs and npm packages
  const fs = require('fs');
  const crypto = require('crypto');
 
  // Complex authentication logic
  const token = request.headers.get('authorization');
 
  if (!isValidToken(token)) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
 
  return NextResponse.next();
}
 
function isValidToken(token: string | null): boolean {
  // Use Node.js crypto for validation
  // Access file system, databases, etc.
  return true;
}

This change enables middleware to handle more complex use cases while maintaining the same developer experience.

Although Node.js runtime won't be the default in Next.js 16, we are exploring making it the default starting with Next.js 17 based on community feedback and usage patterns.

TypeScript Improvements

Next.js 15.5 brings major TypeScript improvements to the App Router, with full Turbopack compatibility and comprehensive type safety for routing.

Typed Routes (stable)

Typed routes provide compile-time type safety for your application's routes, catching invalid links before they reach production. This feature automatically generates types based on your file structure, ensuring that every <Link> component points to a valid route.

This feature is available behind the typedRoutes flag, which was previously experimental and is now stable. Statically typed routes now work with Turbopack through a new implementation that provides type safety across both Webpack and Turbopack builds:

next.config.ts

const nextConfig = {
  typedRoutes: true, // Now stable!
};
 
export default nextConfig;

import Link from 'next/link'
 
// Full type safety for route paths
<Link href="/blog/example-slug?ui=dark">Read Post</Link>
 
// TypeScript catches invalid routes at compile time
<Link href="/invalid-route">Broken Link</Link> // ← Type error

Route Export Validation (Turbopack)

Route export validation also works on Turbopack through a new system that generates a type guard file, validating pages, layouts, and route handlers using TypeScript's satisfies operator.

This catches invalid exports like incorrect dynamic values during compilation when running next build, replacing the old Webpack plugin with a more performant solution that works across both build systems.

Route Props Helpers

Next.js automatically generates globally available PageProps, LayoutProps, and RouteContext types with full parameter typing and no imports required:

Before: Manual typing and imports

import { Metadata } from 'next';
 
interface Props {
  params: Promise<{ slug: string }>;
  children: React.ReactNode;
  analytics: React.ReactNode; // Manual parallel route typing
  team: React.ReactNode; // Manual parallel route typing
}
 
export default function DashboardLayout(props: Props) {
  return (
    <div>
      {props.children}
      {props.analytics} {/* No type safety for parallel routes */}
      {props.team} {/* No type safety for parallel routes */}
    </div>
  );
}

After: Automatic typing with parallel route support

// No need to import LayoutProps - globally available
export default function DashboardLayout(props: LayoutProps<'/dashboard'>) {
  return (
    <div>
      {props.children}
      {props.analytics} {/* Fully typed parallel route slot */}
      {props.team} {/* Fully typed parallel route slot */}
    </div>
  );
}

The system automatically discovers routes from your file structure, supporting dynamic routes, parallel routes, and custom routes from next.config.js. Type generation runs in both development and build modes, immediately regenerating types when your file structure changes in development, and scales efficiently to large projects by generating only a few optimized files instead of the many individual files used in the previous implementation.

`next typegen`

We've added a next typegen command for manual type generation without running next dev or next build. This is particularly useful for external type validation scenarios.

terminal

next typegen [directory]

Previously, route types were only generated during next dev or next build, which meant running tsc --noEmit directly wouldn't validate your route types. Now you can generate types independently and validate them externally:

terminal

# Generate route types first, then validate with TypeScript
next typegen && tsc --noEmit
 
# Or in CI workflows for type checking without building
next typegen && npm run type-check

`next lint` Deprecation

Starting with Next.js 15.5, the next lint command shows a deprecation warning and will be removed in Next.js 16. This modernizes the linting experience by transitioning to explicit ESLint configurations and introducing Biome as a fast alternative.

When creating a new Next.js project, you can now choose between ESLint (comprehensive rules), Biome (fast with fewer rules), or no linter. ESLint projects now generate explicit eslint.config.mjs files instead of relying on the next lint command wrapper, providing complete transparency into your linting rules.

Biome projects receive optimized configurations with Next.js and React rules plus built-in formatting capabilities. Generated package.json scripts now call linters directly:

{
  "scripts": {
    // ESLint projects
    "lint": "eslint", // Instead of "next lint"
    "lint:fix": "eslint --fix",
 
    // For Biome projects
    "lint": "biome check",
    "format": "biome format --write"
  }
}

For existing projects, a new codemod automates the migration from next lint to ESLint CLI:

terminal

npx @next/codemod@latest next-lint-to-eslint-cli .

The codemod intelligently transforms package.json scripts while preserving functionality, mapping Next.js-specific flags like --strict to --max-warnings 0, and automatically installing required dependencies.

This transition gives developers direct control over their linting setup with better ecosystem compatibility.

Note: next build will still run a linting validation step if an ESLint config is present. This automatic linting during builds will also be removed in Next.js 16, giving you complete control over when and how linting runs.

Deprecation Warnings for Next.js 16

Next.js 15.5 introduces deprecation warnings to help you prepare for the upcoming Next.js 16 release. These warnings appear in development and build logs, giving you time to migrate before these features are removed.

`legacyBehavior` for `next/link`

The legacyBehavior prop for next/link will be removed in Next.js 16. This prop was introduced as a temporary compatibility layer during the Next.js 12 to 13 transition.

// ❌ Will be removed in Next.js 16
<Link href="/about" legacyBehavior>
  <a>About</a>
</Link>
 
// ✅ Modern approach (no changes needed)
<Link href="/about">About</Link>

Migration: Remove the legacyBehavior prop and any child <a> elements. The Link component now handles styling and accessibility automatically.

AMP Support

Next.js AMP support will be removed in Next.js 16. AMP adoption has declined significantly, and maintaining this feature adds complexity to the framework. All AMP-related APIs and configurations will be removed.

pages/amp-page.js

// ❌ Will be removed in Next.js 16
import { useAmp } from 'next/amp';
 
export const config = { amp: true };
 
export default function AmpPage() {
  const isAmp = useAmp();
  return <div>AMP Page: {isAmp ? 'AMP' : 'HTML'}</div>;
}

next.config.ts

const nextConfig = {
  amp: {
    // ❌ Will be removed in Next.js 16
    canonicalBase: 'https://example.com',
  },
};
 
export default nextConfig;

Migration: Remove all AMP-related code including:

export const config = { amp: true } from pages
amp configuration from your next.config.ts
next/amp hook imports and usage (useAmp)
Any other AMP-specific APIs

Evaluate if AMP is still necessary for your use case. Most performance benefits can now be achieved through Next.js's built-in optimizations and modern web standards.

`next/image` Quality Settings

Starting in Next.js 16, the quality prop will be restricted to only 75 by default. Currently in Next.js 15, you can use any integer from 1 to 100, but Next.js 16 will require explicit configuration for qualities other than 75.

// ⚠️ Will show deprecation warning in Next.js 15.5
// when images.qualities is undefined and quality !== 75
<Image src="/photo.jpg" quality={100} alt="Photo" />
 
// ✅ Explicit configuration required for Next.js 16

next.config.ts

const nextConfig = {
  images: {
    qualities: [75, 100], // Explicitly allow quality={100}
  },
};
 
export default nextConfig;

Migration: If you use quality props other than 75, explicitly configure images.qualities in your next.config.ts to include the quality values you need for Next.js 16.

`next/image` Local Patterns

Starting in Next.js 16, using query strings with local image src paths will require explicit configuration in images.localPatterns. This affects images with query parameters like cache-busting or versioning.

// ⚠️ Will show deprecation warning in Next.js 15.5
// when images.localPatterns is not configured
<Image src="/photo.jpg?v=1" alt="Test" />
 
// ✅ Explicit configuration required for Next.js 16

next.config.ts

const nextConfig = {
  images: {
    localPatterns: [
      {
        pathname: '/photo.jpg', // allow exact path
        // omitting "search" will allow all query parameters
      },
      {
        pathname: '/photo.jpg', // allow exact path
        search: '?v=1', // allow exact query parameters
      },
      {
        pathname: '/assets/**', // allow wildcard path
        search: '', // empty search will block all query parameters
      },
    ],
  },
};
 
export default nextConfig;

Migration: Configure images.localPatterns in your next.config.ts to explicitly allow query strings in your image paths. This provides better security and performance optimization.

Timeline

These deprecation warnings will appear starting with Next.js 15.5. The features will be completely removed in Next.js 16. We recommend migrating as soon as possible to avoid issues during the upgrade.

Share your feedback and help shape the future of Next.js:

Contributors

Next.js is the result of the combined work of over 3,000 individual developers. This release was brought to you by:

The Next.js team: Andrew, Ben, Hendrik, Janka, Jiachi, Jimmy, Jiwon, JJ, Josh, Jude, Rob, Sam, Sebastian, Sebbie, Wyatt, and Zack.
The Turbopack team: Benjamin, Josh, Luke, Maia, Niklas, Tim, Tobias, and Will.
The Next.js Docs team: Delba, Rich, Ismael, Joseph, and Lee.

Huge thanks to @unstubbable, @gnoff, @RobPruzan, @mischnic, @huozhi, @delbaoliveira, @styfle, @ankur-arch, @skt-t1-byungi, @ijjk, @Han5991, @SyMind, @Anas-github-acc, @hf, @bgw, @wyattjoh, @ztanner, @prateekkish, @eps1lon, @lubieowoce, @timneutkens, @acdlite, @lukesandberg, @bgub, @Cy-Tek, @padmaia, @raunofreiberg, @devjiwonchoi, @sokra, @MidnightDesign, @stephenliang, @allenzhou101, @icyJoseph, @gaojude, @remcohaszing, @wesjune, @wbinnssmith, @m1abdullahh, @Sayakie, @startracex, @chadfennell, @dlehmhus, @Jarred-Sumner, @candymask0712, @stepan662, @PuppyOne, @huperniketes, @xusd320, @MichalMoravik, @fireairforce, @kitfoster, @feedthejim, and @r34son for helping!

Next.js 15.4

Invalid Date

Next.js 15.4 includes updates to performance, stability, and Turbopack compatibility. Highlights for this release include:

Turbopack Builds: 100% integration test compatibility for next build --turbopack
Stability Improvements: Numerous stability and performance improvements to Next.js and Turbopack

This blog post also includes an early preview of what's coming in Next.js 16, our next major release.

Upgrade today, or get started with:

Terminal

# Use the automated upgrade CLI
npx @next/codemod@canary upgrade latest
 
# ...or upgrade manually
npm install next@latest react@latest react-dom@latest
 
# ...or start a new project
npx create-next-app@latest

Turbopack Builds

next build --turbopack now passes all 8298 integration tests for production builds and now powers vercel.com. This is a crucial milestone towards marking Turbopack in Next.js stable.

The team's current priority is to finish the swing on bundling optimizations via production chunking and to fix reported bugs from early adopters of the Alpha release. We've also made numerous stability and performance improvements to Turbopack under the hood.

We are confident that Turbopack will soon be ready for production use, and we're working towards a beta release in Next.js 16. If you had tried Turbopack previously, now is a good time to try again. If you run into any issues let us know on GitHub Issues.

Looking Ahead: Next.js 16

Over the past few months, we've been iterating on major improvements to Next.js, focusing on both the developer experience with Turbopack and the core capacities of the App Router with PPR and use cache. While we are not ready to enable those features on by default, we are looking to lay the groundwork for our users to try it out in Next.js 16 this summer.

Here’s a preview of what's coming in Next.js 16:

Cache Components (beta): Consolidates experimental caching features (Dynamic IO, use cache, and Partial Prerendering) into a unified cacheComponents flag, simplifying performance optimization strategies. The Next.js 16 blog post will detail our vision.
Turbopack Builds (beta): Introduces next build --turbopack, fully passing integration tests, and validated internally on high-traffic sites like vercel.com. Ready for expanded public beta use in Next.js 16.
Optimized Client-Side Routing: Enhances App Router navigation with smarter prefetching, improved cache invalidation strategies, and reduced bandwidth usage, resulting in faster and more responsive navigation.
DevTools & Debugging: Adds Route Info to inspect app structure and toggle components like loading.tsx. Adds experimental browser log forwarding to the terminal to support AI-powered debugging workflows.
Node.js Middleware (stable): Promotes the previously experimental Node.js runtime support for Middleware, initially introduced in Next.js 15.2, to stable status.
Deployment Adapters (alpha): Enables developers to create custom deployment adapters for finer control over build and deploy targets.
Minor Deprecations and Changes: Deprecates Node.js 18 support, AMP, and changes to select next/image APIs with appropriate migration guidance.

Our goal is to make this update as smooth and straightforward as possible. We're managing these changes carefully to minimize disruption and will provide clear guidance and tools to support your transition to Next.js 16.

Preview Upcoming Features

You can start experimenting with many of these features today by using the canary channel and enabling the following flags in your next.config.js:

next.config.ts

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  experimental: {
    // Forward browser logs to the terminal for easier debugging
    browserDebugInfoInTerminal: true,
 
    // Enable new caching and pre-rendering behavior
    dynamicIO: true, // will be renamed to cacheComponents in Next.js 16
 
    // Activate new client-side router improvements
    clientSegmentCache: true,
 
    // Explore route composition and segment overrides via DevTools
    devtoolSegmentExplorer: true,
 
    // Enable support for `global-not-found`, which allows you to more easily define a global 404 page.
    globalNotFound: true,
 
    // Enable persistent caching for the turbopack dev server and build.
    turbopackPersistentCaching: true,
  },
};
 
export default nextConfig;

Notable Changes

[Improvement] Preserve RSC query during redirects (#77963)
[Improvement] Graceful error fallback for bots (#77916)
[Improvement] Disallow unstable_rootParams in client components (#79471)
[Improvement] Fix bodySizeLimit errors and non-multipart actions (#77746)
[Improvement] Respond with 404 for unknown action IDs (#77012)
[Improvement] Check cache-busting params on RSC requests (#80669)
[Improvement] Upgrade Vercel OG to 0.7.2 (#81447)
[Improvement] List assert/strict as external (#80884)
[Improvement] Omit searchParam data from FlightRouterState before transport (#80734)
[Improvement] Render streaming metadata on the top level (#80566)
[Fix] Clone the config module to avoid mutation (#80573)
[Fix] Bugfix: Propagate staleTime to seeded prefetch entry (#81263)
[Fix] Reinstate vary (#79939)
[Fix] Fix interestingness detection for React Compiler (#79558)
[Fix] Fix react compiler usefulness detector (#79480)
[Fix] Better handle edge-case file paths in launchEditor (#79526)
[Fix] Client router should discard stale prefetch entries for static pages (#79362)
[Feature] Add onInvalidate to router.prefetch (#77880)
[Feature] Add prefetch="auto" as an alias to prefetch={undefined} to Link (#78689)
[Feature] Support metadata in global-not-found (#78961)
[Feature] Restart dev server from error overlay (#80060)
[Feature] Restart dev server from indicator preferences (#80072)
[Feature] Add --debug-prerender option for next build (#80667)
[Feature] Add htmlrewriter to server externals (#80819)
[Feature] Allow partially prerendering intercepted dynamic routes (#80851)
[Performance] Check files with SWC before React Compiler (#75605)
[Performance] Improve static path generation performance and parameter handling (#81254)
[Misc] Fix NEXT_CPU_PROF usage during development to allow capturing CPU traces (#81248)

Share your feedback and help shape the future of Next.js:

Contributors

Next.js is the result of the combined work of over 3,000 individual developers. This release was brought to you by:

The Next.js team: Andrew, Ben, Hendrik, Janka, Jiachi, Jimmy, Jiwon, JJ, Josh, Jude, Rob, Sam, Sebastian, Sebbie, Wyatt, and Zack.
The Turbopack team: Benjamin, Donny, Josh, Luke, Maia, Niklas, Tim, Tobias, and Will.
The Next.js Docs team: Delba, Rich, Ismael, Joseph, and Lee.

Huge thanks to @sokra, @huozhi, @Marukome0743, @mischnic, @wbinnssmith, @eps1lon, @razzeee, @delbaoliveira, @kdy1, @wyattjoh, @acdlite, @ztanner, @bgw, @jantimon, @lubieowoce, @Fonger, @ospira, @gnoff, @styfle, @Cy-Tek, @timneutkens, @raunofreiberg, @devchaudhary24k, @Neschadin, @OreQr, @drewlong314, @ijjk, @praizjosh, @unstubbable, @lukesandberg, @ScriptedAlchemy, @sqidermad, @Juneezee, @devjiwonchoi, @Kamitenshi, @feedthejim, @leerob, @mauerbac, @miki-tebe, @gaearon, @mrbadri, @luwes, @lucacasonato, @M4xymm, @jirihofman, @vicb, @jackwilson323, @SyMind, @kevva, @xyf7, @gaojude, @dario-piotrowicz, @mastoj, @nicole0707, @lourd, @Karibash, @chipit24, @icyJoseph, @xusd320, @fireairforce, @GenhaoLi, @igas, @Macw07, @amannn, @bcdipesh, @r34son, @ivasilov, @lpalmes, @imskyleen, @teamleaderleo, @vitaliemiron, @agadzik, @chdeskur, @nakanoh, @luiscobot, @GameRoMan, @dferber90, @maurobonfietti, @navandstokes, @sajadtorkamani, @bobziroll, @lumirlumir, @KkOoSsTtAa, @msabramo, @sommeeeer, @schoenwaldnils, @remcohaszing, @HerringtonDarkholme, @bgub, @RobPruzan, @lmammino, @MohammedYehia, @extoci, @padmaia, @aacosta11, @vercel-release-bot, @maral, @ethanniser, @MichalMoravik, @rajrawat37, @kidonng, @dnhn, @kristian240, @rachnac-emeritus, @rortan134, and @nick20name17 for helping!