Next.js 16.3: Instant Navigations Brings SPA Speed to Server Apps

If you have ever watched a user click a link in your Next.js App Router app and stare at a blank screen, the Next.js team heard you. Next.js 16.3 Preview, published June 25, ships Instant Navigations — a set of opt-in controls that make server-driven routing feel as responsive as a single-page application. You keep the server. You drop the blank screen.

The Problem, Plainly Stated

Server-driven navigation has a known feel to it. You click a link, nothing happens, then the next page arrives. For content sites like blogs, this is acceptable — users expect a page load. For apps — dashboards, tools, any interface where users are working — this feels unresponsive. It has been a consistent criticism of the App Router since launch, and it pushed some teams toward Remix or back toward full SPAs.

Next.js 16.3 borrows the trick SPAs have always used: show something instantly on click, then fill in the data. The difference is that here, the “something” comes from the server’s prefetched route shell, not a bundled client-side template.

Stream, Cache, or Block

Instant Navigations is not a global toggle. You choose behavior per route, and the distinction matters:

• Stream: Wrap slow sections in <Suspense>. The user sees a loading shell the instant they click, and the real content streams in once the server responds.
• Cache: Use the 'use cache' directive on data-fetching functions. The user sees a previously cached version of the UI — stale-while-revalidate, but instant.
• Block: Add export const instant = false to a page. The route waits for the full server response before transitioning. This is the old behavior, and it is the right choice for content pages where a loading skeleton would feel absurd.

The Block option is what makes this design honest. Vercel could have forced every route to show a shell and called it a win. Instead they made it explicit, which means you can make an informed decision per route rather than accepting a global UX compromise.

Partial Prefetching Fixes the Network Tab Problem

In Next.js 16.2, the framework sent one prefetch request per visible link on scroll. On a page with a sidebar listing twenty conversations, that meant twenty network requests firing as the sidebar rendered. Developers noticed. The Next.js team agrees it looked ridiculous.

In 16.3, with Partial Prefetching enabled, Next.js prefetches one reusable shell per distinct route. Twenty links pointing to /chat/[id] trigger a single prefetch. That shell is cached on the client for the duration of the session. This is the same pattern SPAs use with per-route code splitting, applied to server prefetching. The shell also lays groundwork for offline navigation — a future release will explore keeping prefetched routes navigable when the network briefly drops.

How to Try It Today

Both features are gated behind config flags. Install the preview and update your config:

npm install next@preview

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

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

export default nextConfig;

Both flags are planned to become defaults in a future major release. Enabling them now means adopting what will eventually be the standard behavior. To opt a specific route out of instant navigations — a blog post, a static content page — export a single constant:

// page.tsx
export const instant = false;

For routes where you want to prefetch more than the shell, add <Link prefetch={true}>. By default, this is limited to build-time known content. Exporting const prefetch = 'allow-runtime' extends it to request-time cached data at the cost of additional server load.

The Tooling Makes This Usable

Performance features without visibility are worthless — you fix them once and break them a month later in a refactor. Next.js 16.3 ships three tools to prevent that:

• Instant Insights panel: In development, slow navigations surface as errors, not just slowness. You cannot ignore them and ship.
• Navigation Inspector: Added to Next.js DevTools. Pause any navigation at the shell stage to see exactly what gets prefetched versus what waits for the server.
• Playwright helper: The instant() function from @next/playwright lets you write tests that assert what must be visible before the network responds. Instant route regressions become failing tests.

This is the part other frameworks rarely invest in. Solving the navigation problem without solving observability just means the fix erodes silently over time.

Caveats Worth Knowing

This is a Preview release — stable is expected in the coming weeks. Two known issues to watch before deploying:

• Instant Insights has display bugs in Safari during development. Use Chrome or Firefox.
• Accessing params inside a shell can cause a route to block without triggering an Instant Insights error, so the tooling will not catch it automatically.

The Bottom Line

Instant Navigations is the proper architectural answer to the most legitimate criticism of the Next.js App Router. It is not a workaround — it is per-route shells, smarter prefetching, and observability tooling to keep the fix intact over time. The catch is that it is still experimental, and real applications will find edge cases the preview docs have not covered yet.

If you are running a Next.js app where navigation feel is actively hurting user experience, this is worth testing in staging now. If you are happy with current behavior, wait for the stable release. Either way, read the official announcement — the framing of what Instant Navigations unlocks for server-centric apps is worth understanding before stable lands. The full cacheComponents API reference and the preview docs for Instant Navigations have the complete implementation details.