Between clicking a link and the moment the next page appears lies the real waiting time on the web for users. This is exactly where the Speculation Rules API comes in: it lets the browser prefetch or fully prerender a likely next page in the background, so that nothing needs to load on click -- the page is there within milliseconds instead of after one or several seconds. The lever is large, because only 48 percent (Chrome UX Report) of mobile websites currently pass all Core Web Vitals, and Largest Contentful Paint, passed by just 62 percent (Chrome UX Report) of mobile pages, remains the hardest Core Web Vitals metric of 2026 to meet. Adoption is growing fast: among the mobile pages of the top 10 million, 25 percent (Web Almanac 2025) already use Speculation Rules. This article explains the eagerness levels, how to avoid wasted prerenders, how to handle script side effects such as analytics, and the new prerender until script level introduced in 2026 -- and where a targeted frontend optimization makes the difference.
Key takeaways
- Speculation Rules load a likely next page in advance -- prefetch only fetches the document, while prerender builds the complete page in the background so the click activates it instantly.
- The eagerness level decides when speculation happens: from conservative (only on click) through moderate (after 200 milliseconds of hover) to immediate (right away) -- more speed means more risk of wasted prerenders.
- Waste is avoided through precise where rules, an eagerness matched to the hit probability, and Chrome's own limits, which allow only a few speculations at a time.
- A prerender already executes scripts in the background -- analytics and similar side effects must be deferred until activation via document.prerendering and the prerenderingchange event.
- The new prerender until script level from Chrome 144 renders the page but pauses at blocking scripts -- a middle ground that brings a lot of speed without triggering scripts prematurely.
What Speculation Rules Are and Why They Work
To understand why Speculation Rules are so effective, it helps to look at how classic navigation works. When a user clicks a link, the browser only then starts everything: it builds the connection, loads the HTML, discovers the CSS, fonts, images and scripts inside, loads those too, and finally renders the page. Each of these stages costs time, and they largely run one after another. The Largest Contentful Paint of the new page therefore typically appears only after a noticeable delay. Unlike classic resource hints such as preload and preconnect, which prepare individual files, this API speculates on an entire next page and shifts its complete loading work to a point before the click, when the browser is idle anyway.
The API has two levels. A prefetch only loads the HTML document of the target page into the cache in advance -- the subresources and rendering follow only after the click, which saves the connection setup and the time to first byte. A prerender goes much further: the browser loads the document together with its subresources and renders the page fully in a hidden state. When navigation is triggered, it simply swaps in the prepared page. According to Chrome, the result is a near-instant page build with an LCP near zero (Chrome for Developers), often accompanied by better values for CLS and Interaction to Next Paint. prefetch is already used on around 6 percent (Web Almanac 2024) of pages, and for JavaScript resources alone prefetch use rose from 1.0 to 4.8 percent (Web Almanac 2024) between 2022 and 2024.
prefetch and prerender Compared
Eagerness: The Four Levels of Prediction
The decisive control is eagerness. It separates the question of which URLs are speculated from the question of when that happens. Chrome has four levels with clearly defined triggers. immediate speculates as soon as the rule is read. eager begins on a very brief touch of the link -- on desktop as early as around 10 milliseconds (Chrome for Developers) of hover. moderate waits until the user dwells on a link for 200 milliseconds (Chrome for Developers) or presses it. conservative, finally, speculates only once the click begins. The default is immediate for explicit URL lists and conservative for broad document rules.
| Eagerness | When it speculates | Chrome limit (prefetch / prerender) | Suited for |
|---|---|---|---|
| conservative | only on pointer or touch down | 2 / 2 (FIFO) | default for broad document rules |
| moderate | after 200 ms hover or pointerdown | 2 / 2 (FIFO) | the likely next page |
| eager | as early as ~10 ms hover | 50 / 10 | tight link lists with a high click rate |
| immediate | instantly, as soon as the rule is read | 50 / 10 | a few, very safe targets |
The levels are not an end in themselves but a risk dial. The earlier speculation happens, the more often the prediction misses and the more work is wasted. Chrome limits this automatically: with immediate and eager, the browser keeps up to 50 prefetches and 10 prerenders (Chrome for Developers) at a time, but with moderate and conservative only two each (Chrome for Developers), which are also evicted on a first-in-first-out basis. For most sites, moderate is the recommended middle ground.
moderate as a Starting Point
Avoiding Wasted Prerenders
Every speculation that does not lead to a navigation is wasted work: bandwidth, compute and, with a prerender, a complete, unused page build. On mobile devices with limited data or a weak battery, this is especially sensitive, as our article on mobile performance optimization explains. The key is to speculate only on plausible targets and to match the eagerness to the hit probability.
<script type="speculationrules">
{
"prefetch": [
{ "where": { "href_matches": "/*" }, "eagerness": "conservative" }
],
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate"
}
]
}
</script>In this example, a sparing conservative rule applies to all internal links, while only some pages are prerendered under the more active moderate level. The where object with href_matches and selector_matches lets you steer precisely which links qualify: logout links, cart actions or elements marked as .no-prerender are excluded via not (MDN Web Docs). This keeps state-changing or expensive pages out, and speculation concentrates on what users are likely to head to next.
Chrome Does Not Speculate in Every Situation
- Frame where rules precisely and exclude state-changing links such as logout or cart
- Match eagerness to the hit probability -- moderate as a safe starting point
- Use prerender only for a few, very likely targets, prefetch for the broader set
- Mark elements that should not be speculated with a .no-prerender class or appropriate rel attributes
- Factor in the Chrome limits and do not expect more targets than the browser keeps at a time
- Verify the effect in field data instead of rolling out rules blanket
Script Side Effects: Keeping Analytics and Consent Clean
A prerender is not a passive download but a full page build -- including the execution of JavaScript. That is powerful but has a downside: anything that triggers side effects during loading already happens in the background before the user even sees the page. The classic case is analytics: a page view is counted although no one has navigated yet -- the statistics are skewed. The same applies to ad impressions, A/B test assignments or the setting of certain cookies.
function startAnalytics() {
// only counts once the user actually sees the page
}
if (document.prerendering) {
document.addEventListener("prerenderingchange", startAnalytics, { once: true });
} else {
startAnalytics();
}The browser provides two building blocks for this. The document.prerendering property is true during prerendering, and the prerenderingchange event fires exactly when the user actually activates the page (MDN Web Docs). As in the example, this lets you defer any logic that may only run on a genuine page visit until activation. For embedded third-party scripts you do not control yourself, this is harder -- one more reason to keep the stock of such scripts lean anyway, as our article on trimming third-party scripts shows.
Consent-Safe Prerenders
prerender until script: The New Level from Chrome 144
The trade-off between the large speed gain of a full prerender and its side effects got a new answer in 2026. With Chrome 144 (Chrome for Developers), released on 23 January 2026, the prerender until script level was added as an origin trial. It is a middle ground between prefetch and full prerender: the browser loads the HTML and subresources and begins rendering the page -- but pauses the parser as soon as it hits a blocking script, executing it only after navigation (Chrome for Developers). The preload scanner keeps fetching resources during this pause.
| Method | What the browser does | Scripts | Speed gain |
|---|---|---|---|
| prefetch | loads only the HTML document in advance | no execution | moderate |
| prerender until script | loads HTML and subresources, rendering begins, pauses at blocking scripts | only after navigation | high |
| prerender (full) | renders the page completely including scripts | already run in the background | highest |
The gain is considerable: according to Chrome it is well above that of a plain prefetch and potentially reaches almost as far as a full prerender -- without scripts running prematurely and triggering analytics or state changes (Chrome for Developers). For complex sites where a full prerender has so far been too risky, this is a pragmatic option. As an origin trial, the level is initially only available in a limited way and should, like any new browser feature, be safeguarded with a clean fallback to prefetch.
Limits and Browser Support
As effective as Speculation Rules are, they are not a universal tool. The API is not yet Baseline, meaning it does not work in all widely used browsers (MDN Web Docs) -- which is uncritical, because browsers without support simply ignore the rules and load the page as usual. Adoption is also unevenly distributed across the web: among the top 1,000 sites it is low at just 3 percent (Web Almanac 2025) on desktop and 5 percent (Web Almanac 2025) on mobile, reaches around 15 percent (Web Almanac 2025) for the top 1 million, and climbs to 25 percent (Web Almanac 2025) in the long tail of the top 10 million. One reason for the high adoption in the long tail is that Speculation Rules are now baked into WordPress (Web Almanac 2025).
- No substitute for fast pages: prerendering speeds up the next navigation, not the first page load
- Not available in every browser -- rules are ignored without support
- Data Saver, Energy Saver and memory pressure suppress speculations
- State-changing and consent-requiring operations must wait until activation
- Cross-origin targets are subject to additional restrictions and requirements, for example on the referrer
How We Set Up Speculation Rules Cleanly
In practice we approach Speculation Rules the same way as any other frontend optimization measure: measure first, then act. First we analyze the actual navigation paths in a performance analysis -- which page typically follows which in a funnel, where the most frequent transitions occur. On this basis we choose targets and eagerness so that the hit rate stays high and little work is wasted. We exclude state-changing links, cleanly couple analytics and consent-requiring scripts to activation, and safeguard new levels such as prerender until script with a fallback. Afterwards we check the effect in the field data of the Core Web Vitals instead of relying on lab values alone. For us, Speculation Rules are part of a larger range of services around loading time and Core Web Vitals.
Instant navigation does not come from prerendering as much as possible, but from preparing exactly the one likely next page -- without skewing analytics and without burning resources on weak devices.
The Core in One Sentence
The appeal of Speculation Rules is that they act on immediately perceived speed: a next page that is already there on click feels faster than any well-optimized loading animation. Because the rules are purely declarative in the markup and require no rebuild of the existing site, they are among the most efficient building blocks of a targeted frontend optimization -- provided eagerness, exclusions and consent are set with judgment. How fast navigation and loading time affect conversion and revenue is explored in our article on the relationship between loading time, conversion rate and revenue; how speed and resource efficiency go together is shown in the article on sustainable, high-performance websites.
Sources and Studies