How does prefetching work for `<Link>` in the Next.js App Router — what triggers it, and how do you turn it off for a single link?

## Why prefetching exists A client-side navigation still needs data from the server: the RSC payload for the segments that change. That round trip is the whole latency budget of a link click. Prefetching moves that round trip to *before* the click, while the user is still reading, so the click itself resolves from memory. ## What triggers it For `<Link>` in the App Router, the primary trigger is **visibility**: when the anchor scrolls into the user's viewport, Next kicks off a background request for the destination. It is not hover-only — a link sitting on screen is prefetched even if the pointer never touches it. The requests are low priority and are skipped on very slow or data-saver connections. Two things routinely confuse people here: - **Prefetching is disabled in development.** Running `next dev` and watching the network tab produces no prefetch requests. Test this against `next build && next start`. - **Prefetched payloads live in the client Router Cache**, an in-memory, per-session structure. A hard reload empties it. It is not the HTTP cache and not a service worker. You can also prefetch imperatively: ```tsx 'use client'; import { useRouter } from 'next/navigation'; export function Row({ href }: { href: string }) { const router = useRouter(); return <tr onMouseEnter={() => router.prefetch(href)}>{/* … */}</tr>; } ``` That is the escape hatch for destinations that are not behind a `<Link>` at all — a row that navigates on click, a wizard's next step chosen programmatically. ## Controlling it per link The `prefetch` prop takes three values: - **`prefetch={false}`** — do not prefetch this link. Use it for links that are numerous and rarely clicked, or whose destination is expensive to render on the server. - **`prefetch={true}`** — prefetch the full route eagerly, rather than whatever the default partial strategy is. - **default (unset)** — Next's automatic strategy, which differs for statically and dynamically rendered destinations. ```tsx <Link href={`/reports/${id}`} prefetch={false}> {name} </Link> ``` ## The version-sensitive part This is where stale interview answers show up. Two specifics have moved across Next majors and are worth stating as "depends on the version" rather than as a fact: 1. **How much of the destination is prefetched by default.** The general shape is that a fully static destination can be prefetched completely, while a dynamic one is prefetched only down to the nearest loading boundary, so the shell appears instantly and the dynamic part streams after the click. 2. **How long a prefetched entry stays reusable.** Next 15 set the client Router Cache stale time for dynamic pages to `0` by default, meaning a prefetched dynamic entry is used for the instant shell but the data is refetched on navigation. That is tunable through the `experimental.staleTimes` option in `next.config`. Assume Next 15/16 App Router for the numbers above. In an interview, the strong answer names the *mechanism* — a client-side cache of RSC payloads, keyed by route, populated ahead of the click — and flags the defaults as version-dependent, rather than asserting a number that changed two releases ago. ## When to switch it off Prefetching costs server work and bandwidth on requests the user may never make. Turn it off when: - a page renders **hundreds of links** into the viewport, such as a long table or an infinite feed — the aggregate prefetch traffic can rival the page itself; - the destination is **expensive to render** on the server, e.g. a heavy report that hits several upstream services; - the destination has **side effects on GET**, which is a design smell in its own right but does happen with legacy endpoints. In those cases `prefetch={false}` plus an imperative `router.prefetch()` on hover or focus gives you speed on the links people actually aim at, without the broadcast cost. ## Common misconceptions Prefetching does not download the destination's HTML page, and it does not run its client-side effects. It does not warm any server cache you control. And it is not a substitute for making a slow route fast — a route that takes two seconds to render on the server still takes two seconds if the user clicks before the prefetch settles.