To start route work before a visitor clicks, trigger prefetching when they show intent—usually by hovering over or focusing a link—while keeping the link itself as a normal <a href>. If you use React Router, try its built-in <Link prefetch="intent"> first; a custom component is useful only when your router lacks the behavior you need.
What “prefetch before you click” means
Prefetching starts some work associated with a destination before navigation. With an intent trigger, a pointer hover or keyboard focus can signal likely interest; the click still performs navigation. Prefetching does not necessarily download every asset, fetch all destination data, or execute the destination page.
React itself provides a DOM <link> component for resources and metadata, but route-specific intent behavior comes from router libraries or application code, not automatic React route prefetching. See React’s <link> reference.
Choose a trigger that fits the link
| Strategy | When work starts | When it may fit |
|---|---|---|
| Intent | React Router: hover or focus. TanStack Router: hover or touch start; its documented default hover/focus delay is 50 ms. | When interaction is a useful signal that a visitor may navigate, without starting work for every visible link. |
| Viewport | When the link becomes visible; TanStack Router uses Intersection Observer. React Router describes this option as useful for mobile. | When visibility is a reasonable predictor of likely navigation, such as links in a list. |
| Render | As soon as the link renders. | When the destination is likely enough to justify eager work. |
| None or custom | React Router defaults to no prefetch; custom logic can start work on a chosen event. | When prefetching is unnecessary, or the router’s built-in choices do not meet a specific need. |
These triggers are not interchangeable. A link being rendered or visible is a weaker signal of likely navigation than a hover or focus, but it may start work earlier. Choose selectively: speculative requests use network and cache resources even when the visitor never follows the link.
#1 Best Overall
Use React Router’s built-in intent prefetch when it fits
React Router’s Link API defines prefetch="intent" for hover or focus. Its documented choices also include render, viewport, and none. The router inserts prefetch-related HTML <link rel="prefetch"> tags after the anchor. The API describes the Link as a progressively enhanced <a href> wrapper; the versioned v6.30.4 reference likewise documents an accessible anchor with a real href.
One practical consequence of inserted tags: structural CSS selectors can see a different last child. If a selector such as nav :last-child stops matching the link as expected, React Router recommends :last-of-type for this situation.
For a different trigger, React Router’s PrefetchPageLinks API can render prefetch and module-preload tags independently of a link—for example, while someone types into a search field. That can suit interfaces where the likely destination becomes clearer through input rather than link hover.
Check TanStack Router before adding a custom layer
TanStack Router documents a built-in preload="intent" approach, alongside viewport and render. Its current guide says hover/focus intent and viewport work start after a 50 ms default delay; touch intent is immediate. Pending intent work is cancelled when hover or focus ends, or when the link leaves the viewport. These are documented defaults for TanStack Router, not browser-wide guarantees. See the TanStack preloading guide.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
TanStack’s documented loader cache defaults are 30 seconds of freshness and five minutes of unused retention. These are configuration defaults, not speed measurements: freshness governs whether a retained result may be reused as fresh, while unused retention governs how long an unused entry remains before it becomes eligible for pruning during later cache reconciliation. Actual behavior depends on the router configuration and cache state.
If you build a custom intent link, preserve the anchor
A custom implementation should use an anchor with a real destination in href, then attach prefetch behavior to appropriate intent events. Keep the anchor as the interactive target rather than replacing it with a clickable non-link element. That preserves the native link model and its progressively enhanced behavior while letting application code start selected work early.
Before shipping custom logic, decide what work it starts, which links qualify, and how duplicate or abandoned requests are handled. A custom fetch/cache path may not reuse a prefetched response after navigation; reuse depends on the router and implementation. The router’s existing feature is generally the simpler choice when it already provides the desired trigger and caching behavior.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What a speedup can—and cannot—be assumed to mean
Prefetching may make some destination work available sooner, which can improve perceived responsiveness in suitable conditions. It does not guarantee instant navigation: route behavior, network conditions, cache state, browser behavior, and the resources needed by the destination all matter. The cited documentation establishes APIs and defaults, not a measured latency reduction for a custom component. Evaluate a real implementation in its own routes and conditions before making performance claims.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
