Speculative Loading & Prefetching: Navigations Before the Click

This topic is part of Network & Server Response Optimization. Every optimization so far makes the next page load faster. Speculative loading makes it load before it is requested. If the browser fetches the HTML of a likely next page while the user is reading the current one, that navigation skips TTFB. If the browser fully prerenders the page — loading its subresources, running its scripts, laying it out in a hidden tab — activating it is nearly instantaneous: LCP for that navigation can be close to zero.

The modern tool is the Speculation Rules API: a JSON block (or HTTP header) that tells the browser which URLs to prefetch or prerender, either as explicit lists or via document rules that match links on the page, with an eagerness setting that controls when speculation starts — immediately, when the user hovers a link, or when they start pressing it. Older and complementary approaches include <link rel="prefetch">, libraries that prefetch links as they enter the viewport during idle time (Quicklink), and framework routers that prefetch route code and data on hover or visibility.

Speculation spends resources on guesses. Each prefetch costs bandwidth and server capacity; each prerender also costs memory and CPU on the user's device, and runs the page's scripts — including analytics that must not count a visit that never happened. The art is in predicting well and speculating at the right moment.

The Metric Degradation This Topic Addresses

Speculative loading improves LCP, FCP and TTFB for the navigations it predicts correctly, and INP can benefit too, since a prerendered page has already run its startup JavaScript. In field data, these navigations show near-zero TTFB and very low LCP, which pulls p75 down when a meaningful share of navigations are speculated. The flip side is cost: wasted prefetches show up as extra server requests and bandwidth; wasted prerenders as extra CPU and memory use on devices, potentially affecting the current page if done too aggressively.

Chrome reports prerendered navigations in the Navigation Timing entry (activationStart > 0), and the web-vitals library adjusts metrics to be relative to activation. Segment field data by navigation type (navigate, prerender, back-forward-cache, restore) to see the effect.

Prerequisites

• Navigation analytics: which pages users go to next from each template.
• RUM that records navigation type and activation start.
• The ability to add a script block or response header to pages.

1. Environment Setup: Find Predictable Navigations

Use analytics to build a transition table: for each page type, the top next pages and their probabilities. Search results to the first result, article to next article, category to product, homepage to top categories are common high-probability transitions.

2. Capture a Baseline

Record LCP and TTFB for subsequent navigations (not entry pages), and the distribution of navigation types. Note server capacity and bandwidth costs.

3. Isolate Safe Candidates

Exclude URLs with side effects on GET (logout, add-to-cart links, one-time tokens), pages that are expensive to render, and pages behind authentication flows that may behave differently in a prerender.

4. Apply Speculation Rules With Appropriate Eagerness

<script type="speculationrules">
{
  "prerender": [{
    "where": { "and": [
      { "href_matches": "/articles/*" },
      { "not": { "selector_matches": "[rel~=nofollow], .no-prerender" } }
    ]},
    "eagerness": "moderate"
  }],
  "prefetch": [{
    "where": { "href_matches": "/*" },
    "eagerness": "conservative"
  }]
}
</script>
<!-- trade-off: "moderate" starts on ~200ms hover (or pointerdown on touch), giving
     high hit rates with some waste; "eager" speculates earlier with more waste. -->

Deconstructing Prefetch vs Prerender

Prefetch fetches the document (and with speculation rules, only the document) into a short-lived cache. On navigation, the browser uses it, skipping TTFB; subresources still load, and the page still renders. It is cheap — one request — and safe for most pages.

Prerender loads and renders the entire page in an invisible tab: subresources download, scripts run, layout happens. On navigation, the browser swaps the prerendered page in. It costs as much as a full page load (network, CPU, memory) and runs JavaScript with side effects, so pages must be prerender-safe. Browsers limit the number of concurrent prerenders and may skip them under memory pressure or data-saver modes.

A common strategy combines both: conservative prefetch broadly (many links, low cost), and moderate prerender for a few high-probability patterns.

Advanced Diagnostics and Edge Cases

Analytics and side effects. Prerendered pages run scripts before the user sees them. Analytics must wait for activation (document.prerendering and the prerenderingchange event). Many analytics libraries already handle this.

Personalisation and auth. Prerendered pages use the user's cookies; if a page's content depends on state that changes before activation (cart contents), it may be stale.

Cross-origin speculation. Cross-origin prefetch is supported with limitations (no cookies unless configured); cross-origin prerender is restricted. Same-site is the main use case.

Server load. Speculation increases requests. Cache speculated pages at the CDN where possible; use Sec-Purpose: prefetch request headers to identify and deprioritise speculative requests if needed.

Mobile and data saver. Browsers reduce or disable speculation under data saver or low memory. Do not rely on it for essential performance.

Validation and Budgeting

Validate in DevTools (Application → Speculative loads shows rules, candidates and their status) and in the field: share of navigations prerendered or prefetched, LCP for those navigations, and hit rate (speculations that were used). Watch server request volume and bandwidth.

Worked Example: A Recipe Site

A recipe site's users typically moved from search results or category pages to a recipe, then to related recipes. LCP p75 for these subsequent navigations was 2.3 seconds on mobile. The team added speculation rules: moderate-eagerness prerender for recipe links, conservative prefetch for all same-site links, and excluded print and share URLs. Analytics were updated to fire page views on activation. Thirty-eight percent of subsequent navigations became prerendered, with a 61% hit rate for started prerenders. LCP p75 across all subsequent navigations fell from 2.3 to 1.4 seconds, and recipe pages per session rose 9%. Origin requests rose 7%, mostly absorbed by CDN caching of recipe HTML.

Prediction Strategies

Speculation is only as good as its predictions. Static rules cover predictable layouts: next/previous links, the first search result, the top categories. Document rules with selectors cover link sets on a page, letting the browser speculate based on hover or press. Server-side predictions use analytics to inject speculation lists per page: for each article, the three most common next articles. Viewport-based prefetching prefetches links as they become visible during idle time, which works across browsers but can waste bandwidth on long pages with many links. Start with moderate-eagerness document rules — they need no prediction model and achieve high hit rates — then add targeted immediate rules for the highest-probability transitions.

Speculation and Back/Forward Cache

Speculation covers forward navigations; the back/forward cache (bfcache) covers going back and forward through history. A page restored from bfcache appears instantly with its state intact. Pages become ineligible for bfcache when they use unload handlers, Cache-Control: no-store (in some browsers), open IndexedDB transactions or WebSocket connections at the time of navigation, and other blockers. Fixing bfcache eligibility is often the cheapest instant-navigation win: Chrome DevTools' Application → Back/forward cache panel lists blocking reasons for the current page.

Speculation in Single-Page Applications

Speculation rules apply to full document navigations. Single-page applications navigate by swapping content client-side, so their equivalent is route prefetching: loading the JavaScript chunk and data for a likely next route before the user clicks. Most routers do this already — Next.js prefetches links in the viewport in production, SvelteKit can preload code and data on hover with data-sveltekit-preload-data, Nuxt prefetches route components for visible links, and Angular supports preloading strategies for lazy routes. The same principles apply: prefetch cheap things broadly (code chunks), fetch expensive things narrowly (data for routes with high click probability), and avoid side effects. For multi-page sites built with these frameworks, speculation rules and framework prefetching can be combined, with rules covering full-page navigations and the router covering in-app transitions.

Server-Side Considerations

Speculation shifts some traffic from "when the user clicks" to "when the user might click", and adds requests that are never used. For HTML cached at the CDN, the extra cost is small. For uncached, server-rendered pages, every speculative request is real server work. Three practices keep this in check. First, cache speculatable pages at the edge, even briefly. Second, identify speculative requests by the Sec-Purpose header so you can log them separately, serve them from cache only, or reject them under load (a non-2xx response simply cancels the speculation). Third, make speculative responses cheap: skip expensive personalisation for prerender requests when the activated page can fill it in client-side.

Monitoring should track the ratio of speculative to real navigations per template. A rising ratio without a matching rise in activations means rules are matching more links than users click, and eagerness or patterns need tightening.

Measuring the Benefit Correctly

The goal of speculation is faster navigations for users, and the right measure is the distribution of LCP across all subsequent navigations, not only the prerendered ones. If 40% of subsequent navigations are prerendered with LCP near zero, and the rest are unchanged, the p75 of the whole distribution still improves noticeably. Report three numbers per template: the share of navigations that were prerendered or prefetched, the LCP p75 of each navigation type, and the overall LCP p75. Combine these with server-side counts of speculative requests to express the trade-off: milliseconds saved per thousand speculative requests. That makes eagerness decisions an engineering trade-off rather than a guess.

Privacy and User Considerations

Speculation uses the user's resources on their behalf, so it should respect their signals. Browsers already reduce or disable speculation when the user enables data saver, when battery is low, or when memory is constrained, and they partition speculative loads like other storage. Sites should add their own restraint: avoid speculating to third-party origins (which reveals browsing intent to those parties before the user clicks), avoid prerendering pages that start media playback or request permissions, and keep eagerness modest on pages popular with users on metered connections. Speculation that respects these limits is invisible to users except as speed; speculation that ignores them can cost users data and battery for pages they never open.

A Rollout Plan

1. Analyse navigation transitions and identify safe, likely next pages.
2. Make analytics and side-effecting scripts prerender-aware.
3. Add conservative prefetch for same-site links.
4. Add moderate prerender for high-probability link patterns.
5. Fix bfcache blockers for back/forward navigations.
6. Measure navigation types, hit rates, LCP and server load per template, then tune eagerness and patterns based on what you see.

Common Pitfalls

• Prerendering side-effecting URLs. Logouts, cart actions, one-time links.
• Counting prerendered page views. Analytics fire before activation.
• Immediate eagerness for many URLs. High waste, memory pressure, server load.
• Ignoring bfcache. Back navigations remain slow while forward ones are instant.
• Measuring without segmentation. Prerendered navigations mixed with normal ones obscure both.

FAQ

Guides in This Topic

• Speculation rules for instant navigations — rules, eagerness and debugging.
• Prerender vs prefetch cost trade-offs — choosing per link pattern.
• Viewport prefetching with Quicklink — cross-browser idle-time prefetching.
• Avoiding analytics double counting on prerender — correct measurement.

Related

• Back/forward cache (bfcache) — instant back and forward navigations.
• Time to First Byte (TTFB) optimization — for navigations that are not speculated.
• SvelteKit preloading and load functions — framework-level prefetching.