Speculation Rules API

TL;DR — The Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. lets your site tell Chrome or Edge to load the next page a visitor is likely to click — quietly, in the background — before they click it. When they do click, the page can appear almost instantly. It’s a speed feature for real people using Chromium browsers. It does not help Google crawl or rank your site, but it can make pages feel faster, which is good for users (and, indirectly, for Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.).

What it is

Normally, when you click a link, the browser starts fetching that page from scratch — and you wait. The Speculation Rules API lets a site get a head start: it tells the browser “the visitor will probably go here next, so start getting it ready now.” When the click finally happens, the browser swaps in the page it already prepared instead of starting over.

There are two versions of “getting it ready,” and the difference matters:

• Prefetch — the browser quietly downloads the next page’s HTML in the background. Lighter weight, lower risk.
• Prerender — the browser fully loads and renders the next page in an invisible tab, running its JavaScript and everything. Heavier, but the page can appear truly instantly. Riskier, so you use it sparingly.

You set this up with a small block of JSON on your page. You can list exact URLs, or tell the browser “prepare any link the visitor hovers over.”

Does it help SEO?

Short version: not the way people hope. It won’t get you crawled or indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. faster. GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. doesn’t need this — it’s a feature for human visitors in Chrome and Edge, not for search botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index..

What it can do is make your pages feel faster once someone is already on your site, clicking around. Faster real-world experiences feed into Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., which is a (modest) ranking signal — and, more importantly, faster pages tend to convert better. Ray-Ban, for example, reported a big jump in conversions after prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. product pages.

The one thing to watch out for

Your analytics can lie to you. If the browser prerenders a page before the visitor ever sees it, and that page fires a “pageview” the moment it loads, your analytics will count a visit that never happened. Google Analytics 4’s own script handles this correctly on its own — but many other tags and pixels don’t, and they’ll log phantom pageviews unless a developer patches them.

If you’re on WordPress 6.8 or later, you already have a safe, conservative version of this turned on by default (prefetch only, for logged-out visitors). You didn’t have to do anything — it came with an update.

Want the full picture — prefetch vs. prerender in detail, eagerness levels, the “never prerender this” list, and how to fix the analytics problem? Switch to the Advanced tab.

TL;DR — The Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. (Chromium, Chrome/Edge 109+) lets a site declare — in JSON, inline or via a Speculation-Rules header — which same-site URLs the browser should prefetch (download the document; pays down TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.) or prerender (fully fetch, render, and run JS in an invisible tab; pays down TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. + FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. + LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.). Eagerness (immediate/eager/moderate/conservative) controls when a rule fires, separate from which URLs it targets. It is not a crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor./indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed./ranking mechanism — GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. doesn’t rely on resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. like this (per Illyes’ Feb 2026 comments on hints generally) and Google publishes no Search docs on it. But Google Search itself uses it to prefetch its top results, and Ray-Ban reported large conversion + LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. wins, so the payoff is real for actual visitors via Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and UX. Biggest gotchas: analytics double-counting (fix with document.prerendering/prerenderingchange), state-changing GET URLs (logout, add-to-cart) you must never speculate, and Chromium-only support. Start with prefetch broadly; add prerender to one or two high-confidence pages at most.

What the Speculation Rules API actually is

The Speculation Rules API is a browser API — Chromium only — that lets a site tell the browser which same-site pages to prepare before a visitor clicks. Per MDN, the API is designed to improve performance for future navigations, and because it targets document URLs rather than individual resource files, it makes sense for multi-page sites rather than single-page apps. It supersedes the old, deprecated, Chrome-only <link rel="prerender"> and goes beyond the widely-available <link rel="prefetch"> with a more expressive JSON syntax.

Rules are declared as JSON, either inline in a <script type="speculationrules"> block or via a Speculation-Rules HTTP response header. They can list explicit URLs or auto-match links on the page via where/href_matches conditions (called document rules).

There are two speculative actions, and getting the distinction right is the whole game:

• Prefetch downloads the response body of the referenced page — but not its subresources. It pays down the next page’s TTFB.
• Prerender fetches, renders, and loads the page into an invisible in-memory tab: all subresources, all JavaScript, even data fetches kicked off by JS. Per MDN, future navigations to a prerendered page are near-instant. It pays down TTFB and FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCP — but it’s far more expensive and riskier.

Harry Roberts’ shorthand in his layered-approach write-up captures it well: prefetch is for paying down TTFB, prerender is for LCP.

One under-covered technical nuance: speculated resources land in the browser’s memory cache, which is quicker to retrieve than the HTTP cache the older <link rel="prefetch"> hint uses. And a prefetched or prerendered document also populates the HTTP cache, so even a speculation the visitor never uses isn’t pure waste — a later navigation can still benefit.

Eagerness: when to speculate, separate from which URLs

A genuinely clever design choice here is that eagerness is a separate lever from targeting. Barry Pollard’s Chrome blog post on the API’s improvements frames it as separating when to speculate from which URLs to speculate on. There are four levels:

• immediate — speculate as soon as the rules are seen (on page load).
• eager — start on the slightest signal.
• moderate — roughly a 200ms hover (or pointerdown on touch).
• conservative — pointer- or touch-down, i.e. the visitor has all but clicked.

Treat these four trigger definitions as Chrome’s current heuristics, not a fixed spec — Chrome has changed the exact mobile triggers more than once (it moved moderate to viewport-based heuristics and adjusted eager’s timing as recently as January 2026), so re-check the live docs before quoting an exact millisecond or percentage threshold in your own implementation notes.

Two related refinements worth knowing: No-Vary-Search lets the browser reuse a cached document that differs only by ignorable parameters (e.g. UTM-tagged variants of the same page), and the newer prerender-until-script pattern (covered by CoreWebVitals.io) offers a middle ground between plain prefetch and a full prerender — as of this writing it’s still an experimental, not-generally-available action running in a Chrome origin trial, not a shipped default.

Chrome’s own guardrails

You can’t accidentally nuke a visitor’s device with an over-broad rule. Chrome’s prerender documentation sets hard, FIFO caps regardless of your configuration: for immediate-eagerness rules, 50 prefetches and 10 prerenders; for interaction-based (moderate/ conservative) rules, 2 slots. Chrome also treats a prerender as a hint and a progressive enhancement, not a guarantee — it can decline based on the user’s settings or resource constraints — and it won’t render cross-origin iframesHTML element that displays one webpage inside another — how embeds work. on a prerendered page until activation. A built-in privacy guard also blocks cross-site prefetches when the user already has cookies set for the destination site.

Cross-origin rules, and what actually happens inside a prerendered page

Per MDN, prerendering is restricted to same-origin documents by default. Cross-origin, same-site prerendering is possible, but only if the target page opts in with a Supports-Loading-Mode: credentialed-prerender response header — cross-site prerendering isn’t possible at all as of this writing. Cross-site prefetch is more permissive (same-site and cross-site prefetches both work), but still gated by the no-cookies-set privacy rule above; a broader cross-site prefetch opt-in via Supports-Loading-Mode is documented as planned but not yet shipped.

Inside the hidden tab, a prerendering page isn’t a normal page load: intrusive APIs (alert()/confirm()/prompt(), requestFullscreen(), Navigator.share()) are blocked or ignored, async APIs like geolocation and getUserMedia() are deferred until activation, and cross-origin iframes and worker scripts don’t run until then either. Session storage gets special handling worth knowing if your page reads it on load: a prerendering page starts with a clone of the tab’s session storage, and that clone is discarded in favor of the real tab’s storage at activation — so test any session-storage-dependent logic both before and after the prerenderingchange event, not just on a normal load. For timing, document.prerendering and prerenderingchange tell you the state and the activation moment; PerformanceNavigationTiming.activationStart gives you the actual elapsed time between prerender start and activation if you want to measure it.

Does the Speculation Rules API affect SEO, crawling, or rankings?

This is the question every SEO wants answered, and most competing articles wave it away. The precise answer has two halves.

What it does NOT do

It is not a crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., or ranking mechanism. There is no Google Search Central documentation tying the Speculation Rules API to how GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawls or indexes — because it doesn’t touch that layer at all. It’s a browser feature for human visitors in Chromium.

The closest thing to an on-the-record Google statement is Gary Illyes on Search Off the Record (early 2026), talking about resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. in general — not the Speculation Rules API by name. As Search Engine Journal reported, Illyes’ point was that Googlebot’s own infrastructure has near-infinite bandwidth and very fast DNS resolution, so hints like DNS-prefetch and preload hold essentially no value for its crawling process — it can already talk to servers fast and doesn’t need to be told to fetch things earlier. Treat that as support for “this is a browser/visitor feature, not a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. one,” but note the scope: Illyes was addressing the broader resource-hints family, not Speculation Rules specifically. This is the same discipline the sibling resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. piece applies.

Also worth stating plainly because people ask: Bing has published nothing on the Speculation Rules API for SEO. Edge (Chromium 109+) supports it as a browser feature, but there’s no bingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. or indexing angle — which is exactly what you’d expect for a renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.-browser feature rather than a search-engine-crawler one.

What it CAN do

It can improve Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — especially LCP, and indirectly INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. by front-loading JavaScript execution before the interaction happens — for real users. Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. is a documented (if modest) ranking signal via the page experience system, so there’s an indirect ranking pathway. But the stronger case is plain UX and conversion: making the next page feel instant is a real business lever independent of rankings.

The non-overclaiming way to frame it: Speculation Rules won’t get you crawled or indexed differently — it makes a page feel instant once a real visitor is already navigating your site, which is a UX and Core Web Vitals lever, not a crawler one.

Real-world results

Two proof points do the heavy lifting here, and both come from Google’s own publications.

Google Search uses it on itself. Per the Chrome team’s 2025 announcement, one of the first uses of speculation rules was to prefetch the first two search results. The measured gains: on Android Chrome, LCP for clicks from Google Search was reduced by 67 milliseconds; on desktop, a similar 58.6 millisecond LCP improvement. Hover-based prefetching of the remaining results cut desktop FCP by 7.6 milliseconds and LCP by 9.5 milliseconds. For cross-origin result prefetches, Google Search routes them through Chrome’s private prefetch proxy to anonymize the request. Very few competing articles cite that Google trusts this enough to run it on google.com/search at scale — and published the exact millisecond deltas.

Ray-Ban’s case study is the business-impact proof. Google’s web.dev case study reports that after prerendering product pages, mobile conversion rates on PDPs increased by 101.47% and desktop by 156.16%, with a 43% improvement in LCP on both desktop and mobile. Exit rates dropped roughly 13% on both, and pages viewed per session rose 51.95% on mobile and 65.30% on desktop. The implementation split is instructive: desktop used moderate eagerness triggered by hovering product tiles; mobile (no hover state) used immediate eagerness on just the first four tiles, which were the most-clicked.

And the scale is already large: WordPress 6.8 (March 2025) ships this by default, building on a feature plugin that was on tens of thousands of sites before core adoption — meaning a meaningful share of the web already has speculation rules running without anyone configuring them.

How to implement it safely

The consensus adoption order, from both Google’s docs and independent experts:

1. Start with prefetch, broadly. Per Chrome’s implementation guide, prefetch is relatively safe for most sites and is the initial approach many take.
2. Add prerender narrowly, later. Chrome’s docs warn against over-prerendering at a cost of user resources, and recommend keeping prerenders down to one or two pages at most. Harry Roberts reaches the same conclusion independently — a wildcard-like match is too greedy, and prerendering everything is usually too expensive and too risky; an opt-in approach is better.
3. Use document rules to scale without per-page config. Rather than hand-listing URLs on every page, a where/href_matches condition sources URLs from the document itself so one rule set can apply site-wide.
4. Mind your CSP. Inline <script type="speculationrules"> blocks need explicit allowance in script-src — via 'inline-speculation-rules', a hash-source, or a nonce-source — or they silently fail when a Content Security Policy is in place.

What NOT to prefetch or prerender

Both MDN and Chrome’s implementation guide are explicit that some URLs must never be speculated, because a speculative fetch is still a real request that can trigger real side effects. The danger list:

• Sign-out / logout URLs.
• “Add to cart” URLs.
• Language- or currency-switcher URLs.
• Sign-in flows that trigger an SMS/OTP.
• URLs that increment a usage allowance or fire ad-conversion tracking.

The root fix is a design one: state changes — like a /logout action — shouldn’t be plain GET links that a speculation rule could fetch in the first place.

Prerender is stricter still. Additionally unsafe to prerender: pages that modify client-side storage on load, send analytics or ad-impressions on load, or otherwise cause side effects as if the user had interacted. MDN’s framing is that prerendering is riskier than prefetching and should be done sparingly, only where it’s worth it.

Fixing the analytics problem

This is the trap that catches real sites. A prerendered page fully loads before the user ever sees it. If a page_view (or an ad impression, or a Meta Pixel event) fires on load, you’ve logged a visit that didn’t happen — inflating GA4 sessions and corrupting attribution.

The mechanism to fix it is documented in MDN and Chrome’s guides:

• document.prerendering is true while a page is being prerendered.
• The prerenderingchange event fires on activation (when the user actually navigates in).
• Servers can also detect speculative requests via the Sec-Purpose request header (prefetch, or prefetch;prerender).

The practical reality: per Chrome’s implementation guide, some analytics providers (Google Analytics) and ad providers (Google Publisher Tag) already support speculation rules and won’t log a view until the page is activated. GA4’s own gtag.js handles it for you. What typically doesn’t handle it by default: custom GTM tags, Meta Pixel, and homegrown scripts. For tag-manager setups, one clean approach is to delay the tag manager script itself, or gate specific code until the page is activated or made visible. There’s a documented real-world version of getting this wrong — WordPress 6.8 sites reportedly firing GA4 and Meta Pixel ghost visits after the feature auto-enabled; Erwin Hofman covers the fix in depth.

Browser support reality check

This tempers ROI expectations and most articles bury it: the Speculation Rules API is Chromium-only (Chrome and Edge 109+). It is not Baseline. Firefox has a positive standards position on the prefetch portion only and hasn’t shipped it; Safari has an implementation behind a flag, off by default. A meaningful share of any site’s traffic — everyone on Firefox and Safari — gets zero benefit, so size your expectations accordingly.

Speculation Rules in WordPress 6.8+

Because so much of the search audience is on WordPress and got this by default: WordPress 6.8 (March 2025) ships built-in Speculative Loading, on by default for logged-out visitors, using a conservative, prefetch-only configuration out of the box. Site owners can customize the behavior — including opting into prerender for key URLs — via the wp_speculation_rules_configuration filter (Weston Ruter, a Google engineer and WordPress core contributor, has a walkthrough). The default is deliberately safe, which is why most WordPress sites can leave it on — but it’s also why the analytics gotcha above surprised a lot of site owners who never chose to enable anything.

Myths, debunked

• “Speculation Rules will help Googlebot crawl my site faster.” No — it’s a browser-rendering feature for human visitors in Chromium; Googlebot’s own infrastructure doesn’t need hints like this, and no Google doc links the API to crawling.
• “It’s the same as <link rel="prefetch">/<link rel="prerender">.” Not quite — it supersedes the deprecated Chrome-only rel="prerender", adds a richer JSON syntax (document rules, eagerness), and stores speculated resources in the memory cache rather than the HTTP cache.
• “Prerendering everything makes my whole site instant with no downside.” No — Chrome warns against over-prerendering, enforces hard caps, and both Google and Harry Roberts recommend at most one or two prerendered pages.
• “If I add speculation rules my analytics just works.” Only if every analytics and ad script defers via document.prerendering/prerenderingchange. GA4 handles it; many GTM tags and third-party pixels don’t.
• “It’s universally supported, so it’s a safe default for all traffic.” No — Chromium-only, not Baseline; Firefox and Safari don’t ship it by default.
• “Prefetch is risk-free, so I can wildcard it.” Overstated — a wildcard-like match is too greedy, especially for state-changing GET URLs that should never be fetchable links in the first place.
• “This will directly move my rankings.” Not established by any official source as a direct ranking factor. The credible chain is Speculation Rules → better real-user Core Web Vitals / conversion → the existing, modest page-experience signal, plus business wins that matter regardless of rankings.

Where this sits

This is a web performance topic, not a crawling one — and keeping that line clean is the point. It’s a close cousin of resource hints (preload/preconnect/dns-prefetch/prefetch), which share the “browser does network work earlier” idea and the same “doesn’t help Googlebot” caveat; it feeds Core Web Vitals (LCP especially); and it interacts with caching and a CDN since speculated documents populate caches. For the crawler-side analogue of “ask before you re-fetch,” the conditional-requests topic covers how Googlebot avoids re-downloading unchanged pages — a different layer (crawler, not browser), same discipline of separating mechanics from ranking impact.

AI summary

A condensed take on the Advanced version:

• What it is: a Chromium-only (Chrome/Edge 109+) browser API to prefetch (download the HTML document; pays down TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.) or prerender (fully load + run JS in an invisible tab; pays down TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. + FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. + LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) same-site pages before a click. Declared as JSON inline or via a Speculation-Rules header.
• Eagerness (immediate/eager/moderate/conservative) controls when a rule fires, separate from which URLs it targets. Chrome enforces hard caps (50 prefetches / 10 prerenders for immediate rules); the exact triggers are Chrome-version-dependent heuristics, not fixed constants.
• Cross-origin: prerender is same-origin by default; cross-origin same-site prerender needs the target’s opt-in (Supports-Loading-Mode: credentialed-prerender); cross-site prerender isn’t possible at all. Prefetch is more permissive but still gated by a no-destination-cookies privacy rule.
• SEO reality: not a crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor./indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed./ranking mechanism — GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. doesn’t need resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. (per Illyes, Feb 2026, on hints generally) and Google has no Search doc on it. Bing has published nothing. It can move Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.) and conversions for real users — an indirect ranking + UX lever.
• Proof it works: Google Search prefetches its top two results (LCP down ~58–67ms); Ray-Ban reported ~100–156% conversion lifts and a 43% LCP improvement from prerendering PDPs.
• Biggest risk — analytics: a speculated page firing a pageview on load inflates GA4. Fix with document.prerendering / prerenderingchange. GA4 handles it natively; GTM custom tags and Meta Pixel often don’t.
• Never speculate state-changing GET URLs: logout, add-to-cart, currency/lang switchers, OTP sign-in. Redesign those off GET links.
• Adoption order: prefetch broadly, add prerender to one or two pages max, mind CSP ('inline-speculation-rules').
• WordPress 6.8+ ships conservative, prefetch-only speculative loading on by default for logged-out users (wp_speculation_rules_configuration filter to customize).

Official documentation

Primary-source documentation. Note: the search engines publish nothing on this as an SEO topic — the authoritative docs are browser/standards references.

MDN / standards

• Speculation Rules API — the technical reference: syntax, prefetch vs. prerender, privacy, CSP, and browser-compatibility status.
• Speculation-Rules HTTP header — declaring rules via a response header instead of an inline script.

Chrome for Developers (Google)

• Prerender pages in Chrome for instant page navigations — how prerender works, the hint-not-guarantee framing, and Chrome’s FIFO caps.
• Guide to implementing speculation rules for more complex sites — the analytics warning, third-party-script handling, and state-change cautions.
• Improvements to the Speculation Rules API (Barry Pollard, 2024) — document rules, eagerness, No-Vary-Search, HTTP-cache reuse.
• Google Search now uses the Speculation Rules API (Pollard & Busaryev, 2025) — Google’s own usage and the measured LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. deltas.

web.dev (Google)

• How Ray-Ban doubled conversion rate… through prerendering — the business-impact case study.
• Prefetching, prerendering, and precaching — memory cache vs. HTTP cache, and when to be cautious.

WordPress (official feature docs)

• Speculative Loading in 6.8 (Make WordPress Core) — the default behavior and configuration filter.
• Speculative Loading feature plugin — the plugin core adoption was based on.

Quotes from the source

Statements from the primary browser/standards documentation and Google’s own publications. Because this isn’t a search-engine SEO topic, there are no Google Search quotes — the sources are Chrome/MDN/web.dev.

MDN — what it is and does

• “The Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. is designed to improve performance for future navigations. It targets document URLs rather than specific resource files, and so makes sense for multi-page applications (MPAs) rather than single-page applications (SPAs).” Jump to quote

Chrome — Google Search’s own usage (the strongest proof point)

• “One of the first uses of speculation rules was to prefetch the first two search results.” — Chrome for Developers blog. Jump to quote
• On Android Chrome, LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. for clicks from Google Search was “reduced by 67 milliseconds.” Jump to quote
• On desktop, a “similar improvement in LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. of 58.6 milliseconds.” Jump to quote

Speculation Rules cheat sheet

Prefetch vs. prerender

Eagerness — when a rule fires (independent of which URLs)

Chrome’s hard caps (regardless of your config)

• immediate rules: 50 prefetches / 10 prerenders.
• Interaction-based (moderate/conservative) rules: 2 FIFO slots.

Cross-origin quick reference

• Prerender: same-origin by default; cross-origin same-site needs the target to send Supports-Loading-Mode: credentialed-prerender; cross-site prerender isn’t possible.
• Prefetch: same-site and cross-site both work, gated by the no-destination-cookies privacy rule.

Fast facts

• Support: Chromium-only (Chrome/Edge 109+). Not Baseline. Firefox = prefetch standards position only (unshipped); Safari = behind a flag, off by default.
• Declared as JSON: inline <script type="speculationrules"> or a Speculation-Rules HTTP header.
• CSP: inline blocks need 'inline-speculation-rules' (or hash/nonce) in script-src.
• Detect a speculative load: document.prerendering, the prerenderingchange event, or the Sec-Purpose request header.
• Not a Google ranking/crawl signal. Google Search uses it (top-2 results, ~58–67ms LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.). WordPress 6.8+ = conservative, prefetch-only, logged-out, on by default.

What not to do

Speculating state-changing GET URLs. A speculative fetch is a real request. Never prefetch or prerender logout, add-to-cart, currency/language switchers, OTP-triggering sign-in flows, or allowance-incrementing URLs. The real fix is design: those actions shouldn’t be plain GET links a rule could fetch. This is documented in both MDN and Chrome’s implementation guide.

PrerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. broadly or with a wildcard. Chrome caps it and warns against over-prerendering at a cost of user resources; Harry Roberts calls a wildcard-like match too greedy. Keep prerenders to one or two high-confidence pages.

Assuming your analytics is fine. If a prerendered page fires a pageview on load, you’ll inflate GA4 with visits that never happened. GA4’s gtag.js handles this — but GTM custom tags, Meta Pixel, and homegrown scripts often don’t. WordPress 6.8 sites reportedly logged GA4/Meta ghost visits after the feature auto-enabled. Gate tracking on document.prerendering / prerenderingchange.

Forgetting your CSP. An inline <script type="speculationrules"> silently fails under a Content Security Policy unless script-src allows 'inline-speculation-rules' (or a hash/nonce).

Expecting it to help crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. or rankings. It doesn’t touch GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.. Selling this internally as an “SEO fix for crawl budgetThe number of URLs an engine will crawl in a timeframe. or rankings” sets the wrong expectation — pitch it as a Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. / conversion win for real Chromium visitors.

Over-estimating reach. It’s Chromium-only. Firefox and Safari users get nothing by default, so don’t model ROI as if it applies to all traffic.

Worked examples

Minimal, illustrative rule blocks. Adapt targeting to your own site and always exclude state-changing URLs.

1. Prefetch two explicit URLs (safest starting point)

<script type="speculationrules">
{
  "prefetch": [
    { "urls": ["/pricing/", "/features/"] }
  ]
}
</script>

2. Document rules — prefetch same-site linksSitelinks are extra links from the same domain that Google clusters together under a single search result, usually for branded or navigational queries. They're generated entirely algorithmically — there's no way to add, edit, or guarantee them. on hover (moderate)

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

3. Prerender one high-confidence page, excluding dangerous paths

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout*" } },
          { "not": { "href_matches": "/cart*" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

4. Deliver rules via HTTP header instead of an inline script

Speculation-Rules: "/speculation-rules.json"

…where /speculation-rules.json returns the same JSON with a application/speculationrules+json content type. Useful when a strict CSP makes inline scripts painful.

5. Guard analytics against firing during prerender

if (document.prerendering) {
  document.addEventListener('prerenderingchange', sendPageview, { once: true });
} else {
  sendPageview();
}

This defers the pageview until the page is actually activated — the same pattern GA4’s own script uses.

Analytics jumped after prerender shipped

1. Pause the prerender rule, not the whole performance program. Keep a copy of the deployed rule and switch the affected path back to prefetch or no speculation. If the unexplained traffic stops, continue with the prerender investigation.
2. Separate activation from background load. Reproduce in Chromium and inspect document.prerendering before navigation. If analytics fires while it is true, the tag records a page the visitor has not activated.
3. Identify the firing owner. Check GA4, custom GTM tags, ad pixels, and homegrown events independently. If only one source inflates, fix that integration rather than weakening every rule.
4. Gate the event. Delay the pageview or impression until prerenderingchange/activation. If the provider already supports prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., remove duplicate custom firing logic.
5. Replay the abandoned-navigation case. Trigger a prerender but do not click. The event must remain absent. Then activate the page once and confirm exactly one event is recorded.
6. Restore narrowly. Re-enable one high-confidence prerender target, compare activated navigations with analytics events, and expand only when counts remain aligned.

Review a rule set for side effects

Review this Speculation Rules JSON and a list of site routes. Classify every matched
route as safe to prefetch, safe to prerender, or exclude. Explicitly flag logout,
add-to-cart, language/currency switching, OTP, allowance-changing, analytics, storage,
and ad-impression side effects. Check eagerness, scope, and likely resource waste.
Return the smallest safe rule set plus validation and rollback tests. Do not claim a
crawling, indexing, or direct ranking benefit.

Design a staged rollout

Create a staged Speculation Rules rollout for this click-path data and browser mix.
Start with prefetch, choose at most one or two high-confidence prerender targets, and
explain why each route is likely enough to justify its cost. Include Chromium-only
segmentation, analytics activation handling, CSP checks, success metrics, an abandoned
navigation test, and rollback triggers. Do not invent conversion or performance gains.

Debug missing speculation

Given this page markup, response headers, CSP, browser version, and DevTools evidence,
diagnose why a speculation rule was not used. Check invalid JSON, CSP blocking,
unsupported browser, rule mismatch, resource limits, cross-origin restrictions, and
browser discretion. Return symptom, evidence, likely cause, smallest fix, and the
exact evidence that would confirm it.

Safe speculation release checklist

• Browser-support data justifies a Chromium-only progressive enhancement.
• Initial rollout uses prefetch; prerender is limited to one or two high-confidence destinations.
• Logout, cart mutation, login/OTP, language/currency, allowance-changing, and other state-changing GET routes are excluded.
• Prerendered pages do not mutate storage or fire impressions before activation.
• Session-storage-dependent logic is tested both before and after prerenderingchange (a prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. page starts with a storage clone that’s discarded at activation).
• Any cross-origin prerender target sends Supports-Loading-Mode: credentialed-prerender; cross-site prerender isn’t attempted at all.
• Custom analytics and pixels check document.prerendering and wait for prerenderingchange when necessary.
• CSP permits the inline or external speculation-rules delivery method.
• Targeting and eagerness come from observed navigation behavior, not a wildcard guess.
• DevTools confirms the rule is valid, eligible, and used only for intended URLs.
• An abandoned speculative load records no pageview, conversion, or state change.
• Safari and Firefox still receive a fully functional normal navigation.
• Performance and business outcomes are measured on activated navigations, with wasted speculation tracked separately.

Activation and analytics integrity

Test to run: Trigger a prerender without clicking, then repeat and activate the page once while observing analytics and custom pixel requests.

Expected result: The abandoned prerender records no pageview or impression; the activated navigation records exactly one.

Failure interpretation: A tag fires on background load or duplicate activation logic records the same visit twice.

Monitoring window: Test before release, immediately after release, and after tag manager or analytics-library changes.

Rollback trigger: Disable prerender for the affected route if speculative loads inflate sessions, impressions, conversions, or attribution.

Navigation performance and waste

Test to run: Compare matched activated navigations with and without the rule, and count speculations that are never activated.

Expected result: Targeted Chromium navigations show earlier document/paint timing without an unacceptable volume of unused work or current-page regressions.

Failure interpretation: The prediction is weak, eagerness is too aggressive, or background work competes with the current page.

Monitoring window: Review during a limited rollout across representative devices and connection classes before expanding scope.

Rollback trigger: Step back from prerender to prefetch, or remove the rule, if unused requests or regressions outweigh the measured activated-navigation benefit.

Side-effect exclusion

Test to run: Exercise every matched route without activation and inspect server state, authentication, cart contents, messaging, and usage counters.

Expected result: No speculative request changes user or server state.

Failure interpretation: A state-changing GET route was matched or a page executes side effects during background load.

Monitoring window: Re-run when routes, document-rule selectors, or application side effects change.

Rollback trigger: Remove the match immediately if a speculative request logs out a user, changes a cart, sends a message, consumes an allowance, or records a conversion.

Speculative-navigation scorecard

Metric: Activated-navigation performance for eligible Chromium users, paired with speculation activation rate and analytics-event accuracy.

What it tells you: Whether prediction makes real next-page navigations faster, how often prefetched/prerendered work is actually used, and whether measurement stays trustworthy.

How to pull it: Segment real-user navigation and paint timings by browser and rule exposure; log speculation candidates and activations; compare activated pageviews with analytics events. Keep prefetch and prerender cohorts separate.

Benchmark or realistic range: Use the site’s own pre-release distribution and a controlled holdout. There is no honest universal activation-rate or conversion target; browser mix, path predictability, page weight, and intent differ by site.

Cadence: Watch resource use and analytics integrity during rollout, review performance and activation weekly while tuning rules, and re-audit after navigation, tagging, CSP, or browser-support changes.

Resources worth your time

My related writing

• The Beginner’s Guide to Technical SEO — where page-experience and performance topics like this fit in the bigger picture.
• Core Web Vitals: What They Are and How to Improve Them — the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./INP metricsInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. that Speculation Rules actually moves for real users. (Note: I don’t yet have a dedicated Ahrefs guide specifically on the Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. — this piece is the deep dive; the links here are my closest adjacent coverage.)

My speaking

• What’s Next for Page Experience — SMX Next 2021 (SlideShare) — my page-experience talk that flagged early-loading techniques (a “Get Things Earlier” slide linking to the then-experimental speculative prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.), which predates the modern Speculation Rules API but points at the same idea.
• How Search Works (SlideShare) — crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking, useful for keeping the browser layer separate from the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. layer. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Google Search now uses the Speculation Rules API (Chrome for Developers) — Google’s own usage, with the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. millisecond deltas.
• How Ray-Ban doubled conversion rate… through prerendering (web.dev) — the best business-impact case study on prerendering.
• A Layered Approach to Speculation Rules (Harry Roberts, CSS Wizardry) — the strongest independent-expert implementation write-up, including the “prefetch for TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., prerender for LCP” model.
• Google Explains Why Its Crawler Ignores Your Resource Hints (Search Engine Journal) — Illyes’ Feb 2026 comments on why GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. doesn’t benefit from resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. (general, not Speculation-Rules-specific).
• Google Search now uses Speculation Rules API to make search faster (Search Engine Land) — trade-press corroboration of the Chrome announcement.
• Prevent skewed analytics when using Speculation Rules (Erwin Hofman) — an in-depth fix for the GA4 contamination problem.
• Eagerly Prerender Key URLs with Speculative Loading in WordPress (Weston Ruter, Google/WordPress core) — how to customize WordPress 6.8’s default via the wp_speculation_rules_configuration filter.
• Blazing Fast Websites with Speculation Rules (DebugBear) — a performance-tool vendor’s practical walkthrough.

Test yourself: Speculation Rules

Five quick questions on what the Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. does — and doesn’t — do. Pick an answer for each, then check.

Speculation Rules API

The Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal.

Related: Resource Hints, Core Web Vitals

Speculation Rules API

The Speculation Rules API is a browser API — Chromium only (Chrome and Edge 109+) — that lets a site tell the browser which same-site pages to prefetch or prerender before the user clicks a link. When the visitor does navigate, the browser “activates” the already-prepared page instead of starting the request from scratch, so the next page can load near-instantly.

Rules are declared as JSON, either inline in a <script type="speculationrules"> block or via a Speculation-Rules HTTP response header. They can target explicit URL lists or use a where/href_matches condition (document rules) to auto-apply across matching links. It supersedes the old, Chrome-only <link rel="prerender"> and goes beyond <link rel="prefetch"> with a more expressive syntax, eagerness levels, and storage in the browser’s in-memory cache.

The key distinction between the two actions:

• Prefetch downloads only the referenced page’s HTML document (not its subresources) — it pays down the next page’s TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good..
• Prerender fetches, renders, and runs all the JavaScript for the page in an invisible background tab — it pays down TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., but is riskier and more resource-intensive.

For SEO, this is a browser-performance lever, not a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. one. GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. doesn’t need or use resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. like this, and there is no Google Search documentation tying the Speculation Rules API to crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. or indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. What it can do is improve Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (especially LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) and engagement for real visitors in Chromium browsers — an indirect ranking pathway through page experience, plus a direct UX and conversion win. The main risk to manage is analytics: a speculated page that fires a pageview on load, before the user sees it, will inflate GA4 sessions unless the tracking code checks document.prerendering.

Related: Resource Hints, Core Web Vitals

Changelog