Next.js 16.3 Instant Navigations

There is one complaint about the App Router that has followed it since the day it shipped, and every single person who has built a real app with Server Components has said some version of it out loud.

"It renders fast, but clicking around feels slow."

I have said it. I said it while migrating this site. I said it again three months ago while building something with a heavy dashboard, watching a link click sit there doing absolutely nothing for 400ms before the page swapped. The pages themselves were fast. The navigations were not. And the fix everyone reached for, sprinkling loading.tsx files across every route segment until the dead air went away, was a chore you could forget about in exactly one place and then never notice until a user complained.

Next.js 16.3 is the release where the team stopped patching around that and rebuilt the model underneath it. The headline feature is called Instant Navigations, and it is the biggest change to the framework since 16.0 landed last November.

I have been running it for a few weeks now. Here is what it actually does, what it costs to adopt, and the parts I would turn on today versus the parts I would wait on.

The Free Wins: Upgrade Even If You Ignore Everything Else

Before the opt-in stuff, there is a pile of improvements in 16.3 that require zero code changes. If you read nothing else in this post, read this section, run npm install next@latest, and go back to whatever you were doing.

Dev server memory dropped by up to 90%. Turbopack now ships disk caching for dev plus memory eviction, both on by default. Vercel's own dashboard went from 21.5 GB to 2 GB of RAM after compiling 50 routes. nextjs.org went from 4,600 MB to 840 MB. If you have ever had next dev slowly eat your laptop over a six-hour session until the fans sound like a departing aircraft, this is the fix. On my machine the difference is the gap between "I can keep Docker and a browser open" and "I cannot."

Builds got faster because the disk cache now applies to next build. Vercel is reporting up to 5.5x faster repeat builds on CI. Their own numbers span a range: nextjs.org went from 21s cold to 9.2s cached, vercel.com/home from 66s to 46s, vercel.com/geist from 30s to 5.5s. That spread is worth noting. The gain depends heavily on how much of your build is actually compilation versus data fetching, so do not budget for 5.5x and be disappointed when you get 1.4x.

Server-side rendering handles about 22% more requests under load. They replaced web streams with native Node.js streams in the App Router rendering layer, cutting the conversion overhead between the two. No API change, no config, just more headroom on the same box.

Type checking can now use TypeScript 7. If you bump your local dependency to typescript@^7, next build will use the native Go port for type checking. I wrote about TypeScript 7 and Project Corsa when it was still landing, and the short version is that a 10x faster type checker changes what you are willing to run in CI. This is the release where that becomes a one-line change in a Next.js app.

Coding agents now read version-matched docs automatically. Running next dev writes and maintains an AGENTS.md block pointing at the docs bundled in your local node_modules. Vercel is retiring the earlier Skills that existed purely to feed current documentation to agents, because the docs now reach the agent directly. If you have ever watched Claude Code confidently write a Next.js 13 pattern into a Next.js 16 app, you know exactly why this matters.

That is a genuinely good release before you opt into anything.

What Instant Navigations Actually Is

Now the interesting part.

The mental model to hold onto is this: Next.js can only show you something the instant you click a link if it already has that something on the client. Everything in Instant Navigations is machinery for extracting a reusable "shell" of each route, prefetching it once, and rendering it immediately on click while the real data streams in behind it.

Before 16.3 you had two blunt tools for that. You could define a loading.tsx for a route segment, which gave you one shell per segment and nothing more granular. Or you could set <Link prefetch={true}> and pull down the entire target page, which worked and also hammered your server with prefetch traffic for pages nobody visited.

16.3 replaces both with something finer. Components that render dynamic UI can either define inline loading states with <Suspense>, or mark part of their UI as prerenderable with 'use cache'. Next.js extracts that UI into a shell, prefetches the shell once, and reuses it. The rule the docs give you is close to a slogan:

• Stream with <Suspense>, or
• Cache with 'use cache', and your navigation is instant
• Block with export const instant = false if you deliberately want to opt a route out

That third one matters more than it looks. It is an escape hatch that turns "this route is slow" from an invisible accident into a deliberate, greppable decision in your codebase.

You turn the whole thing on with two flags:

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

export default nextConfig;

Vercel has said the behaviors behind Instant Navigations will become the default in a future major version. So this is not a side experiment you can ignore forever. It is a preview of where the framework is going, offered a version early so you can migrate on your own schedule instead of during an upgrade weekend.

Partial Prefetching Is the Piece That Changes Your Bill

Of the whole suite, Partial Prefetching is the one I would call out to anyone running a site with real traffic and a real invoice.

The old model forced a binary. Either you got the coarse loading.tsx shell, or you flipped prefetch={true} and pulled the whole page down for every link in the viewport. On a page with thirty links, the second option is thirty full page payloads fetched on behalf of a user who is going to click one of them, if that.

Partial Prefetching lets Next.js extract a reusable loading shell from any route's UI, and lets per-link prefetching include as much or as little of the target page as you want. Separately, 16.3 bundles prefetches below a certain payload size into fewer requests, while keeping larger shared segments as separate fetches so they can be reused across routes.

That combination is the difference between prefetching being a nice performance trick and prefetching being something you can afford to leave on. If you are on a usage-priced host, prefetch traffic is not free, and "aggressive prefetching" has been a quiet line item on plenty of bills. I have written before about how edge functions get sold as a default when they should not be, and this is the same category of problem: a feature that is great when it is targeted and expensive when it is blanket-applied.

Instant Insights: The Devtool That Tells You What You Broke

The failure mode with all of this is not the initial setup. It is the slow drift afterward.

Someone adds a component that reads cookies() into a shared header, and the route de-opts to request-time rendering. Someone moves a <Suspense> boundary during a refactor and half the page starts blocking. The navigation that was instant in March is not instant in July, and nobody noticed because nobody was measuring it.

16.3 ships three things aimed squarely at that.

Instant Insights is a DevTools panel that automatically surfaces navigations that are not instant as you click around your own app. You do not go looking for it. It goes looking for you. Each insight also hands you a prompt you can feed to your coding agent to apply the fix, which is a small detail I find quietly telling about where Vercel thinks the workflow is heading.

The Navigation Inspector solves a specific annoyance: prefetching is disabled in development, so you genuinely cannot see what your users see during a navigation's loading sequence. The inspector lets you pause a page load or client-side navigation at the shell and look at exactly what the loading state renders.

The instant() Playwright helper is the one that keeps it fixed. It lets you assert exactly what content should be visible during a navigation, without waiting on the network:

// 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');

  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();
});

That test fails whenever the instant UI changes, whatever the cause. That is the whole point. Performance regressions are boring to catch by hand and trivial to catch in CI, so put them in CI.

The Smaller Additions Worth Knowing About

A few things in 16.3 are not headline features but will show up in your code within a month of upgrading.

Custom error boundaries with catchError. React error boundaries in Next.js used to interfere with notFound() and redirect(), and they could only reset client state. They gave you no way to retry a Server Component that failed during rendering. Now:

// 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 retry() function refetches the boundary's children, including rerendering Server Components. If you have ever shipped a "something went wrong, please refresh the page" screen because there was no way to retry the server render, this deletes that screen.

Glob imports in Turbopack. import.meta.glob is now supported, Vite-compatible, with HMR:

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

For a content-driven site this is genuinely nice. This blog reads MDX off disk with fs.readdirSync and a module-level cache, which works fine but does not hot-reload when I add a file. Glob imports fix that class of thing.

Root params. Params defined above the root layout, the classic [lang] case, are effectively global, and until now the only way to read them deep in the tree was prop drilling. Now:

import { lang } from 'next/root-params';

They work inside use cache scopes too. Currently Server Components only, with route handlers and Server Actions planned.

Better ISR for partially prerendered routes. If you use generateStaticParams to prerender only some pages, the rest used to face a bad trade: show a loading shell but never get prerendered, or skip the shell and block the first visitor. Now the first visitor gets an instant shell, the page upgrades to fully prerendered in the background, and everyone after that gets the cached final content.

Experimental: The Rust React Compiler

Two experimental flags ship with 16.3, and one of them is worth watching closely.

The React Compiler has been available for a while, but enabling it meant running it through Babel in Node. The experimental Rust port runs directly inside Turbopack, skipping the generate-and-reparse round trip:

const nextConfig: NextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

On v0, Vercel measured a 34% cut in time from next dev to a ready page on a cold build, and 46% on a warm one. Important asterisk: those numbers assume you have dropped Babel entirely. If you still run Babel for other transforms, you get a smaller win.

I wrote about the React Compiler when it first landed and my position has not really changed. The compiler is the right long-term answer to manual memoization, and the friction was always the build-time cost. Moving it into Turbopack removes most of that friction.

The other experimental flag is useOffline, which keeps soft navigations, data fetches, and Server Actions pending when the network drops and retries on reconnect, plus a useOffline() hook so you can render a banner. Because Partial Prefetching already caches route shells on the client, a prefetched route still renders its shell offline and streams data in when you reconnect. That is a nice composition of two features that were designed separately.

Should You Turn the Flags On?

Here is how I would actually sequence this, in order of how much I would trust each step.

Upgrade to 16.3 today. The dev memory, build cache, SSR throughput, and prefetch bundling improvements are all default-on and require no code changes. There is no argument for sitting on 16.2 while your dev server eats 20 GB of RAM.

Turn on partialPrefetching next if you have a link-heavy app. It is the lowest-risk of the two flags and it directly reduces prefetch traffic. If you have been running prefetch={true} broadly because navigations felt bad, this is the thing that lets you keep the feel and drop the cost.

Adopt cacheComponents deliberately, not casually. This is the one that changes how you think about your data layer. Vercel ships a migration guide and explicitly frames it as something you or your agent can work through, which is an honest signal that it is not a flag flip. If your app is mostly static marketing pages, the migration is small. If it is a dashboard where half the tree reads cookies and headers, budget real time for it.

Skip the Rust React Compiler on anything that pays you money. It is experimental, the win is a dev-loop speedup rather than a runtime one, and experimental compiler flags are exactly the wrong place to be adventurous on a production app. Try it on a side project, report what breaks, wait for stable.

The thing I keep coming back to is the framing Vercel used: simplify Next.js back to its roots, dynamic by default, with no hidden or implicit caching. That is a direct response to the years of complaints about the App Router's caching model being something you had to reverse-engineer rather than read. 'use cache' being explicit and composable, and now covering the client too, is the correction. Whether it lands depends on whether the migration path is genuinely walkable for apps that already exist, and that is the part I will only know for sure after doing it on something bigger than a blog.

Frequently Asked

Do I need to enable anything to benefit from Next.js 16.3? No. The memory, build, rendering, and prefetch-bundling improvements are default-on. Instant Navigations is the opt-in part, behind cacheComponents and partialPrefetching.

What is the difference between Instant Navigations and Partial Prefetching? Instant Navigations is the umbrella name for the whole suite. Partial Prefetching is the specific mechanism that lets Next.js extract a reusable loading shell from any route and control how much a link prefetches.

Will Cache Components become the default? Vercel has said the behaviors behind Instant Navigations will become the default in a future major version. Adopting now is early migration, not a permanent side path.

Is loading.tsx deprecated? Not deprecated, but it is no longer the only way to define a loading shell. Inline <Suspense> boundaries and 'use cache' give you finer-grained control than one shell per route segment.

Does this change my hosting bill? Probably down, if you were running broad prefetch={true}. Partial Prefetching plus prefetch bundling means fewer and smaller prefetch requests for the same perceived speed.

If you are upgrading this week, start with the flags off, look at Instant Insights while clicking through your own app, and let it tell you which routes are actually slow before you migrate anything. That list is usually shorter and weirder than you expect.