Preloading Data: Prefetching Routes and API Calls

The plain-language idea

The resource-hints lesson covered <link rel="prefetch"> for a likely next navigation's static resources — code, mostly. This lesson extends the same underlying principle one layer further: prefetching data, not just assets. The idea doesn't change — fetch something before it's needed, so it's already available when it is — but applying it to a data fetch (an API call, a route's server data) rather than a static file is a distinct, common pattern in its own right.

Two real, widely-used triggers for when to prefetch data:

• Hover/focus intent — when a user hovers (or keyboard-focuses) a link, that's a real signal they're likely about to click it. A common modern-framework pattern kicks off both the next route's code and its data fetch during that hover delay — typically a couple hundred milliseconds before an actual click lands. If the fetch finishes before the click happens, the navigation feels instant, because the work that would normally happen after the click already happened during the hover.
• Viewport visibility — a link scrolling into view is a weaker but still real signal of likely intent (the user is reading toward it, or it's plausible they'll click it soon). Some frameworks trigger a low-priority prefetch automatically the moment a link becomes visible on screen, on the theory that a visible link is more likely to be clicked than one nowhere near the viewport.

See it in a real thing: the hover-to-click gap

User hovers a link  ->  [prefetch starts: code + data]  ->  ~200ms hover delay  ->  user clicks
                          |
                          v
                     By click time, fetch may already be done — navigation renders from
                     already-resolved data instead of waiting on a fresh request.

Without prefetching, a click triggers the entire chain — route code loads, then the data fetch starts, then the page can render — all after the click, which is exactly when the user is watching and waiting. With hover-triggered prefetching, most or all of that chain already ran during the hover delay that happens naturally before most clicks anyway. The click just reveals work that's already done.

What people usually miss

Watch out

• Prefetching data is the same idea as resource hints, applied one layer up — from "fetch this file before it's needed" to "fetch this data before it's needed." Recognizing that connection is worth more in an interview than treating them as unrelated techniques.
• Hover-triggered prefetch only helps if the fetch has time to finish before the click. A hover delay of a couple hundred milliseconds isn't enough time to rescue a genuinely slow endpoint — prefetching hides latency that fits in the hover gap, it doesn't make a slow API fast.
• "Prefetch everything visible" is a real anti-pattern, not just a theoretical risk. A long list or feed with dozens of links visible at once can trigger dozens of speculative fetches if visibility-based prefetching isn't scoped or throttled — this is exactly the over-aggressive case worth naming explicitly.
• Prefetching should be a deliberate choice about which navigations are actually likely, not a blanket setting — the right targets are the small number of links a user is disproportionately likely to click next (a "next" button, a primary nav item), not every link that happens to be on the page.

Why this matters in interviews

"A click into a detail page feels slow because of the API round trip after navigation — how would you make it feel instant without changing the backend?" is a real question, and naming hover-triggered data prefetching (plus the honest bandwidth tradeoff of doing it too aggressively) shows you can apply the resource-hints principle to data, not just static assets.