Prefetching Explained: The Optimization That Makes Pages Feel Instant

What is Prefetching, Really?

Prefetching is the practice of fetching resources before the user explicitly asks for them — pages, scripts, images, fonts, data — based on a prediction that they are about to be needed. The bet is simple: if you can move the network round-trip off the click and into the moment of hover or scroll, the click feels instant because there is nothing left to download when it happens.

The reason this matters more in 2026 than it did five years ago is mobile traffic. Even on fast LTE, a typical page fetch involves DNS lookup (50ms), TLS handshake (100ms), HTTP round-trip (100ms), and the actual payload download. Add them up and you have routinely lost half a second before pixels start appearing. Prefetching collapses most of that latency into time the user is not waiting — usually while they are reading the current page or hovering over a link.

How Prefetching Actually Works Under the Hood

Three signals tell a browser or framework that a resource is likely to be needed soon. Each unlocks a different prefetch strategy:

• Static — links visible in the viewport or marked with rel="prefetch" are candidates for low-priority background fetching
• Behavioral — hover-to-prefetch waits until the user moves the mouse over a link, predicting a click is imminent (or the touch equivalent on mobile: tap-start)
• Predictive — frameworks and analytics-driven systems use navigation history to predict the next likely page, even without an explicit link

Behind the scenes, prefetched resources are downloaded at a lower priority than what the current page actually needs to render. The browser will not block your hero image to prefetch a link's HTML — the prefetch waits until the network is idle. That priority distinction is what makes prefetching mostly safe to use liberally on desktop, even though it has real costs on mobile (covered later).

The Four Browser-Level Prefetch Techniques

Before any framework gets involved, the browser itself supports four distinct link-relation hints. Each does a different thing, and confusing them is how teams accidentally fetch everything twice.

Next.js Automatic Prefetching — The Default Almost Nobody Tunes

Out of the box, Next.js prefetches every <Link> component as soon as it enters the viewport. This is why your Next.js app feels so instant on navigation — by the time you click the link, the next page's RSC payload is already in memory. No configuration required.

import Link from 'next/link';

export default function Nav() {
  // Prefetched automatically when the link scrolls into view.
  return <Link href="/pricing">See pricing</Link>;
}

The mechanism is intersection observer + RSC payload fetching. The Next.js runtime watches for Link components entering the viewport, fetches the destination's serialized React tree in the background, and stores it in the Router Cache. When you click, Next.js skips the network entirely and just hydrates the cached payload.

Controlling Next.js Prefetch Behavior

The default is right for most apps, but four scenarios call for tuning the behavior:

// Disable prefetch for low-value links (footer legal pages, etc).
<Link href="/privacy" prefetch={false}>Privacy</Link>

// Force prefetch on hover only (saves bandwidth on data-light sites).
<Link href="/heavy-dashboard" prefetch={false}>Dashboard</Link>

// Aggressive: prefetch on mount even before viewport intersection.
// Useful for the one most-likely-next link on a landing page.
<Link href="/signup" prefetch={true}>Get started</Link>

Recommended pattern: keep the default prefetch on for primary nav and CTA links, set prefetch={false} on legal footer links and any link to a heavy dashboard route, and rely on Next.js to handle everything else. Manual prefetching everywhere is more code than it is worth.

Smart Prefetching Strategies

There is a wide gap between 'prefetch nothing' and 'prefetch everything'. Five strategies that hit the sweet spot:

• Prefetch the most-likely-next page only — analytics will tell you what 70% of users click first; prefetch only that, not every link in the nav
• Prefetch on hover/touch-start rather than on render — by the time a user hovers, they have ~100ms before they click; that is plenty for a prefetch to complete and zero bandwidth wasted on users who never hover
• Skip prefetch on slow connections — check navigator.connection.effectiveType (or the Network Information API) and disable prefetch for users on 2g or slow-2g
• Skip prefetch when the user has Save-Data enabled — respect the navigator.connection.saveData flag; it is the user explicitly telling you 'do not waste my bandwidth'
• Defer prefetch until the page has finished its critical work — fire prefetches after window.load, not during the initial paint, so they never compete with first-paint resources

The Hidden Costs of Aggressive Prefetching

Prefetching has a real cost — three of them, actually — and ignoring them is how 'optimization' turns into a degraded mobile experience:

Measuring Whether Prefetching Is Helping

Optimization without measurement is just hope. Three metrics tell you whether your prefetch strategy is paying off:

• Time to interactive on the destination page — should drop dramatically when the navigation was prefetched (sub-100ms vs 500-2000ms for cold)
• Prefetch hit ratio — of all the links you prefetched, what percentage did users actually click? Below 30% suggests you are prefetching too aggressively
• Bandwidth-per-session — track total bytes downloaded per user session before and after enabling prefetch; if it doubles but engagement does not increase, you are over-prefetching

Most teams skip step 2 and just enable prefetch everywhere. The result is a feel-good optimization that quietly wastes 30-40% of mobile users' data without proportional engagement gains. Worth the half-hour of analytics work to confirm.

Common Pitfalls

Mistakes that show up repeatedly when teams roll out prefetch for the first time:

• Confusing preload with prefetch — preload is high-priority for the current page; prefetch is low-priority for the next page. Mixing them up either blocks current-page rendering or wastes the optimization entirely.
• Prefetching dynamic, personalized pages — prefetching /dashboard for a logged-out user wastes the bytes; the response is just a redirect to /login. Gate prefetch on auth state.
• Not setting CORS headers on prefetched cross-origin resources — without crossorigin on the link tag and the right CORS response headers, the prefetch result is unusable and must be fetched again. Easy to miss in network panels.
• Prefetching everything in a hero carousel — five prefetches for slides the user will probably never scroll to. Lazy-load images instead; prefetch is for navigation, not media.
• Forgetting that prefetched RSC payloads age — Next.js Router Cache holds prefetched routes for 30 seconds (dynamic) or 5 minutes (static). After that, the user is back to a fresh fetch. Test navigations after long idle periods.

When to Skip Prefetching Entirely

Prefetching is the right default for most public-facing apps. It is the wrong default in three scenarios: data-heavy admin panels where every route weighs 500KB+ and users only visit one per session; sites with a heavy mobile audience on slow networks where bandwidth conservation matters more than perceived speed; and apps with strict bandwidth budgets like progressive web apps targeting low-end devices in emerging markets.

In those cases, set Next.js's <Link prefetch={false}> by default, disable browser-level rel="prefetch", and trade the instant-navigation feel for predictable bandwidth usage. It is a real trade-off, not a one-size-fits-all win.

Final Thoughts

Prefetching is the rare optimization where users feel the difference immediately — a click that used to take 800ms now takes 50ms, and the app starts to feel like a native experience. The four browser primitives (dns-prefetch, preconnect, preload, prefetch) each cover a different layer of the latency chain, and Next.js's automatic prefetching collapses most of the work into a single Link component. The discipline is in the smart part: prefetch what users will actually click, respect Save-Data and slow-connection signals, measure the hit ratio, and trim back wherever bandwidth waste outpaces the engagement gain. Get those right and prefetching becomes the small change with the biggest perceived-speed impact in your entire performance budget.

Frequently Asked Questions