Prefetching is a browser performance technique that speculatively loads resources, web pages, assets, or data, before the user explicitly requests them, anticipating that the resources will be needed in the near future and loading them during idle time so they are immediately available when the user does navigate to them. Where normal resource loading is reactive, the browser fetches what is needed when it is needed, prefetching is proactive, the browser fetches what might be needed before the user asks for it.

The performance benefit of prefetching is significant, a resource that has been prefetched and is available in the browser cache loads from local storage in microseconds rather than requiring a network round trip. A user who clicks a link to a prefetched page experiences nearly instant navigation, the page content is already on their device before they clicked. This transformation of a network-dependent load into an instant local retrieval dramatically improves perceived performance for anticipated navigations.

Prefetching is one of several resource hints available to web developers, alongside preloading, preconnecting, and DNS prefetching, each addressing different aspects of speculative resource acquisition. Where prefetching targets complete future navigations, fetching the HTML and resources for a page the user will likely visit next, preloading targets resources needed for the current page, fetching critical assets the current page needs but that the browser would discover late in its normal loading sequence.

For redirect management prefetching has specific implications, a prefetched URL that returns a redirect response causes the browser to follow the redirect during prefetching, potentially prefetching the redirect destination rather than just the redirect response. Understanding how prefetching interacts with redirects enables designing redirect infrastructure that works correctly with prefetching behaviour and does not accidentally cause unintended prefetch destinations.

Types of prefetching

Several distinct prefetching mechanisms are available, each with different scope, browser support, and appropriate use cases.

<link rel="prefetch">, the standard HTML prefetching mechanism. A <link> element with rel="prefetch" instructs the browser to fetch the specified URL during idle time and store it in the browser’s prefetch cache, ready for immediate use if the user navigates to that URL.

<!-- Prefetch the next page in a multi-step flow -->
<link rel="prefetch" href="/checkout/payment">

<!-- Prefetch a likely next article -->
<link rel="prefetch" href="/blog/next-article">

<!-- Prefetch the next page in a multi-step flow -->
<link rel="prefetch" href="/checkout/payment">

<!-- Prefetch a likely next article -->
<link rel="prefetch" href="/blog/next-article">

<!-- Prefetch the next page in a multi-step flow -->
<link rel="prefetch" href="/checkout/payment">

<!-- Prefetch a likely next article -->
<link rel="prefetch" href="/blog/next-article">

The browser treats prefetch requests as low priority, they execute during idle periods when bandwidth and processing are not needed for higher-priority resources. Prefetched resources are stored in the browser’s HTTP cache, accessible for subsequent navigations within the session and potentially across sessions depending on cache control headers.

Speculation Rules API, a modern JavaScript-based API providing more sophisticated control over speculative navigation. The Speculation Rules API supports both prefetch, fetching the resource, and prerender, fetching, rendering, and executing the page fully in a background context, enabling near-instant navigation experiences.

<script type="speculationrules">
{
    "prefetch": [
        {
            "source": "list",
            "urls": ["/checkout/payment", "/products/popular-item"]
        }
    ],
    "prerender": [
        {
            "source": "document",
            "where": { "href_matches": "/blog/*" },
            "eagerness": "moderate"
        }
    ]
}
</script>

<script type="speculationrules">
{
    "prefetch": [
        {
            "source": "list",
            "urls": ["/checkout/payment", "/products/popular-item"]
        }
    ],
    "prerender": [
        {
            "source": "document",
            "where": { "href_matches": "/blog/*" },
            "eagerness": "moderate"
        }
    ]
}
</script>

<script type="speculationrules">
{
    "prefetch": [
        {
            "source": "list",
            "urls": ["/checkout/payment", "/products/popular-item"]
        }
    ],
    "prerender": [
        {
            "source": "document",
            "where": { "href_matches": "/blog/*" },
            "eagerness": "moderate"
        }
    ]
}
</script>

The Speculation Rules API enables more granular control, specifying eagerness levels, conservative, moderate, eager, that balance prefetch aggressiveness against bandwidth consumption and privacy implications.

<link rel="preconnect">, establishes early connections to anticipated origins, completing DNS resolution, TCP handshake, and TLS negotiation, before the browser discovers it needs resources from that origin. Preconnect does not fetch any specific resource, it prepares the connection infrastructure for faster subsequent resource loads.

<!-- Preconnect to CDN for faster asset loading -->
<link rel="preconnect" href="https://cdn.example.com">

<!-- Also prefetch DNS for lower-priority origins -->
<link rel="dns-prefetch" href="https://analytics.example.com">

<!-- Preconnect to CDN for faster asset loading -->
<link rel="preconnect" href="https://cdn.example.com">

<!-- Also prefetch DNS for lower-priority origins -->
<link rel="dns-prefetch" href="https://analytics.example.com">

<!-- Preconnect to CDN for faster asset loading -->
<link rel="preconnect" href="https://cdn.example.com">

<!-- Also prefetch DNS for lower-priority origins -->
<link rel="dns-prefetch" href="https://analytics.example.com">

<link rel="dns-prefetch">, resolves the DNS for an origin before resources from that origin are requested, eliminating DNS lookup latency when the browser eventually makes requests to that origin. DNS prefetch is lower overhead than preconnect, it performs only DNS resolution without TCP or TLS establishment, appropriate for origins that will be accessed but not immediately.

<link rel="preload">, fetches resources needed for the current page as early as possible, different from prefetch which targets future navigations. Preload is used for resources the current page needs but would otherwise discover late, LCP images, critical fonts, late-discovered CSS.

<!-- Preload the LCP image for faster LCP -->
<link rel="preload" as="image" href="/hero-image.webp" fetchpriority="high">

<!-- Preload a critical font -->
<link rel="preload" as="font" href="/fonts/brand-font.woff2" crossorigin>

<!-- Preload the LCP image for faster LCP -->
<link rel="preload" as="image" href="/hero-image.webp" fetchpriority="high">

<!-- Preload a critical font -->
<link rel="preload" as="font" href="/fonts/brand-font.woff2" crossorigin>

<!-- Preload the LCP image for faster LCP -->
<link rel="preload" as="image" href="/hero-image.webp" fetchpriority="high">

<!-- Preload a critical font -->
<link rel="preload" as="font" href="/fonts/brand-font.woff2" crossorigin>

How browser prefetching works

The browser’s prefetching process involves idle-time scheduling, low-priority network requests, and cache storage, designed to provide performance benefits without interfering with current-page loading.

Idle-time scheduling, prefetch requests are submitted as low-priority background tasks. The browser’s network scheduler prioritises resources needed for the current page, HTML, render-blocking CSS, critical scripts, the LCP image, and defers prefetch requests to idle periods when bandwidth and processing capacity are not fully utilised. This prioritisation ensures prefetching improves future navigation performance without degrading current page loading.

Network request execution, during idle periods the browser makes HTTP GET requests for prefetch URLs. These requests include standard request headers but may include a Sec-Purpose: prefetch header, indicating to the server that this is a speculative prefetch rather than a user-initiated navigation. Servers can use this header to handle prefetch requests differently, returning lightweight responses or declining to process the prefetch for certain URL types.

Prefetch cache storage, prefetched resources are stored in a separate prefetch cache, distinct from the regular browser cache. The prefetch cache has a limited lifetime, typically 5 minutes, after which cached prefetch entries expire and would need to be re-fetched if the user navigates to them. This limited lifetime prevents stale prefetched resources from being served to users who navigate to the URL after the prefetch data is outdated.

Navigation interception, when a user navigates to a URL that has been prefetched the browser intercepts the navigation and serves the prefetched response from the prefetch cache rather than making a new network request. The page loads from the cached prefetch response, appearing to load instantly from the user’s perspective.

Prefetching and redirects

Redirects interact with prefetching in specific ways, the browser follows redirects during prefetch requests just as it follows redirects during normal navigation.

Redirect following during prefetch, when a prefetch request encounters a redirect the browser follows the redirect, fetching the redirect destination rather than just storing the redirect response. A prefetch of example.com/old-page, which returns a 301 redirect to example.com/new-page, results in the browser prefetching example.com/new-page. The user who subsequently navigates to example.com/old-page is served the prefetched content of example.com/new-page, benefiting from the prefetch even through the redirect.

This redirect-following behaviour is generally beneficial, the content the user will ultimately see is prefetched rather than just the redirect response. However it creates an important consideration, the prefetch attribution and analytics impact differs from a non-prefetch navigation.

Analytics implications of prefetched redirects, a user whose browser prefetches a URL does not generate a session or conversion in analytics when the prefetch occurs, only when the user actually navigates to the URL. However the analytics tracking code on the prefetched page may execute as part of the prefetch process, depending on the browser’s prefetch implementation, potentially generating phantom analytics events. The Speculation Rules API addresses this by allowing server-side detection of prefetch requests through Sec-Purpose: prefetch headers, analytics code can check for this header and defer tracking until the page is actually visited.

Redirect cache interaction with prefetch, if a redirect is cached in the browser’s regular HTTP cache, a 301 permanent redirect stored from a previous visit, a prefetch request for the redirect source URL uses the cached redirect destination directly rather than fetching the redirect response from the server. The prefetch fetches the cached destination, which is the correct behaviour from a performance perspective but may not register the prefetch with server-side analytics or redirect tracking systems.

Prefetching redirect destinations directly, for URLs that are known to redirect to specific destinations prefetching the final destination URL directly, rather than the redirect source, is more efficient. The browser skips the redirect hop and prefetches the actual content that will be displayed. This requires knowing the redirect destination in advance, applicable when redirects are configured in a manageable system where destinations are known.

Avoiding prefetch loops, a page that prefetches URL A, which redirects to URL B, which prefetches URL A, creates a potential prefetch loop. While browsers implement loop detection that prevents infinite redirect chains the interaction between on-page prefetch hints and redirect configurations can create unexpected prefetch patterns. Auditing prefetch configurations for pages reachable through redirects ensures no inadvertent loops are created.

When to implement prefetching

Prefetching provides performance benefits only when the prediction is correct, prefetching a resource the user does not navigate to wastes bandwidth without benefit.

High-confidence next steps, prefetching is most valuable for highly predictable navigation patterns. Multi-step checkout flows, the user on the cart page almost certainly navigates to checkout next. Onboarding sequences, the user on step 1 almost certainly proceeds to step 2. Paginated content, the user reading article page 1 frequently continues to page 2. These patterns have high navigation probability, prefetching the next step provides performance benefits for most users.

Popular content linking, prefetching the most popular links on a page, the articles or products most users click from a given page, provides performance improvements for the majority of users without unnecessary prefetch waste for the minority who navigate elsewhere.

Search results, prefetching the top result for a search query as the user types, or as they hover over results, anticipates the most likely navigation and can produce near-instant load times for the clicked result.

Login and registration flows, users who submit login forms almost certainly navigate to their authenticated dashboard immediately after. Prefetching the dashboard page while the login form is being submitted, or even while the user is filling it in, can make the post-login navigation feel instant.

Prefetching best practices

Measure navigation probability before implementing, analytics data reveals which links are clicked by what percentage of users on each page. Prefetching links clicked by less than 10% of users wastes bandwidth for 90% of visitors. Focus prefetch investment on high-probability navigations, links clicked by the majority of users on a given page.

Respect user data preferences, users on metered connections, mobile data plans, may not want the browser to consume data on speculative prefetches. The navigator.connection.saveData API exposes whether the user has opted into a data-saving mode, prefetch implementations should check this flag and skip prefetching for data-conscious users:

if (!navigator.connection?.saveData) {
    // Add prefetch links for likely next pages
    const link = document.createElement('link')
    link.rel = 'prefetch'
    link.href = '/next-page'
    document.head.appendChild(link)
}

if (!navigator.connection?.saveData) {
    // Add prefetch links for likely next pages
    const link = document.createElement('link')
    link.rel = 'prefetch'
    link.href = '/next-page'
    document.head.appendChild(link)
}

if (!navigator.connection?.saveData) {
    // Add prefetch links for likely next pages
    const link = document.createElement('link')
    link.rel = 'prefetch'
    link.href = '/next-page'
    document.head.appendChild(link)
}

Prefetch on hover for high-probability links, triggering prefetch when the user hovers over a link, rather than on page load, provides a practical balance. Hover intent strongly predicts a click, most users who hover over a link click it. The hover-to-click delay, typically 200-400ms, provides time for a prefetch request to begin downloading content before the click occurs.

Monitor prefetch cache hit rates, analytics and server log analysis can reveal how often prefetched resources are actually used, the prefetch cache hit rate. Low hit rates indicate that prefetch predictions are inaccurate, wasting bandwidth without proportionate performance benefit. Refining prefetch rules based on actual hit rate data improves the efficiency of prefetch implementation.

Prefetching and SEO

Prefetching is a client-side performance optimisation, it does not directly affect search engine crawling, indexing, or ranking. Googlebot does not prefetch pages it discovers through link crawling, it crawls pages explicitly based on discovered links and submitted sitemaps.

However prefetching indirectly affects SEO through its impact on Core Web Vitals field data. Pages that are frequently prefetched and loaded from prefetch cache have faster load times in Chrome User Experience Report data, improving the field data that feeds Core Web Vitals ranking signals. A site that implements effective prefetching for common navigation patterns sees improved LCP field data for those pages, potentially improving their Page Experience rankings.

The relationship between prefetching and TTFB is particularly relevant, a page loaded from prefetch cache has zero network TTFB, the browser serves the prefetched content from local storage without any server request. TTFB for prefetched pages is therefore negligible, among the best possible TTFB values. These fast-TTFB visits from prefetched navigations improve the 75th percentile field TTFB for affected pages, which feeds into LCP calculations and Core Web Vitals assessments.