Because every click starts from zero. Your first page can load in half a second and the second page still has to be requested, downloaded, parsed, and painted all over again. The browser waits for the click before it starts. Speculation rules change that by letting the browser start early.
This is the gap between a fast site and a fast-feeling site. Single page apps solved it years ago by never doing a real navigation, at the cost of shipping a large JavaScript bundle to every visitor. Regular multi-page sites got the better initial load and kept the slower clicks.
The Speculation Rules API is the platform's answer to that tradeoff. It is genuinely impressive, and it is also not ready for everyone, which is the part we want to be straight about.
It is a browser feature that lets you tell the browser which pages a visitor is likely to visit next, so it can fetch or even fully render them in advance. MDN Web Docs describes it as "designed to improve performance for future navigations", targeting document URLs rather than individual resource files.
You declare the rules in a script tag with the type set to speculationrules, or through a Speculation-Rules HTTP header. Inside it you write JSON describing which URLs to speculate on, either as an explicit list or as a pattern match across your site.
MDN positions it as the successor to older techniques, calling it "an alternative to the widely-available link rel prefetch feature" that is "designed to supersede the Chrome-only deprecated link rel prerender feature". If you have used resource hints, this is the same instinct applied to whole pages instead of single files. We covered the older tools in our guide to preload, preconnect, and prefetch.
Prefetch downloads the page. Prerender loads it completely. With prefetch, MDN says the browser downloads "the response body of the referenced pages, but none of the subresources referenced by the page", so navigation is faster but not instant. Prerender goes much further.
MDN describes prerender as causing the browser to "fetch, render, and load the content into an invisible tab", including "loading all subresources, running all JavaScript, and even loading subresources and performing data fetches started by JavaScript". The page is fully built before anyone clicks it.
The payoff is dramatic. MDN says navigations to a prerendered page "will be near-instant", because the browser simply "activates the invisible tab instead of carrying out the usual navigation process". There is no load, only a swap.
The cost is proportional. A prerender spends real bandwidth, memory, and CPU on a page the visitor might never open. Prefetch is the cheap, safe option. Prerender is the expensive, spectacular one, and choosing between them is mostly a question of how confident you are about where people go next.
Not all of them, and this is the honest headline. MDN currently labels the Speculation Rules API as limited availability, stating that the feature "is not Baseline because it does not work in some of the most widely-used browsers". MDN also flags it as experimental technology.
Chrome is where it works. Chrome's own documentation says support began in Chrome 109, with Chrome 121 adding the eagerness parameter that makes the feature practical to tune. Edge follows Chrome, since they share an engine.
That limited availability label matters more than a support percentage, and it is exactly the judgement call the Baseline system exists to make for you. A feature that has not reached every core browser is a feature you build as an enhancement, never as a foundation.
The saving grace is how gracefully it fails. A browser that does not recognise the speculationrules script type simply ignores the block, exactly as it ignores any script type it does not understand. Visitors on those browsers get the normal navigation they would have had anyway. Nothing breaks, nothing needs a fallback, and nobody sees an error.
Eagerness tells the browser how keen to be. Chrome's documentation defines four values. Immediate speculates as soon as the rules are seen. Eager triggers on a very short hover or when a link enters the viewport. Moderate waits for a longer hover or a pointer down. Conservative only acts on pointer or touch down.
The numbers behind those words are specific. Chrome's docs say eager performs speculations after "holding the pointer over a link for 10 milliseconds" on desktop, and on mobile uses viewport heuristics "triggering 50ms after an anchor enters the viewport". Moderate waits for a pointer down or "after 200ms hover" on desktop, and on mobile triggers "500ms after scrolling stops".
Conservative is the one people underestimate. Acting on pointer down sounds too late to help, but there is a real gap between pressing a mouse button and releasing it, and between touching a link and lifting your finger. The browser gets a head start of a hundred milliseconds or so for almost no wasted work.
Our default is moderate for prerender and something more eager for prefetch. Moderate hover is a genuine signal of intent, and prefetch is cheap enough that guessing wrong costs little.
Fewer than you would expect, and that is deliberate. Chrome enforces limits to protect memory. With immediate eagerness, Chrome allows up to 50 prefetches and 10 prerenders. With eager, moderate, or conservative, the limits drop to 2 of each, handled first in first out.
Chrome's documentation explains the behaviour at the limit: "after reaching the limit, a new speculation will cause the oldest speculation to be canceled and replaced by the newer one to conserve memory." So you cannot prerender your whole navigation and hope for the best.
This changes how you write the rules. There is no point listing twenty likely destinations, because the browser will simply churn through them and discard the early ones. Pick the two or three pages that genuinely follow from the current page, and let the pattern matching stay narrow.
It improves all three, because the work happens before the visitor is watching. Chrome's documentation states that prerendering "can therefore also have a direct impact on a site's Core Web Vitals, with near zero LCP, reduced CLS (since any load CLS happens before the initial view), and improved INP (since the load should be completed before the user interacts)."
Near zero LCP is the line that gets people excited, and it is real for the visitors who got a prerendered page. If your largest element is already painted in a hidden tab, activation shows it immediately. Our guide to fixing Largest Contentful Paint covers the harder work you still need for the first page a visitor lands on.
Keep the scope in mind though. Prerendering does nothing for the entry page, because there was no previous page to speculate from. Most of your search traffic and most of your ad traffic lands cold. Speculation rules improve the second click onwards, which is a real win, but it is not a substitute for a fast first load.
Analytics is the classic problem. A prerendered page runs its JavaScript before anyone has seen it, so a naive setup can record a pageview for a visit that never happened. Any measurement or tracking that fires on load needs to wait for activation instead.
The browser helps here rather than leaving you to guess. Chrome's documentation notes that "a number of APIs that cause intrusive behaviors (for example, prompts) are not activated in this state, and are instead delayed until the page is activated". So the obviously disruptive things are held back automatically.
What is not held back is your own code. Anything you wrote that assumes load means visible needs checking, and that includes analytics events, video autoplay, animation triggers, countdown timers, and anything that writes to storage on arrival. Chrome also cancels prerenders it cannot safely complete, so a page relying on a blocked behaviour may simply never get the benefit.
Our practical advice is to avoid prerendering anything with a side effect. Do not prerender logout links, add to cart actions, form submissions, or anything that changes state. MDN's own example rules explicitly exclude a logout path and add to cart URLs for exactly this reason.
Yes for prefetch, carefully for prerender, and never as a substitute for real performance work. Prefetch is cheap, low risk, and helps immediately in Chrome and Edge. Prerender is worth it on high-intent journeys where you can genuinely predict the next page.
The sites that benefit most are content-heavy multi-page sites with obvious paths. A blog where readers move from an article to a related article, or a service site where people go from a services page to a contact page, both have predictable next steps. A site where every visitor does something different gains much less.
Where we would not spend the effort is on a site that is still slow. Speculating a heavy page just moves the cost earlier. If a page takes four seconds to build, prerendering it means the browser spends four seconds of somebody's battery and data on a page they may never open. Fix the page first, then speculate.
Start with a prefetch rule at moderate eagerness on your highest traffic template, and exclude anything that changes state. Ship it, then check your analytics for phantom pageviews before you consider adding prerender. That order keeps the risk low while you learn how your own traffic behaves.
Treat it as an enhancement in your planning too. Because MDN still lists this as limited availability, it should never appear in a requirements document as something the site depends on. It is a bonus for the browsers that have it, and that framing keeps you honest when support questions come up later.
If you want a hand working out which journeys on your site are predictable enough to be worth speculating on, or you would rather fix the underlying page speed first, we are happy to take a look. Let's talk, and you can find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.