We have spent the last decade obsessed with making websites fast. We compressed images. We minified JavaScript. We moved everything to the Edge. But in 2026, we have reached a plateau. If your site loads in 500 milliseconds, you are not winning. You are just keeping up. The real winners this year are the ones whose sites load in zero milliseconds. That is not a marketing claim. It is a technical reality most developers are completely ignoring.
It is called Speculative Prerendering, and it is the single most important lever for retaining organic traffic and killing your bounce rate right now.
And we use it for all of our pages. Even the one that you are reading right now.
The Problem with Fast Enough
When you click a link, your browser has to locate a server, request a page, wait for the server to respond, download the data, and render it on screen. Even on the best fibre connection, there is a physical lower bound to how fast that can happen.
For performance engineers, you already know Core Web Vitals are the gatekeepers of Google rankings. You might have a perfect Lighthouse score, but real users are still seeing a blank screen for a fraction of a second. In a world where attention spans are measured in heartbeats, that fraction is where you lose the click, the session, and the conversion.
Google is not just measuring how fast your page loads. It is measuring how seamless the transition feels. A page that is simply there when the user clicks is the highest possible signal of a quality user experience.
The Speculation Rules API: Beyond Old-School Prefetch
Most people are still using prefetching, where the browser downloads some files in the background. That is table stakes at this point. The Speculation Rules API is a different class of tool entirely.
It allows you to instruct the browser to not just download the files, but to fully render the entire next page in a hidden background tab. When the user clicks the link, the browser swaps the visible tab for the pre-rendered one. It is instantaneous. No loading state. No flicker. The page is simply there, as if it were cached locally in the user's own machine.
Prefetch vs Prerender: Prefetch downloads the resources. Prerender executes them. With prerender, the full page layout, styles, and scripts have already run by the time the user clicks. The browser just reveals it. This is the difference between preparing ingredients and having the meal already plated.
The Four Eagerness Levels You Need to Master
The real power of the Speculation Rules API is in the eagerness property. There are four distinct levels of speculative intensity.
Immediate starts the speculation the moment the browser sees the rule in your HTML. High reward, high server load risk. Use it for pages you are nearly certain the user will visit.
Eager triggers on desktop when a user hovers over a link for roughly 10 milliseconds. On mobile, as of recent browser updates, it triggers shortly after a link enters the visible viewport. This is the sweet spot for content-heavy blogs and editorial sites.
Moderate triggers after a 200 millisecond hover or on the pointerdown event. It is the safer default for data-heavy pages where background rendering carries a real CPU cost.
Conservative only fires when the user actually begins the click or touch. It still saves the 100 to 200 milliseconds it takes for a finger to lift or a mouse button to release. Barely noticeable in isolation, but measurable at scale.
The No-Vary-Search Fix: Stop Wasting Your Prerender Budget
One of the most common and costly mistakes with prerendering is query parameter mismatches. You prerender /blog/article, but the user clicks a link with a UTM tag like /blog/article?utm_source=twitter. The browser sees two different URLs and discards the prerendered page entirely.
The fix is the No-Vary-Search HTTP response header. It tells the browser which query parameters to ignore when matching a prerendered page to an incoming navigation. Without it, analytics and tracking tags are silently invalidating a significant portion of your prerendering work before any user sees the benefit.
What No-Vary-Search Actually Does: Set No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign") in your response headers and the browser will treat those tagged URLs as matches for your prerendered pages. This is the detail that separates a deliberate performance strategy from one that only works in a lab environment with clean URLs.
Prerender-Until-Script: The CPU-Safe Option
A legitimate concern with full prerendering is the background CPU cost of executing heavy JavaScript for a page the user may never actually visit. Running third-party trackers, complex state initialisation, or large framework hydration in the background on every speculation is a real tax on lower-end devices.
The prerender-until-script feature, currently moving through browser standardisation, addresses this directly. It lets the browser download the HTML, parse the CSS, and build the layout tree, but pauses before executing any script tags. You capture the vast majority of the speed benefit without the JavaScript execution cost. When the user does click, the scripts fire and the page activates instantly.
Protecting Your Analytics Data
The most common objection to speculative prerendering is analytics pollution. If a page is prerendered and the user never clicks it, a naive setup records that as a page view, corrupting your session data and inflating your apparent traffic.
The correct pattern is to check document.prerendering before initialising your analytics scripts. You defer sending the page view event until the prerenderingchange event fires, which only happens when the prerendered page actually becomes the active tab. No confirmed navigation, no data sent.
For deeper measurement, PerformanceNavigationTiming.activationStart tells you exactly how much time passed between the user initiating the navigation and the prerendered page becoming active. When that number approaches zero, you have achieved what this whole strategy is working toward.
The goal is not just a fast site. The goal is a site that feels like it is already open. When activationStart reads near zero, you have crossed that line.
Agentic Speculation: From Shotgun to Sniper
The current state of the art is moving away from static rule files toward what can be called agentic speculation. Instead of manually listing every URL you want prerendered, small client-side models observe user behaviour and send dynamic hints to the Speculation Rules API at runtime.
A practical example: a script notices a user has read 80 percent of a blog post. The statistical probability they will click through to the next article is now high. The agent triggers a moderate prerender of that specific next post at that moment, rather than prerendering it for every visitor from the moment they land. This shifts the approach from prerendering everything speculatively to prerendering precisely, spending the user's bandwidth and battery only when the signal justifies it.
Cross-Origin Speculation and the Private Prefetch Proxy
A legitimate concern for security-conscious teams is whether speculating a cross-origin link exposes the user's IP address to a third-party server before they have made any decision to navigate there. In the current implementation of the Speculation Rules API, cross-origin prerender requests are routed through a privacy-preserving proxy. The target server sees the request but does not receive the user's identity or IP address until they commit to the navigation.
To enable this correctly, your ruleset needs the requires: ["anonymous-client-ip-when-cross-origin"] flag set. Without it, the browser will skip the speculation for cross-origin targets rather than risk a privacy violation.