Prefetching and Route-Level Data Loading

The plain-language idea

The default pattern most components use is simple: mount, then fire a fetch in a useEffect. That default has a hidden cost — it creates a strict sequence. Navigation happens, then the destination route's code loads, then the component mounts, and only then does the fetch actually start. The user sees a loading spinner appear right after all of that has already happened, instead of data that's already in flight, or already arrived, by the time it's needed.

Two concrete techniques start the fetch earlier than that:

• Route-level data loading. Many modern routing setups let a route declare its own data dependency as part of the route itself, so the moment navigation to that route is triggered, the router starts the data fetch in parallel with loading the route's code — not sequentially after the destination component has already mounted.
• Hover- or focus-triggered prefetching. A link can start fetching the data for the page it points to the instant a user hovers or focuses it, well before they actually click. By the time the click happens, that data may already be sitting there, or well underway.

See it in a real thing: prefetching a link's data on hover

function PrefetchLink({
  href,
  cacheKey,
  children,
}: {
  href: string;
  cacheKey: string;
  children: React.ReactNode;
}) {
  const prefetch = () => {
    // Warms a shared cache so the destination route's data may already be
    // resolved, or well underway, by the time the user actually clicks.
    queryCache.prefetch(cacheKey, () => fetch(`/api${href}`).then((res) => res.json()));
  };

  return (
    <a href={href} onMouseEnter={prefetch} onFocus={prefetch}>
      {children}
    </a>
  );
}

onFocus matters here as much as onMouseEnter — a keyboard user tabbing to a link never triggers a hover event at all, so a prefetch that only listens for the mouse leaves keyboard navigation with no head start.

Route-level loading follows the same underlying idea from a different angle: instead of waiting for a hover, the fetch is declared as part of the route definition itself, so it kicks off the instant navigation is triggered — in parallel with the route's own code loading, rather than after the destination component has already mounted and run its own effect.

What people usually miss

Watch out

• Prefetching on every hover, for every link, isn't free. It's a real bandwidth cost paid on navigations that never happen — a user hovering past a link on their way to another one still triggers the fetch. Choosing which routes are worth prefetching is part of doing this well, not an afterthought.
• A primary navigation path and a rarely-visited settings page don't deserve the same treatment. Prefetching a main nav link a user is likely to click next is a reasonable default; prefetching every link on a page indiscriminately, including ones almost nobody clicks, is where the cost stops paying for itself.
• Route-level loading and hover prefetching solve the same problem from different triggers. One starts the fetch at navigation time, the other starts it even earlier, speculatively, before navigation is even certain to happen — they're not competing techniques, they're two different points to start the same kind of head start.
• "Faster fetch" and "earlier fetch" are different fixes for the same symptom. Optimizing how fast a fetch resolves doesn't help if the fetch itself still doesn't start until after navigation, code loading, and mounting are already finished — the actual fix here is moving when the fetch starts, not how quickly it completes.

Why this matters in interviews

"The app feels slow right after clicking a nav link" is a common performance question, and correctly diagnosing it as a sequencing problem, fetch starting too late, rather than a raw speed problem is what separates someone who's actually reasoned about the request waterfall from someone reaching straight for caching or a faster endpoint.