Fetching future navigations before the user clicks

Research consistently ties faster load times to better conversion rates and user experience. When you can predict where a user will go next, you can shorten that future navigation by downloading its required resources in advance with the <link rel=prefetch> resource hint.

prefetch is not a mandate; the browser decides whether and when to execute the hint. Prefetched resources are requested at the lowest priority and are cached in the HTTP cache when cacheable, so they don't compete with current-page resources for bandwidth. The browser queues multiple hints and fetches each during idle time, and in Chrome, an in-flight prefetch is adopted as the navigation if the user happens to arrive at the destination before it finishes loading.

Because prefetching downloads bytes for resources that aren't immediately needed, it should be used deliberately. Only prefetch when you're confident the resources will be used. On slow connections, consider skipping prefetch entirely — the Network Information API can help you detect this condition.

Common prefetching targets

Prefetching works best when the next navigation is predictable. When you can anticipate the user's path, there are several assets worth fetching ahead of time, each with different payoffs.

HTML documents for predictable next pages

Prefetching an HTML document is appropriate when the next page is highly predictable. For a product listing page, that could mean prefetching the page of the most popular product. On a shopping cart page, the checkout page is a natural candidate.

This approach directly improves Time to First Byte (TTFB) because the document request is served from the cache. Lower TTFB in turn tends to lower downstream, time-based metrics including First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

Static assets shared across pages

When predictable future sections share static assets such as scripts or stylesheets, prefetching those files while the user is on the current page can be particularly effective. Netflix, for example, prefetches React during the time users spend on logged-out pages, which reportedly cut Time to Interactive for subsequent navigations by 30%.

The measurable effect on performance varies by resource type:

  • Images: prefetching an LCP image can significantly lower that element's LCP time.
  • Stylesheets: because they are render-blocking, prefetching a stylesheet can improve both FCP and LCP by eliminating its network fetch from the critical path. Note that a subsequent page's CSS background image, requested via the background-image property, is also picked up as a dependent resource of the prefetched stylesheet.
  • JavaScript: scripts that arrive in the prefetch cache can be processed much sooner during navigation. This can benefit Interaction to Next Paint (INP), and for client-side rendered pages containing the LCP element in markup, LCP can improve as well.
  • Web fonts: prefetching a font not yet used by the current page — when font-display: swap; is in play — eliminates the swap period, preventing layout shifts. If that font renders the text in an LCP element on the future page, LCP for that element improves too.

On-demand JavaScript chunks

Code-splitting your JavaScript lets you serve only a portion of the app initially and lazy-load the rest. Prefetching fits naturally here for the routes or components that aren't loaded right away but are likely to be requested soon.

Consider a page with a button that opens a dialog containing an emoji picker. This could be split into three chunks: home, dialog, and picker. The first two load at startup, while the picker loads on demand. Tools such as webpack can inject prefetch hints for these later chunks directly into the HTML.

The gains from prefetching on-demand chunks are nuanced, but generally, interactions that depend on those chunks respond faster when the chunk is already in the cache. The biggest wins come when users have a slow Internet connection and you prefetch the chunk over a network that has extra bandwidth.

Implementing prefetch

The most straightforward method is adding a <link> tag to the document head:

<link rel="prefetch" href="/future-page.html">

Alternatively, you can use the Link HTTP header:

Link: </css/style.css>; rel=prefetch

The header approach has a small advantage: the browser does not have to parse the document to discover the hint.

Prefetching chunks with webpack magic comments

For code-split JavaScript, webpack supports prefetching via magic comments inside dynamic import() calls. A lazy load of a sorting function from lodash, triggered when a form is submitted, can be prefetched ahead of time so the function is ready in the cache before the user even reaches the submit button.

Adding /* webpackPrefetch: true */ to the import tells webpack to inject a <link rel="prefetch"> tag for the chunk into the HTML document.

The impact of prefetch trickles into overall resource prioritization. Since prefetched items fetch at the lowest priority, it frees up your HTML and CSS in the prioritization schedule. You can always rely on your browser to make its own choices on how to optimally prioritize download order for resources.

Prefetching JavaScript can affect how a page's LCP element loads. In the straightforward case, downloading a script early doesn't change resource load delays, and if the document's critical resources are first, the script prefetch isn't necessarily granted all that early.

Prefetching itself will eliminate the script load delay in the case where a third-party origin is required to load the script. However, if a site's LCP element lives in a client-rendered markup skeleton and a significant chunk of JS executes there, it doesn't necessarily mean that preloading is the right fix — rather, that it would be optimal to revise markup for the LCP element. You can use the fetchpriority="high" hint on an LCP element as a precision instrument.