What Happens to Your Core Web Vitals When the Page Loads Before the Click.

Across sites monitored by the RUM platform CoreDash, prerendered navigations show a p75 LCP of 320ms against 1,800ms for standard navigations on the same sites. That is an 82 percent gap produced by a single browser API, with no image work, no CSS surgery, and no server migration behind it. Google clearly believes in the mechanism, because Google Search itself adopted the Speculation Rules API in February 2025 to prefetch the top results before you click them.

The web performance community has written plenty about how the API works. What barely exists is guidance for SEO teams, who care about a different set of questions. Which URL patterns deserve prerendering, what happens to CrUX field data and the Core Web Vitals report in Search Console after deployment, and whether any of this touches crawling. This guide answers those three questions, because the answers turn speculation rules from a developer curiosity into one of the cheapest Core Web Vitals wins available right now.

The Fastest LCP Fix You Can Ship Is a JSON Block

The Speculation Rules API lets you declare, in a JSON block inside a <script type="speculationrules"> tag or via an HTTP header, which links the browser should load before the user clicks them. It supports two levels of aggression. Prefetch downloads the HTML of the target page into memory, which mostly collapses TTFB, while prerender fetches the HTML plus every subresource and renders the whole page in a hidden tab, so activation on click is close to instant. Prerender support shipped in Chrome 109, and the flexible document-rule syntax with eagerness controls landed in Chrome 121, which means the modern version of the API now covers Chrome, Edge, and every Chromium-based browser, roughly 79 percent of global traffic.

Adoption stopped being experimental a while ago. WordPress has shipped speculative loading in core since version 6.8, Cloudflare's Speed Brain feature adds speculation rules across its plans by default, and Shopify rolled out conservative prefetch platform-wide in June 2025. When the web's most-used CMS, the largest CDN, and the largest ecommerce platform all turn the same feature on by default, the sites competing with you in the SERPs are already benefiting from it whether their SEO teams know it or not.

Why Your Field Data Moves When Lab Scores Do Not

The Core Web Vitals report in Search Console is built on CrUX, the field data Chrome collects from real users, and this is where speculation rules behave differently from almost every other performance fix. When a user navigates to a prerendered page, LCP is measured from activation, the moment the user actually clicks, not from when the hidden render started. The page was already painted before the click, so the recorded LCP collapses to a fraction of a cold load. Every one of those near-zero navigations flows into your CrUX distribution and pulls the p75 down, which is the exact number Search Console grades you on. Lighthouse will never show you this, because lab tests always load pages cold.

The field results back this up at every scale. Ray-Ban prerendered its product listing pages and cut mobile LCP from 4.69 seconds to 2.66 seconds, alongside a 101 percent lift in mobile conversion. Italian publisher Monrif improved LCP by up to 17.9 percent by prerendering its most-visited article paths. Even the WordPress data, which reflects the most cautious default configuration possible, shows sites that enabled speculative loading improving their LCP passing rate by around 1.9 percent at the median. The WordPress default is deliberately timid, so the bigger numbers come from aiming prerender at the templates where user intent concentrates, and deciding which templates those are is SEO work.

Which URL Patterns to Prerender

Picking targets is a probability exercise. Prerender is expensive for the browser and your server, so it belongs on the small set of next pages a user is most likely to open, while prefetch can cover the broader link graph cheaply. On an ecommerce site the high-probability hops are category page to product page and product page to the next paginated page. On a publisher, it is article to next article in the series. On a lead-gen site like ours, it is service page to pricing or contact. Your analytics already name these paths, and the top two or three exit links from a template usually capture most of the clicks. Sites we audit almost never have this deployed, including ones that spent two quarters squeezing a few hundred milliseconds of LCP out of image pipelines, so the field is still wide open.

Just as important is what to exclude. Any URL that mutates state has no business being speculatively loaded, so cart, checkout, login, logout, and account paths go on the exclusion list, along with parameterized URLs that explode into infinite variants and links you have marked nofollow. A production-ready rule set for an ecommerce template looks like this.

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "href_matches": "/products/*" },
        { "not": { "href_matches": "/*\\?*" } },
        { "not": { "selector_matches": "a[rel~=nofollow]" } }
      ]
    },
    "eagerness": "moderate"
  }],
  "prefetch": [{
    "source": "document",
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": { "href_matches": ["/cart*", "/checkout*", "/account*", "/*\\?*"] } }
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

The where document rules match links already present on the page, so the browser does the targeting work for you. Prerender is reserved for the product template where purchase intent lives, prefetch covers everything else, and the exclusions keep speculative traffic away from anything transactional.

Eagerness Decides Your Server Bill

The eagerness field controls when the browser starts speculating, and it is the setting that separates a measured rollout from a bandwidth incident. Chrome pairs each level with hard limits on concurrent speculations precisely because over-speculation wastes user data and origin capacity.

Moderate is the right default for almost every SEO deployment. A 200ms hover is a strong signal of intent, so hit rates stay high while waste stays low, and the two-slot FIFO limit means a user wandering across your nav cannot queue up dozens of renders. CoreDash data shows sites on moderate eagerness get roughly 28 percent of navigations served from a speculation, which is plenty to move a p75. Chrome also protects users automatically, disabling all speculation under Save Data mode, low battery, or when the user has turned page preloading off, so the downside on constrained devices is already handled for you.

Measuring the Win After Deployment

The proof arrives in two places. In your RUM tooling, PerformanceNavigationTiming.activationStart is non-zero for prerendered navigations, so you can segment speculated pageviews against standard ones and watch the two LCP distributions diverge. In CrUX, the navigation types dimension reports what share of your navigations are prerender, available through the CrUX History API and BigQuery, and that share climbing is your leading indicator. During rollout, DevTools confirms everything locally under Application, then Speculative loads, which lists each speculation and why it succeeded or failed.

Search Console is the lagging indicator, and you should set that expectation with stakeholders before you ship. The Core Web Vitals report aggregates CrUX over a rolling 28-day window, so a deployment today shows its full effect roughly a month later, and only on the URL groups where speculated navigations make up a meaningful share of traffic. One measurement trap can bite here. Prerendered pages execute JavaScript before the user ever arrives, so analytics can fire phantom pageviews. GA4 already defers correctly, but any other tracking should be wrapped in a document.prerendering check that waits for the prerenderingchange event, otherwise your engagement data degrades at the same moment your speed data improves.

What Search Crawlers Do With Your Speculation Rules

Nothing, and that is the useful part. Google's crawler fetches resources on its own schedule from its own cache, and Gary Illyes has explained that resource hints are irrelevant to Google's crawling infrastructure. Googlebot does not parse your speculation rules, does not trigger prefetches or prerenders, and your crawl budget is untouched in either direction. The same holds for Bingbot and the AI crawlers, none of which execute speculative loads. The user-side benefit reaches past Chrome, though, because Edge ships the same engine, so faster navigations feed Bing's page experience signals just as they feed CrUX, and Bing's index carries extra weight now that it grounds ChatGPT's web answers.

Real users are a different story, and your server logs will show it. Every speculative load is a genuine request to your origin, marked with a Sec-Purpose: prefetch header, while prerenders announce themselves with Sec-Purpose: prefetch;prerender. If your team runs log-file analysis for crawl-budget work, filter those requests out before drawing conclusions, because a moderate-eagerness deployment on a busy site adds a visible stream of user-agent requests that look like page hits and are not. The same header lets you make the speculative requests cheap, since your CDN can serve them from edge cache and your servers can skip expensive personalization work until the real navigation happens.

When Speculation Rules Are the Wrong Tool

Not every site should ship this, and the biggest limitation hides in how your traffic arrives. Speculation rules only accelerate navigations that start on your own pages, so the first pageview of a session still loads cold unless the referrer prefetches it for you the way Google Search does. A site where most sessions are single-page visits from the SERP will see its CrUX numbers barely move, because the speculated share of total navigations stays small no matter how good the rules are. Check the entry-page share in your analytics before promising anyone a Core Web Vitals turnaround, and put the effort into classic LCP work instead if internal navigation is thin.

Architecture and state cause the other failures. Single-page applications handle route changes in JavaScript rather than document navigations, so the API has nothing to intercept beyond the initial load. Pages that render per-user state, like cart badges, stock counters, or logged-in dashboards, can prerender stale content that the user then watches flash and correct itself. If your pages fire A/B test assignments or consent-gated tags on load, a prerender that never activates has still consumed a variant slot unless the tooling is prerender-aware. None of these kill the case for the API, but they decide which templates go on the exclusion list on day one.

Where This Fits in Your Next Sprint

The sequence that works is small and boring. Pick one template with clear next-click behavior, ship prefetch at moderate eagerness with the transactional exclusions in place, and verify in DevTools that speculations succeed. After two weeks of clean RUM data, promote the highest-intent link pattern to prerender, then let the 28-day CrUX window roll over and read the result in Search Console. Most teams see the navigation-type share move within days and the p75 follow within the window.