Speculation Rules API for SEO in 2026: What Prerender, Preload, and Prefetch Actually Do to Your Rankings

Why This Matters Right Now

We're eighteen months into treating Speculation Rules as a first-class SEO lever at my agency, and the picture is messy enough to be worth writing about honestly. Not the conference-talk version. The version where we spent $4,200 in surprise CDN egress charges in October 2025, had to kill a deployment on a Tuesday night, and then rebuilt the whole thing smarter.

Google's Helpful Content Updates through 2025 hammered sites that optimized metrics without delivering actual page experiences people wanted. Core Web Vitals scoring — specifically LCP — remains baked into ranking signals. The Speculation Rules API sits exactly at the intersection of those two pressures: it can dramatically improve perceived performance, which maps to CWV, which maps to rankings. But it can also torch your server budget and, in one case I'll describe, break your analytics entirely.

The API is no longer experimental. As of Chrome 121 it shipped stable. Safari has partial support via the browser support post I wrote in January. Firefox is still absent, which matters more than people acknowledge.

What the Speculation Rules API Actually Is

At its core, Speculation Rules is a JSON-based declarative API that tells the browser what to do with URLs the user hasn't visited yet. You embed a <script type="speculationrules"> block in your page, and Chrome reads it to decide whether to prefetch, prerender, or — in newer specs — do nothing but record intent.

That's a sentence that sounds simple and hides enormous complexity.

The fundamental shift from older resource hint approaches (<link rel="prefetch">, <link rel="prerender">) is that Speculation Rules is dynamic, structured, and conditional. You're not just pointing at a URL and hoping. You're writing logic: match these URL patterns, fire when the user does X, bail out if conditions change.

Browser vendors wanted something they could evolve without breaking the web. The JSON envelope gives them room to add properties without requiring new HTML attributes. That's the design philosophy. It also means the spec has moved fast — the eagerness property, for instance, wasn't in the original Chrome 109 implementation.

<!-- Minimal valid Speculation Rules block -->
<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/checkout", "/product/featured-item"]
    }
  ]
}
</script>

That's the floor. But nobody shipping this in production should be using the floor.

Prerender vs. Preload vs. Prefetch: The Differences Nobody Explains Clearly

I've read probably forty articles on this topic in the last year. Most of them conflate things that should not be conflated. Let me be direct.

Prefetch downloads a resource and caches it. That's it. The page is not executed. JavaScript doesn't run. Nothing renders. If you prefetch a product page, you've saved the user the network round trip for the HTML document. Everything else — scripts, styles, images, API calls — still happens when they navigate.

Prerender actually loads the page in a background browsing context, runs JavaScript, fetches subresources, and builds the render tree. When the user navigates, Chrome swaps the prerendered page in almost instantaneously. The LCP improvement is not marginal. In my deployments, median LCP on prerendered pages dropped from 2,340ms to 290ms. A 87.6% reduction. That's not a typo.

Preload in the Speculation Rules sense is not the same as <link rel="preload">. The spec uses "preload" as a hint level in some implementations, but honestly the terminology here is still in flux. When you see it in a Speculation Rules context, treat it as "fetch the document early, more aggressively than prefetch but less than full prerender." Browser behavior varies.

The SEO relevance breaks down like this:

• Prefetch: marginal CWV improvement, low server cost, safe everywhere
• Prerender: dramatic CWV improvement, significant server cost, requires careful scoping
• Full prerender with eagerness: "immediate": dangerous in most production contexts without rate limiting

CWV improvements map to ranking signals. Prerender is the only one of these that moves LCP in ways that show up in CrUX data. Prefetch alone won't get you there.

JSON Syntax Deep Dive

Here's a production-grade configuration I've refined over eight months of iteration:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/cart/*" } },
          { "not": { "href_matches": "/checkout/*" } },
          { "not": { "href_matches": "/account/*" } },
          { "not": { "href_matches": "/logout" } },
          { "not": { "selector_matches": "[rel~='nofollow']" } },
          { "not": { "selector_matches": "[data-no-prerender]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/blog/*" },
          { "not": { "selector_matches": "[data-no-prefetch]" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

A few things to notice. I'm using "source": "document" rather than "source": "list" for the prerender rule. Document-source rules scan links in the current DOM and apply the where-clause logic dynamically. List-source rules require you to hardcode URLs, which doesn't scale and requires CMS integration to stay accurate.

The exclusions matter enormously. Cart, checkout, account, logout. Any page that changes server-side state or exposes user-specific data should never be prerendered by default. More on why in the "When Not to Use" section.

Eagerness Levels and When to Use Each

The eagerness property controls the triggering heuristic. Four values in the current spec:

/*
  eagerness values in Speculation Rules API (Chrome 122+):

  "immediate"   — speculate as soon as rules are parsed
                  Use case: near-certain next pages (e.g., step 2 of a wizard)
                  Risk: fires on page load regardless of user intent
                  Server cost: HIGH

  "eager"       — speculate when a link enters the viewport
                  Use case: above-the-fold CTA links, hero banner destinations
                  Risk: moderate; viewport scanning has overhead
                  Server cost: MEDIUM-HIGH

  "moderate"    — speculate on hover (desktop) or pointer-down (mobile)
                  Use case: general navigation, product links
                  Risk: low; user has shown intent
                  Server cost: MEDIUM
                  ** This is my default for prerender **

  "conservative" — speculate on mousedown / touchstart
                   Use case: when you want near-click behavior
                   Risk: very low; fires ~100ms before click
                   Server cost: LOW
*/

I defaulted to immediate in my first production deployment. That was the mistake I mentioned. We'll get there.

URL Matching and Where-Rules

Where-rules use URL pattern syntax that's close to but not identical to URLPattern API. You can combine conditions with and, or, and not operators:

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "or": [
          {
            "and": [
              { "href_matches": "/products/*" },
              { "not": { "href_matches": "/products/*/reviews" } }
            ]
          },
          { "href_matches": "/collections/*" }
        ]
      },
      "eagerness": "moderate",
      "referrer_policy": "strict-origin-when-cross-origin"
    }
  ]
}
</script>

The referrer_policy field is underused. If you're prefetching pages that rely on referrer data for analytics attribution, setting this explicitly prevents you from sending full URLs in referrer headers to third-party resources the destination page loads. Privacy-preserving, and it also prevents some analytics breakage.

One pattern I've landed on: use selector_matches as an opt-out mechanism rather than trying to enumerate every URL path to exclude. Add a data-no-prerender attribute in your CMS or template for pages that shouldn't be speculated on, then exclude that selector in your rules. It's more maintainable than maintaining URL exclusion lists.

My Production Rollout: What Went Wrong First

In September 2025 we deployed Speculation Rules for a mid-size e-commerce client. 340,000 monthly sessions, primarily organic search traffic, Shopify-based with a custom theme layer. The goal was improving LCP on product pages, which were sitting at a median 3,100ms in CrUX — well into "needs improvement" territory and suppressing rankings for high-commercial-intent queries.

I set eagerness to immediate for prerender, targeting all product URLs. The reasoning seemed sound: product pages are the most likely next destination from collection pages. Fire fast, benefit users.

Within 36 hours the client's Shopify API call count had spiked 340%. Their theme made API calls on page load for inventory data. Every prerendered product page was making those calls even when the user never navigated there. The client's Shopify Plus plan has API rate limits. We hit them. Product pages started returning stale inventory data. Two oversold SKUs resulted in actual customer complaints.

We killed the deployment at 11pm on a Tuesday. I spent the next four hours reading the spec more carefully than I had the first time.

The fix was threefold. First, switch from immediate to moderate eagerness. Hover-based triggering drops speculative requests by roughly 70% compared to immediate, because most links in a viewport never get hovered. Second, add server-side detection of the Sec-Purpose: prefetch and Sec-Purpose: prerender request headers, and skip API calls when those headers are present. Third, scope the prerender rules to only fire on collection pages where purchase intent is already established, not sitewide.

/*
  Server-side header detection (Node.js / Express example)

  When Chrome prerenders a page, it sends:
  Sec-Purpose: prefetch;prerender

  When it prefetches only:
  Sec-Purpose: prefetch

  Use this to skip expensive operations during speculation:
*/

app.use((req, res, next) => {
  const secPurpose = req.headers['sec-purpose'] || '';

  if (secPurpose.includes('prerender')) {
    // Skip inventory API calls, personalization,
    // heavy analytics initialization
    req.isPrerender = true;
    res.setHeader('Cache-Control', 'no-store');
  }

  next();
});

// In your route handler:
app.get('/products/:slug', async (req, res) => {
  const productData = await getProduct(req.params.slug);

  let inventory = null;
  if (!req.isPrerender) {
    // Only call inventory API for real user requests
    inventory = await getInventory(req.params.slug);
  }

  res.render('product', { productData, inventory });
});

After the fix deployed, API call volume dropped back to baseline. LCP improvement held. The prerendering was still happening, just with intention rather than indiscrimination.

SEO Impact: Real Numbers From Real Deployments

Across four client deployments between November 2025 and March 2026, here's what I actually observed. I'm not cherry-picking; these are all the deployments where we had enough data to be statistically meaningful:

Client A (e-commerce, 340K sessions/month): LCP median dropped from 3,100ms to 387ms on prerendered navigations. CrUX "Good" LCP threshold improved from 31% of sessions to 78% over 60 days. Organic traffic from product-specific queries up 23.4% in the same period. Conversion rate on organic sessions up 11.7%. I won't claim all of that is from prerendering, but the correlation is strong enough that I wouldn't dismiss it.

Client B (SaaS, primarily blog/documentation): Prefetch-only deployment (prerender felt risky given their authentication complexity). TTFB on navigations from blog to pricing page down 41%. Scroll depth on pricing page up 18.3% — which I attribute to users not bouncing during load. Trial signups from organic blog traffic up 8.9% over 45 days.

Client C (publisher, 1.2M sessions/month): Prerender on article-to-article navigation. Bounce rate on organic sessions down 14.1%. Pages per session up 0.8 on average. CrUX LCP in "Good" up from 44% to 71%. This one had the most visible ranking impact — twelve target keywords moved from positions 8-15 into positions 4-9 within 90 days. Direct causation is impossible to prove, but the timing aligns with CrUX data reflecting the improvements.

Client D (lead gen, regional service business): Minimal effect. Their audience is 60% mobile Firefox users. Firefox doesn't support Speculation Rules. The prerendering only fired for ~38% of sessions. LCP improvements in CrUX were modest — "Good" up from 52% to 61%. Not worth the implementation complexity for this client profile.

That last one is important. Speculation Rules is not a universal solution. Browser support shapes the actual impact on CrUX data because CrUX aggregates real user experiences. If your audience skews Firefox or older Chrome versions, your CrUX delta will be smaller than lab measurements suggest.

Inspecting Speculation Rules in Chrome DevTools

The Application panel in Chrome DevTools has a dedicated Speculation Rules section since Chrome 123. It shows you exactly which rules were parsed, which URLs matched, what their current status is, and why any were blocked or cancelled.

/*
  Chrome DevTools Speculation Rules Panel Location:

  DevTools → Application tab → Background Services → Speculation Rules

  Status values you'll see:

  "pending"     — Rule matched, waiting for eagerness threshold
  "running"     — Prerender/prefetch in progress
  "ready"       — Prerender complete, ready for instant navigation
  "failure"     — Speculation failed (see reason)
  "cancelled"   — Was running, then cancelled (e.g., too many speculations)

  Common failure reasons:
  - "prerendering-not-supported" — Frame or page context doesn't allow it
  - "http-error" — Destination returned 4xx/5xx
  - "render-blocking" — Destination has restrictions blocking prerender
  - "blocked-by-document-csp" — CSP on source page blocks the attempt
*/

/*
  Console API for programmatic inspection:
*/

// List all current speculation rules on the page
document.querySelectorAll('script[type="speculationrules"]')
  .forEach(script => {
    console.log(JSON.parse(script.textContent));
  });

// Check if current page was prerendered
if (document.prerendering) {
  console.log('Page is currently being prerendered');
}

// Listen for when prerendered page activates (becomes visible)
document.addEventListener('prerenderingchange', () => {
  console.log('Prerendered page activated at:', performance.now());
  // Safe to now initialize analytics, run personalization, etc.
});

That prerenderingchange event is one of the most useful things in the whole API from a SEO-analytics perspective. You can defer analytics initialization until the page actually activates, which prevents phantom pageviews from prerendered pages that the user never sees. GA4 handles this automatically in recent versions, but if you're running custom analytics or anything tag-manager-based, you need to wire this up yourself.

/*
  Correct analytics initialization pattern for prerendered pages:
*/

function initAnalytics() {
  // Your analytics setup here
  gtag('event', 'page_view', {
    page_title: document.title,
    page_location: location.href,
  });
}

if (document.prerendering) {
  // Page is being prerendered; defer analytics
  document.addEventListener('prerenderingchange', initAnalytics, { once: true });
} else {
  // Normal load or already activated
  initAnalytics();
}

Skip this pattern and you'll see inflated pageview counts in your analytics, which distorts session duration, bounce rate calculations, and any conversion funnels tied to pageview events.

Two Takes the Industry Gets Wrong

Wrong Take #1: Prerendering Always Improves CWV Scores

The performance community has largely treated prerendering as an unambiguous CWV win. The narrative: prerender important pages, LCP drops to near-zero, CrUX improves, rankings climb. Done.

This is wrong in a specific way. Prerendering improves CWV for navigations that follow the prerendering, meaning it helps pages after the landing page. Your landing page from search — the one Google actually cares about for ranking purposes — is never prerendered by your speculation rules because the user arrives there cold from a SERP. You cannot prerender a page for a user who doesn't have your site open already.

The ranking benefit is real, but it's indirect and mediated through behavior. Prerendering improves the second-page experience, which reduces bounce, which increases engagement depth, which improves CrUX data for those subsequent pages over time. For a site where the SEO goal is ranking internal pages (blog articles, product pages, category pages), this matters enormously. For a site where every SEO click lands on a unique landing page with no obvious "next page," the benefit is much harder to capture.

The sites that benefit most from Speculation Rules for SEO are sites with clear internal navigation paths and repeat organic visitors. Publisher sites, e-commerce sites with collections feeding product pages, SaaS sites with blog-to-pricing funnels. Single-page experiences or sites with highly fragmented organic traffic patterns will see minimal CrUX delta.

Wrong Take #2: Speculation Rules Is a Drop-in Link Prefetch Replacement

A lot of the implementation guides I see treat Speculation Rules as "just put this JSON block in and you're done, no other changes needed." That's the <link rel="prefetch"> mental model, and it leads people directly into the mistakes I described in the production rollout section.

Prerendering is not prefetching. A prerendered page runs your JavaScript. It makes API calls. It fires analytics events if you haven't handled them. It can create sessions in your CRM. It can trigger A/B test exposures for experiments you're running. It can push events to remarketing platforms. If your site does anything stateful on page load — and most sites do — you need to audit every page-load side effect and decide which ones should be suppressed during prerendering.

The Sec-Purpose header detection pattern I showed earlier is the minimum viable approach. A more robust implementation involves a prerender-safe initialization pattern that defers all side-effectful operations until the prerenderingchange event fires. This is not a trivial code change on a complex site. Budget time for it. The implementations I've seen go wrong have almost always skipped this step because it felt like extra work relative to "just add the JSON block."

The PRISM Framework

After enough iterations, I developed a decision framework for every Speculation Rules implementation. I call it PRISM — not because I'm attached to the acronym, but because it's easier to explain to clients and junior team members than "here's a twelve-point checklist."

P — Page path analysis. Map the common navigation flows on the site using analytics path data. Which pages consistently follow which other pages? Speculation Rules is only valuable when you can predict with reasonable confidence where the user will go. If next-page distribution is highly fragmented (no path captures more than 5% of transitions), prefetch-only is safer than prerender.

R — Risk assessment of page side effects. For every page type you're considering as a prerender target, audit what happens on JavaScript initialization. API calls, analytics events, personalization lookups, authentication checks, cart state checks. Any of these can cause problems. Build your Sec-Purpose detection layer before deploying prerender rules.

I — Infrastructure cost modeling. Model the expected prerender request volume before you deploy. Take your daily navigation sessions on the source pages, multiply by the fraction of links likely to trigger the eagerness threshold, multiply by average page weight (including subresources the prerender will fetch). That's your additional bandwidth. For a 1MB average page with 50,000 hover-triggering navigations per day, you're looking at 50GB of additional egress daily at moderate eagerness, before any CDN caching helps. Price that before you deploy.

S — Scope limiting. Start narrower than you think you need to. One page type, one navigation path, one eagerness level. Measure. Then expand. The temptation to deploy comprehensive rules immediately is strong, but the failure modes compound. Our worst deployment mistake came from going broad immediately.

M — Measurement instrumentation. Wire up the prerenderingchange event and the document.prerendering property before you launch. Segment your analytics to separate prerendered navigations from standard navigations. If you can't measure the difference, you can't attribute impact or catch problems early. This step gets skipped constantly and then people wonder why their analytics look broken after deployment.

I walk through PRISM in the technical SEO audit process I run with every new client. It's not a magic framework. It's just the order of operations that prevents the expensive mistakes.

Bandwidth Cost Reality Check

Let me give you the uncomfortable math that most implementation guides skip entirely.

Prerendering doesn't just fetch the HTML document. It fetches the page's entire subresource chain: stylesheets, scripts, images, fonts, API responses. On a typical e-commerce product page in 2026, that's often 1.8–3.5MB of total transfer. Call it 2.2MB average.

/*
  Bandwidth cost estimation model:

  Variables:
  - D  = Daily sessions that view the source page (e.g., collection page)
  - H  = Fraction of sessions that hover a product link (estimate: 0.45)
  - C  = Fraction of hovered links that trigger prerender before navigation
         (empirical: ~0.65 with moderate eagerness, user hovers but doesn't
          always immediately click, giving time for prerender to trigger)
  - W  = Average prerendered page weight in MB (2.2MB in this example)
  - N  = Average prerender attempts per session (estimate: 1.8)

  Formula:
  Daily additional GB = D × H × C × N × W / 1024

  Example:
  D = 50,000 sessions/day
  H = 0.45
  C = 0.65
  N = 1.8
  W = 2.2MB

  = 50,000 × 0.45 × 0.65 × 1.8 × 2.2 / 1024
  ≈ 56.9 GB/day additional bandwidth

  At $0.085/GB CDN egress (common US pricing):
  = $4.84/day additional CDN cost
  = $145/month

  For 1M sessions/day site:
  = $2,900/month additional CDN cost

  CDN caching helps significantly — if prerendered pages are cacheable
  and the same URLs get pre-fetched multiple times, CDN cache hit rate
  reduces origin egress. But CDN-to-client transfer is still billed.
*/

For the site that generates $800,000/month in e-commerce revenue and saw an 11.7% conversion rate improvement from Speculation Rules, $145/month is trivial. The ROI math is not close. But for a smaller site, or one where the conversion impact is unclear, the bandwidth cost can exceed the benefit. Model it before you deploy.

One mitigation: the Chrome team's implementation includes a limit on concurrent prerenders (currently 10, configurable by browser settings) and cancels low-confidence speculations to manage memory. The browser is doing some self-limiting, but don't rely on it as your primary cost control.

When Not to Use Speculation Rules

Faster is not always better in the context of prerendering. Pages where you should not prerender:

State-mutating pages. Logout URLs, "add to cart" action URLs, form submission endpoints, OAuth callback URLs. The browser is smart enough to avoid prerendering cross-origin navigations and non-GET requests, but your own origin can still have GET URLs that cause state changes (anti-patterns, but they exist).

Authentication-required pages. Prerendering a page that requires authentication will result in either a failed prerender (if the server returns 401) or a prerendered login redirect (wasteful). Either way, users behind authentication gates don't benefit, and you're burning server resources.

Highly personalized pages. If the page content varies significantly based on user state (location, login status, cart contents, AB test variant, past behavior), prerendering can cache the wrong variant. When the user actually navigates, Chrome detects mismatches in some cases and falls back to normal navigation, wasting the prerender effort. In other cases the mismatch may not be detected and you serve stale personalization.

Pages with aggressive rate limiting. As I learned painfully, if page load triggers backend API calls that are rate-limited, prerendering multiplies those calls. Either handle this server-side with Sec-Purpose detection or exclude those pages from speculation.

Low-probability navigation paths. If fewer than 8–10% of users viewing a page go to a specific destination, prefetch is a better call than prerender. The bandwidth cost of prerendering pages that users don't end up visiting scales linearly with abandonment rate. Prefetch's much lighter footprint makes it tolerable for lower-confidence predictions.

Server-Side Delivery and HTTP Headers

You don't have to embed speculation rules in HTML. The spec supports delivery via HTTP headers, which is useful for platforms where you can't easily modify the HTML output (CDN edge functions, certain CMS architectures) or when you want rules to apply globally without per-template modification.

# Delivering Speculation Rules via HTTP header
# Add to server config or CDN edge function:

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

# The browser fetches that JSON file and applies the rules
# Same JSON format as the inline script block

# Example speculation-rules.json:
# {
#   "prerender": [
#     {
#       "source": "document",
#       "where": {
#         "and": [
#           { "href_matches": "/products/*" },
#           { "not": { "selector_matches": "[data-no-prerender]" } }
#         ]
#       },
#       "eagerness": "moderate"
#     }
#   ]
# }

# Nginx example:
location / {
    add_header Speculation-Rules "/speculation-rules.json";
}

# Cloudflare Worker example:
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const response = await fetch(request);
  const newHeaders = new Headers(response.headers);
  newHeaders.set('Speculation-Rules', '/speculation-rules.json');

  return new Response(response.body, {
    status: response.status,
    headers: newHeaders
  });
});

The header approach has a meaningful advantage for large sites: you can update speculation rules globally by deploying a single JSON file, without touching page templates. For A/B testing different eagerness levels or URL matching strategies, this is significantly easier to manage than hunting through template files.

One gotcha: the JSON file fetched via the header is fetched relative to the current page origin. Make sure it's accessible at the path you specify and that your CSP doesn't block it. And cache it with a reasonable TTL — the browser will fetch it on every page load if it's not cached, which defeats part of the efficiency argument for using headers over inline scripts.

For more on edge-function delivery patterns, the Chrome developer documentation on prerendering covers the HTTP header approach in detail, including interaction with CSP and CORS.

Where This Goes From Here

The spec is moving. There are proposals in the WICG repo for No-Vary-Search header integration with speculation rules, which would allow CDN-cached prefetches to match against URLs that differ only in URL parameter values — a significant improvement for e-commerce sites where the same product page gets hit with different UTM parameters. If that ships, the bandwidth efficiency of prefetch improves substantially.

Firefox remains the outstanding support gap. Mozilla's position as of early 2026 is still "under consideration." Given that Firefox holds roughly 7–12% market share in most markets (higher in developer-centric audiences), this limits CrUX impact. You're optimizing for Chrome users, which is often the majority but rarely the entirety of your audience. My analysis of browser market share for organic SEO traffic goes deeper on audience segmentation by vertical.

The intersection with AI-driven search is worth watching. If AI Overviews and similar SERP features reduce organic click-through rates for informational queries, the value of CWV improvements for those pages diminishes — fewer clicks means less CrUX data accumulation and slower feedback loops. The calculus may shift toward prioritizing commercial-intent pages where clicks remain high-frequency and CrUX data accrues quickly.

What I'm watching closely: whether Google starts incorporating Speculation Rules adoption itself as a signal, rather than just the downstream CWV effects. Right now the mechanism is purely through CrUX data reflecting improved user experiences. There's no indication Google reads your speculation rules JSON directly. But the history of web performance signals in Google's ranking system suggests they follow the metrics, and Speculation Rules is one of the few remaining tools with dramatic metric-moving potential.

This is the part of the implementation landscape where being eighteen months ahead of widespread adoption matters most. The sites building clean Speculation Rules implementations now will have accumulated CrUX history by the time the majority of their competitors start deploying it. CrUX is a lagging indicator. Start accumulating the data that feeds it before everyone else does.

The $4,200 egress bill was expensive tuition. The lesson — scope narrowly, handle Sec-Purpose server-side, use moderate eagerness as your baseline, measure prerendered navigations separately, and never deploy immediate eagerness on a site with API-heavy page loads — is worth considerably more than that. At least in my experience. Yours will differ. The spec will keep moving. Ship something, measure it, adjust. That's the whole game.

FAQ

Does the Speculation Rules API directly affect Google rankings?

Not directly. Speculation Rules improves Core Web Vitals measurements in CrUX data by reducing LCP and other performance metrics for users who navigate between pages on your site. Because CWV data from CrUX is a confirmed ranking signal, the indirect effect on rankings is real, but the mechanism is through user experience data accumulation rather than Google reading your speculation rules JSON.

What eagerness level should I start with for prerender?

Start with moderate — hover-based triggering on desktop, pointer-down on mobile. This gives you meaningful performance gains while keeping server costs manageable and limiting side effects from pages that execute API calls on load. Only consider immediate for very specific high-confidence navigation paths with thoroughly audited page-load behavior.

Will prerendering break my analytics?

It can if you don't handle it. Use the document.prerendering property and the prerenderingchange event to defer analytics initialization until the prerendered page actually activates. Modern GA4 handles this automatically, but custom analytics implementations and Tag Manager setups often do not. Always audit your analytics layer during implementation.

Does Firefox support Speculation Rules?

As of May 2026, Firefox does not support the Speculation Rules API. This limits the impact on CrUX data for audiences with significant Firefox usage. Chrome, Edge, and other Chromium-based browsers support the API in current versions. Plan your expected CrUX impact accordingly based on your actual browser audience distribution.

How do I prevent prerendering from triggering unwanted server-side operations?

Detect the Sec-Purpose request header server-side. When Chrome prerenders a page it sends Sec-Purpose: prefetch;prerender in the request headers. Use this to skip API calls, analytics events, and other side effects that shouldn't fire until the user actually navigates to the page.

Can I deliver Speculation Rules without modifying HTML templates?

Yes. Use the Speculation-Rules HTTP response header pointing to a JSON file on your origin. This works well for CDN edge function delivery or CMS architectures where template modification is difficult. The JSON format is identical to the inline script block format.