HomeMethod

Knowledge

Web VitalsTechniquesSnippetsAnswersImpactsBottlenecks

Preload Links

Prefetch the next likely page in the background so navigation feels instant when the user clicks.

Each ring is a metric this technique moves.

Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: TBT, CLS.

The Problem

Every page navigation involves a full round trip to the server: DNS + TCP + TLS handshake, the HTML request, then further requests for CSS, fonts, and the new page’s LCP image. Even on a fast connection this adds 300–800ms of waiting time. On content-heavy sites with high pages-per-session, this latency compounds — users feel every click as a pause.

Performance Impact

LCP

High

pre-fetched resources make the next page render immediately, reducing its LCP to near-zero

FCP

High

first paint on the next page happens as soon as it is navigated to, not after network round trips

SI

next-page resources are already cached on click; navigation renders immediately, SI approaches zero on prefetched pages

TTFB

High

the next page’s HTML is already in cache when the user navigates — TTFB is effectively zero

Risk: Medium

prefetching pages the user does not visit wastes bandwidth — especially on mobile connections

How it works

  1. 01

    link rel="prefetch" — low-priority background download

    <link rel="prefetch" href="https://adame.io/next-page/" as="document"> asks the browser to fetch the URL at low priority when it has spare capacity. The fetched document is stored in the HTTP cache. When the user navigates to that URL, the browser serves it from cache rather than making a new request.

  2. 02

    Hover-based prefetch with JavaScript

    Libraries like instant.page and quicklink watch for mouseover events on links. After a short delay (65ms by default) — long enough to indicate intent but short enough to anticipate the click — they dynamically inject a <link rel="prefetch"> for that URL.

  3. 03

    Speculation Rules API — prerender

    The Speculation Rules API (Chromium browsers) goes further than prefetch: a prerender rule downloads the next page and renders it in a hidden background process. Navigation is truly instant — the visible page is already fully rendered when the user clicks.

  4. 04

    WordPress implementation

    Prefetch hints can be added via the wp_head action for known high-probability next pages. Performance plugins such as Flying Pages or Speculation Rules for WordPress handle the dynamic hover-based approach automatically.

Static prefetch in wp_head

Code
<?php
add_action('wp_head', 'prefetch_likely_next_pages');
function prefetch_likely_next_pages() {
    if ( is_front_page() ) {
        echo '<link rel="prefetch" href="/blog/" as="document">\n';
    }
    if ( is_page('pricing') ) {
        echo '<link rel="prefetch" href="/checkout/" as="document">\n';
    }
}

Use this for known high-conversion paths where the next step is predictable (homepage → blog, pricing → checkout).

Speculation Rules API

Code
<script type="speculationrules">
{
  "prefetch": [{
    "source": "document",
    "where": { "href_matches": "/*" },
    "eagerness": "moderate"
  }],
  "prerender": [{
    "source": "list",
    "urls": ["/checkout/"]
  }]
}
</script>

The Speculation Rules API is supported in Chrome/Edge. Use eagerness: "moderate" (trigger on hover) rather than eager (trigger on link visibility) to avoid excessive prefetching.

Limitations

  • Every prefetched page that the user does not visit consumes bandwidth for nothing. This is especially costly on metered mobile connections. Limit prefetching to the highest-probability destinations.
  • Prefetching increases server load — requests still hit the server even if the user does not navigate. On shared hosting or high-traffic sites this can be significant.
  • The Speculation Rules API is currently only supported in Chromium-based browsers. Other browsers fall back to no prefetching.
  • Prefetched content may be stale if it changes between prefetch and navigation. This is more relevant for frequently updated pages.

Common Mistakes

Prefetching all links on the page

Fetching every visible link is the quickest way to spike server load and waste bandwidth. Prefetch only the most likely next destination — typically one or two URLs per page.

Using rel=”preload” instead of rel=”prefetch” for future pages

preload is high-priority and intended for resources the current page needs immediately. Using it for another page’s assets delays the current page’s own critical resources.

Not respecting the data-saver preference

Check navigator.connection.saveData before inserting prefetch hints. Users on metered connections have explicitly opted out of background data usage.

Prefetching links that trigger JavaScript actions rather than navigation

Buttons that open modals, accordion toggles, or filter controls are not navigation targets. Prefetching their href values fetches resources that will never be used as a page.

Test this techniqueResource HintsRun the tool

Need help applying this to your site?

Targeted fixes, not guesswork. We identify which techniques move the needle for your specific WordPress stack.

Start an Engagement
Support our family now