Traditional prefetching is great when the next page is highly predictable, like the next step in a checkout flow or setup wizard.
The eagerness: conservative setting fires the prefetch on pointerdown or touchstart, meaning the browser only starts prefetching once the user begins to click or tap a link. There are more aggressive options, such as prefetching when a link becomes visible or when a user hovers over it.
And when you guess wrong, visitors spend bandwidth, battery, and compute on pages they never visit. Multiply that across millions of sites and visitors, and those speculative requests add up.
In short, Speculation Rules changed my mind because they make prefetching feel more responsible: don’t prefetch too much, don’t prefetch too early, and only give the browser a safe hint when the user’s intent is clear.
But they will not prefetch arbitrary links on a page, and for good reason. Prefetching /logout, for example, would sign the visitor out, even if they change their mind and never complete the click or hit Enter.
A couple months ago, while updating my HTTP header analyzer, I added support for the Speculation-Rules HTTP header. Learning about the Speculation Rules API inspired me to try it on my own blog.
For years, prefetching made me uneasy. It can make websites feel faster, but it also asks visitors to spend bandwidth, CPU, memory, and battery on pages they may never open. That always felt a little wasteful, and maybe even a little disrespectful.
Some of you might point out that browsers have supported prefetching for years through the older <link rel=”prefetch”> tag. That is true, but I’ve never loved it.
On many websites, including my blog, it’s anyone’s guess what a visitor will click next. Sometimes you can make a smarter guess, but it is still a guess.
Browsers already do some speculative loading on their own without Speculation Rules, but only for high-confidence destinations, like the address bar suggestion you are typing toward.
That unease also comes from a deeper belief: prefetching should not be a substitute for a fast site. Too many sites are weighed down by unnecessary JavaScript, tracking scripts, third-party widgets, heavy fonts, and oversized assets. Prefetching should not be used to hide that bloat. Before considering prefetching, make your site light and fast.
For my blog, I added the rules directly to the HTML of every anonymous page request:
So why implement Speculation Rules? My site was already fast without being static. With eagerness: conservative, the browser waits until the user has already started an action. At that point, the navigation is no longer a vague prediction. It is very likely to happen.
The idea is simple: a page can give the browser a small JSON rule set that says which links are safe to prefetch, and when. Those rules can live directly in the HTML using <script type="speculationrules">, or in an external file referenced by the Speculation-Rules HTTP header.
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/search*" } }
]
},
"eagerness": "conservative"
}]
}
</script>
So is prefetching still worth it when the user has already started to click? I think so. With eagerness: conservative, the browser only gets a small head start but something is better than nothing.
That is why Speculation Rules can be useful. You can tell the browser which paths are safe and which to leave alone.
Speculation Rules also respect Battery Saver and Data Saver modes. If a device is low on battery, memory constrained, or trying to conserve data, the prefetching is skipped.
