
The fastest page load is the one that already happened. If the browser can guess where a user is going and do the work ahead of time, the click that follows resolves in milliseconds — the page is simply there. Developers have chased this for years with <link rel="prefetch">, hover-intent libraries, and framework-specific prefetchers, all of which work but each solving a slice of the problem.
The Speculation Rules API is the platform finally answering that with one built-in mechanism: a declarative way to tell the browser which pages are likely next and how aggressively to prepare them. Two levels of speculation — prefetch and full prerender — driven entirely by a small JSON block, no framework and no hover-listener plumbing required. The first time you watch a click resolve with zero perceptible load, it's hard to go back.
Prefetch vs prerender#
The API offers two modes, and the difference is how far the browser goes:
- Prefetch downloads the document for a likely next URL and keeps it warm. When the user navigates, the HTML is already in hand, so the network round-trip is skipped. Lower cost, safe, broadly useful.
- Prerender goes all the way — the browser fetches and fully renders the page in a hidden tab, running its JavaScript and building the DOM. On navigation it's swapped in instantly. The payoff is dramatic; the cost is real, since you're running a whole page the user might never visit.
Prefetch is the low-risk default. Prerender is the "this is worth the resources" upgrade for high-confidence destinations.
The basics: declaring rules#
You add a <script type="speculationrules"> block containing JSON. The simplest form lets the browser decide, using link heuristics like pointer hover or proximity:
<script type="speculationrules">
{
"prerender": [
{
"where": { "href_matches": "/products/*" },
"eagerness": "moderate"
}
]
}
</script>
Two knobs do most of the work:
whereselects which links are candidates — by URL pattern (href_matches), by CSS selector, or a combination. Scope it to real navigation targets, not every link on the page.eagernesscontrols timing:immediate(act now),eager(as soon as a link appears),moderate(on hover / pointer-down intent), orconservative(only on a strong signal like pointer-down).moderateis the sensible starting point — it waits for a hint of intent before spending resources.
Where it beats the old tricks#
Compared to rel="prefetch" and hand-rolled hover prefetchers, the Speculation Rules API brings a few concrete wins:
- Full prerender, not just document prefetch. The old prefetch got you the bytes; prerender gets you a rendered, interactive page ready to swap in.
- Built-in intent heuristics.
eagernesslets the browser use hover and pointer-down signals natively, instead of you wiring up mouseover listeners and guessing thresholds. - It's declarative and out of the main thread. No JavaScript execution cost to manage the speculation itself — you describe intent, the browser schedules the work with awareness of resource and data constraints.
The guardrails#
Speculation, especially prerender, does work that may be wasted, so it comes with responsibilities:
- Respect side effects. A prerendered page runs its JavaScript before the user "visits." Analytics, ad impressions, and anything that mutates state must account for this. Use the Page Visibility API and the
prerenderingchangeevent to defer side-effecting work until the page is actually activated — otherwise you'll log phantom pageviews. - Don't prerender destructive or costly URLs. Never speculate a logout link, a "delete" action, an add-to-cart with side effects, or an expensive uncached endpoint. Scope
whereto safe, idempotent navigation targets. - Mind data and battery. The browser already skips speculation under data-saver mode or resource pressure, but aggressive
eagernesson a link-heavy page can still waste bandwidth. Prefermoderate, prerender only high-confidence destinations, and measure. - Treat it as an enhancement. Support isn't universal, so it must degrade gracefully — a browser that ignores the rules simply navigates normally. Never make correctness depend on speculation having happened.
The takeaway#
The Speculation Rules API turns "make navigation feel instant" from a bag of tricks into a few lines of declarative JSON. Reach for prefetch as a safe default, upgrade to prerender for the destinations you're confident about, start at moderate eagerness, and guard any side effects behind activation. Done with that care, the next click stops feeling like a load at all — which is exactly the kind of speed both users and Core Web Vitals reward.
FAQ#
What is the Speculation Rules API?#
The Speculation Rules API is a browser standard that lets you declaratively tell the browser which pages a user is likely to visit next, so it can prefetch or fully prerender them ahead of the click. It's configured with a <script type="speculationrules"> block containing JSON, and it makes qualifying navigations feel near-instant.
What's the difference between prefetch and prerender?#
Prefetch downloads a likely next page's document and keeps it ready, skipping the network round-trip on navigation. Prerender goes further and fully renders the page — including running its JavaScript — in the background, so it can be swapped in instantly. Prerender is faster for the user but costs more resources, so it should be reserved for high-confidence destinations.
Does prerendering break analytics?#
It can, if you don't account for it. A prerendered page runs its JavaScript before the user actually visits, which can log phantom pageviews or fire premature events. Use the Page Visibility API and the prerenderingchange event to defer analytics and other side effects until the page is genuinely activated.
Is the Speculation Rules API safe to use in production?#
Yes, when used as a progressive enhancement. Browsers that don't support it simply navigate normally, and supporting browsers skip speculation under data-saver mode or resource pressure. The key rules are to scope speculation to safe, idempotent URLs (never logout or destructive actions), start with moderate eagerness, and guard side effects behind page activation.
References: