Speculation Rules: Making Your Site Feel Instant With Prefetching

Fast pages that still feel slow

You can compress every image, tune your server and pass Core Web Vitals, and clicking a link still takes a beat: the browser has to fetch the next document, parse it, load its assets and render. On a decent connection that is a few hundred milliseconds; on a train it can be seconds. That gap between click and content is navigation latency, and traditional optimisation can only shrink it, never remove it.

Prerendering removes it. If the browser has already fetched and rendered the next page in the background before the click happens, navigation becomes effectively instant. The Speculation Rules API is the modern, standardised way to tell the browser which pages are worth that gamble.

Chrome already does a version of this on its own: when you type into the address bar, it may preconnect to or prerender likely destinations. Speculation rules hand that power to site owners for in-site navigation, where you know far better than the browser which page comes next.

How the Speculation Rules API works

You declare rules as JSON inside a <script type="speculationrules"> tag, or serve them via an HTTP header. Because the format is declarative, there is no library to load and nothing executes in browsers that do not understand it. Rules support two actions. Prefetch downloads the next document so it is ready to parse. Prerender goes further: it loads the page fully in a hidden background context, including subresources and JavaScript, so activation on click is close to instantaneous.

Modern document rules mean you do not have to list URLs by hand. You can match patterns, such as every link under /services/, and exclude others. Each rule also takes an eagerness setting that controls when the browser acts:

• immediate: speculate as soon as the rule is seen; use sparingly.
• eager: act on the first faint signal of interest in a link.
• moderate: act when a visitor hovers a link briefly or begins to touch it; the sensible default.
• conservative: act only on pointer-down or touch-down, trading a little speed for minimal waste.

A practical setup for a small-business site

A sensible starting configuration: prerender links matching your main sections with moderate eagerness, and exclude anything that changes state. In prose, the JSON says: prerender where href_matches "/*", but not where the URL matches /basket, /checkout, /logout, /wp-admin or anything carrying query parameters such as ?add-to-cart. Chrome caps concurrent speculations, and hover-triggered prerenders are limited to a couple at a time, so the browser will not stampede your server.

Two rules of thumb keep you safe. First, only prerender pages that are free of side effects when loaded. Second, prefer moderate eagerness until you have measured; a hovering cursor is a strong signal of an imminent click, so you gain most of the benefit at a fraction of the waste.

If you run WordPress, note that core has shipped speculative loading since version 6.8, defaulting to conservative prefetching, and the official Speculative Loading plugin lets you switch modes and exclusions without hand-writing JSON.

Measuring before and after

Instinct is not evidence, and prerendering is easy to measure. A simple protocol:

• 1. Record a baseline week of field data: LCP and TTFB from the Chrome UX Report or your RUM tool, plus server request counts.
• 2. Deploy rules to a subset of templates first, such as blog posts.
• 3. Use the Speculative loads panel in Chrome DevTools (under Application) to confirm rules are matching and pages are prerendering.
• 4. Compare navigation timings for speculated versus normal navigations, and watch how the LCP distribution shifts.
• 5. Check server logs for the increase in requests, and confirm your cache-hit ratio absorbed it.

Successful prerendered navigations often report an LCP close to zero, because the content was painted before the user arrived. Expect your averages to improve, and expect the biggest wins on journeys with strong hover intent, such as menu links and pagination.

The traps: analytics, ads and server load

A prerendered page runs its JavaScript in the background, which is exactly what makes activation instant and exactly what can corrupt your data. If a speculated page never gets clicked, any script that logged a pageview has counted a visit that did not happen.

• Analytics: Google Analytics 4 is prerender-aware and defers its hits until the page is actually shown. Older or self-built trackers may not be; gate them behind a document.prerendering check and fire on the prerenderingchange event.
• Ads and A/B tests: impressions and experiment assignments should not fire during prerender; audit any third-party tags before rolling out widely.
• Server load: every speculation is a real request with real subresources. On shared hosting, start with conservative or moderate eagerness and watch your logs.
• Personalisation: pages that render user-specific content may be stale by the time they are activated, and some prerenders are ineligible anyway; test logged-in journeys deliberately.

Support, and a sensible rollout

Speculation rules are a Chromium feature: Chrome, Edge and related browsers act on them, while Safari and Firefox simply ignore the unknown script type. Nothing breaks anywhere, which makes this pure progressive enhancement, and given Chromium's share of UK traffic, most of your visitors benefit from day one.

Roll out in stages: blog first, then service pages, then category-to-product journeys. Keep checkout and account areas excluded permanently. Revisit the rules quarterly, because your analytics will tell you which journeys people actually take and where prerendering earns its keep. If you would like this implemented and measured properly, our team at Thind Global Services can set it up alongside a wider performance review.