Aiming for "immediate," not just "fast"
Next.js 16.3, released on June 29, 2026, drew most attention for Turbopack's memory reduction and build cache (Next.js Blog). But the change that touches real user experience is the improvement to instant navigation: smarter prefetching and streaming make the screen feel like it reacts the moment you click a link.
The distinction between "fast" and "immediate" matters here. A full page load finishing in one second is not the same experience as something moving the instant you click. In human perception, a response within 100 milliseconds feels like direct manipulation; beyond that, people start to feel they are being made to wait. Instant navigation is designed around that perceptual boundary.
This post walks through the prefetching and streaming ideas behind it, and what you as a Next.js developer should keep in mind.
Prefetch: finish the prep before the click
In the Next.js App Router, a <Link> component tries to fetch the destination's data when it enters the viewport. The idea is to have everything the target page needs ready before the user has even clicked, so that when they do, the materials for rendering are already on hand.
import Link from "next/link";
// prefetch runs once the link enters the viewport
export function ArticleCard({ slug, title }: { slug: string; title: string }) {
return (
<Link href={`/blog/${slug}`} prefetch>
<article className="card">
<h2>{title}</h2>
</article>
</Link>
);
}The refinement in 16.3 is that this prefetching is "smarter." Rather than eagerly pulling everything uniformly, the decision about what to prioritize is more refined, cutting wasted requests while raising perceived speed.
Prefetch is not a silver bullet, though. On a list page with many links in the viewport, prefetching all of them can actually saturate bandwidth. When we review implementations, we always check whether every card in a list has prefetch enabled unconditionally.
Streaming: show the ready parts first
The other pillar is streaming. Instead of waiting for the whole page's data, it sends HTML out in the order pieces become ready, using React Server Components together with Suspense.
import { Suspense } from "react";
export default function BlogPage() {
return (
<main>
{/* The header that is ready immediately renders right away */}
<BlogHeader />
{/* The heavy list is wrapped in Suspense and streamed in when ready */}
<Suspense fallback={<PostListSkeleton />}>
<PostList />
</Suspense>
</main>
);
}With this structure, even if PostList takes time to fetch, the header and layout appear immediately. The user never stares at a blank white screen, and although the wait itself is unchanged, the perceived speed improves substantially.
It helps to think of instant navigation as combining prefetch (prep before the click) and streaming (render the ready parts) so that transitions feel uninterrupted and smooth.
Three things to watch for in practice
1. Design the granularity of Suspense boundaries
If the region wrapped in Suspense is too large, you lose the benefit of streaming. Split it too finely and skeletons flicker, which feels unsettled. The practical knack is to separate "what to show first" from "what can arrive later" and draw boundaries accordingly.
2. Narrow down what you prefetch
As noted, unconditional prefetch wastes bandwidth. Focus it on important paths — a transition into an article detail, for example — and be conservative with low-priority links.
3. Confirm perceived speed with measurement
The effect of instant navigation is felt subjectively, but do not stop at impressions — measure. Core Web Vitals' INP (Interaction to Next Paint) is especially useful for gauging how quickly the app responds to a click. Get in the habit of comparing the number before and after, and you can judge the impact objectively.
Our take
Improvements like instant navigation have a part that kicks in automatically just by bumping the framework version, and a part whose effect depends on your implementation. Prefetch and streaming are the latter. Design decisions — how you draw Suspense boundaries, which links you prefetch — heavily influence perceived speed.
When we support a client's Next.js project, we start by measuring INP to quantify the current transition experience, then revisit Suspense boundaries and the prefetch strategy. Improving on the basis of measurement, rather than "it feels faster now," is the reliable path.
Wrapping up
Next.js 16.3's instant navigation finishes the prep before the click with prefetch and renders ready parts first with streaming, making transitions feel immediate. The framework lays the foundation, but implementation choices — Suspense boundary granularity and prefetch targeting — decide the outcome.
After you upgrade, start by measuring INP. Grasping the current state in numbers is the first step toward improving perceived speed.
webhani consults on modern web development, including Next.js. If you want to talk about performance improvements, reach out anytime.