Speculation Rules API: Instant Page Loads for Shops

The fastest page load is the one that already happened before the customer clicks. That is exactly what the Speculation Rules API enables: it lets the browser load or fully prerender likely next pages in the background, so the actual click opens almost instantly. For online shops this is a direct conversion lever, because product pages and checkout appear practically immediately. Eyewear brand Ray-Ban doubled its mobile conversion rate through prerendering and cut its exit rate by around 13% (Ray-Ban, web.dev). This article explains how the Speculation Rules API works, how we deploy it in the shop, and where the pitfalls are.

What the Speculation Rules API Is

The Speculation Rules API is a browser interface that lets a website tell the browser which follow-up pages to speculatively preload. Unlike the deprecated <link rel="prerender"> approach, the rules are passed as JSON inside a <script type="speculationrules"> block or via an HTTP header (MDN Web Docs). The API deliberately targets document URLs, which makes it a fit for classic multi-page applications like most shop systems, not for single-page apps (MDN Web Docs).

The core idea is simple: if a visitor is highly likely to open a specific product page next, the browser can fetch that page ahead of time and keep it in memory. When the user actually clicks, the prepared page is merely displayed instead of loaded anew. According to Google, prerendering the likely next page is one of the most effective ways to dramatically improve Largest Contentful Paint (LCP), because loading is practically complete before the click (web.dev). The result is a near-zero LCP, reduced layout shift, and better interactivity (web.dev).

Prefetch and Prerender: the Decisive Difference

The API offers two levels of preloading that differ sharply in effect and resource cost. Prefetch merely loads the target page's HTML document via a GET request and stores the response in a per-document cache; the page is not yet rendered (MDN Web Docs). Prerender goes much further: the browser loads the page into an invisible tab, runs the JavaScript, and loads all subresources, so the later navigation is near-instant (Chrome for Developers).

In practice this means: prefetch can be applied generously to many links because it costs little, whereas prerender should be reserved for the most likely navigation targets due to its higher cost (MDN Web Docs). Chrome itself estimates a prerender's cost at roughly that of one additional embedded page (Chrome for Developers). Cross-site prefetch only works if no cookies are set for the target site, and cross-site prerender is currently not possible (MDN Web Docs).

Worth knowing: the prefetch store is deliberately short-lived. It is tied to the current document and released again when the page is left (MDN Web Docs). Prefetch is therefore suited to the immediate next clicks, not as a permanent cache replacement. For recurring patterns - such as the always-same path from the home page into the most-visited category - server-side caching remains the load-bearing layer that sensibly complements speculative preloading.

Why Milliseconds Decide Revenue

In e-commerce, load time is not a technical detail but a hard revenue metric. According to Google analyses, the probability of a bounce rises by 32% when load time grows from one to three seconds (Google). Even improving mobile load time by just 0.1 seconds increased retail conversions by 8.4% (Deloitte). This is precisely where prerendering steps in: it moves loading out of the customer's perceived wait and into the background.

Prerendering the next page a user visits is an effective way to dramatically improve LCP performance - made possible by the Speculation Rules API.

web.dev (Google)

The link between load time and business outcome is documented across the industry. Vodafone improved its LCP by 31% and achieved 8% more sales (web.dev). Lazada reached a 16.9% higher mobile conversion rate through a threefold faster LCP (web.dev). AliExpress halved its load time and cut bounce rate by 15% (web.dev). For shop operators this means: whoever makes product and category pages appear instantly wins exactly where purchase decisions are made. A solid performance strategy pays straight into the margin.

Eagerness: Steering Preloading Precisely

The most important control of the API is eagerness, the urgency with which speculation happens. It determines how early the browser preloads a page - and thus the balance between speed and resource use. Four levels are available (Chrome for Developers):

• immediate: Preload as soon as the rule is observed. Useful for very likely targets, such as the first product in a list.
• eager: Triggers very early, on desktop after roughly 10 milliseconds of hover, on mobile based on viewport heuristics.
• moderate: The proven middle ground. On desktop after about 200 milliseconds of hover or on pointerdown, on mobile after scrolling stops.
• conservative: Triggers only on pointerdown or touch - the most economical mode, ideal for broadly scoped rules.

For a shop, a combination usually works best: moderate to prerender the most likely product pages and conservative for a broad prefetch of all remaining links. Here is a typical rule configuration that deliberately excludes cart and checkout pages:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/product/*" },
        { "not": { "href_matches": "/cart" } },
        { "not": { "href_matches": "/checkout" } },
        { "not": { "selector_matches": ".no-prerender" } }
      ]
    },
    "eagerness": "moderate"
  }],
  "prefetch": [{
    "where": { "href_matches": "/*" },
    "eagerness": "conservative"
  }]
}
</script>

Implementation in the Shop: Speeding Up Product and Checkout Loads

In an online shop there are several places where prefetch and prerender pay off especially well. The key is to couple preloading to actual purchase intent - such as hovering over a product tile - rather than preloading everything indiscriminately. These are the entry points we typically implement first in shop development:

The most important lever is almost always the jump from category to product page, because it happens millions of times. Ray-Ban triggered prerendering on desktop via hover with moderate eagerness and preloaded the first product tiles on mobile with immediate (Ray-Ban, web.dev). For performance-critical shops, preloading can additionally be combined with fast network protocols and efficient caching so that even the background fetch stays minimal.

Avoiding E-Commerce Pitfalls Safely

Prerendering is powerful but must be used carefully in a shop context. The biggest risk is URLs with side effects: a preloaded logout link would unintentionally sign the user out, a preloaded cart link could change state. Chrome explicitly recommends excluding addresses that change server state or are not cacheable (Chrome for Developers). In practice we therefore consistently exclude cart, checkout, logout, and account actions from the rule set.

// Count the page view only on real display, not during prerendering
function trackPageView() {
  // the actual analytics call goes here
}

if (document.prerendering) {
  // page is being prerendered invisibly: wait for activation
  document.addEventListener('prerenderingchange', trackPageView, { once: true });
} else {
  // normal load or an already activated prerender
  trackPageView();
}

• Exclude state-changing URLs: Cart, checkout, logout, and account endpoints do not belong in the prerender rules.
• Keep pages current: Changes such as a newly filled cart should be mirrored into prerendered pages via the Broadcast Channel API so the user does not see a stale state (Chrome for Developers).
• Watch server load: During promotions and traffic spikes, preloading can generate extra requests - keep a way to disable the rules quickly (Chrome for Developers).
• Ensure cacheability: Well-cacheable pages significantly reduce the additional server load of preloading.
• Consider legal requirements: Automatically preloaded content should align with your product and safety obligations and your consent logic.

Measurable Results From Practice

The impact of prerendering is well documented in public case studies. Ray-Ban reduced LCP on product pages on mobile from 4.69 to 2.66 seconds (minus 43%) and on desktop from 3.03 to 1.74 seconds (minus 43%) (Ray-Ban, web.dev). In parallel, mobile conversion rate rose by 101% and desktop conversion by as much as 156%, while exit rate dropped by around 13% (Ray-Ban, web.dev). Pages per session also increased markedly, by 52% on mobile and 65% on desktop (Ray-Ban, web.dev).

Publishing group Monrif demonstrates the impact outside retail: on their news sites, LCP fell depending on the title by 433 milliseconds (17.9%), 407 milliseconds (17.1%), and 350 milliseconds (15%) (Monrif, web.dev). Engagement rose in turn by up to 8.9% (Monrif, web.dev). Notable is the platform difference: on desktop 13.9% of page views triggered prerendering, on mobile only 2.9% (Monrif, web.dev) - a hint that rules take effect to different degrees depending on device class.

Even highly optimized sites benefit. By prefetching the first two results, Google Search shortened LCP on Chrome for Android by 67 milliseconds and on desktop by 58.6 milliseconds (Chrome for Developers). For an already heavily tuned site, such millisecond gains are considered remarkable (Chrome for Developers). For a typical shop with considerably more optimization headroom, the effects are usually larger.

An often-overlooked twin of prerendering is the back/forward cache (bfcache), which keeps complete pages in memory for forward and back navigations. Ray-Ban raised the bfcache hit rate of a category page from 0.02% to 72.90% (Ray-Ban, web.dev) by removing unload listeners and switching to the pagehide event. Together with prerendering, this creates a consistently fast navigation experience - forward and backward alike. For shop operators it pays to review both techniques together rather than turning just one dial.

Putting Browser Support and Limits Into Perspective

The Speculation Rules API is an enhancement, not a must - and it should be treated as such. According to MDN it is currently considered experimental and not Baseline, because it does not work in all widely used browsers (MDN Web Docs). The practical advantage: browsers that do not understand the rules simply ignore the speculationrules block and load the page normally. That makes prerendering an ideal case of progressive enhancement: users on supporting browsers get instant navigation, everyone else gets the familiar experience. A good baseline on Core Web Vitals therefore remains the foundation.

The origin rules are worth knowing too. Prerendering is by default restricted to same-origin documents; cross-origin within the same site is only possible if the target page explicitly opts in via the Supports-Loading-Mode header (MDN Web Docs). For most shops this is uncritical, because category, product page, and checkout live on the same domain anyway. For headless architectures with separate frontends, however, a careful review of the domain structure pays off before rules are activated.

This feature is not Baseline because it does not work in some of the most widely-used browsers - treat it as an enhancement, not a requirement.

MDN Web Docs

Using Instant Navigation as a Conversion Lever

The Speculation Rules API is among the few performance measures that not only lower perceived load time but make it nearly disappear. For shops with many product views, the path from category to product page is the obvious starting point, complemented by broad prefetch and a consistent exclusion of state-changing URLs. Combined with solid load-time optimization and clean caching, this creates a noticeably faster shopping experience.

We accompany the rollout from analyzing the most frequent navigation paths through defining safe rules to measuring in field and lab data. Whether as part of a relaunch project, a targeted Shopware performance optimization, or a building block of a modern shop architecture with AI connectivity: prerendering is a pragmatic lever with a direct effect on conversion and visibility. Start with an inventory of your top navigation paths - that is usually where the greatest potential lies.