Speculation rules, and why they are not on this site

A small block in the head is now enough to tell the browser: when the cursor comes near a link, fetch the page behind it, and if you have room to spare, build it in full ahead of time.

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/*" },
    "eagerness": "moderate"
  }]
}
</script>

The first time you see the result it is disorienting. The click has no latency at all. Not “fast”: instant, because the page had already been built, invisibly, in a ghost tab. It is one of the rare web features whose effect a non-technical visitor notices without being told.

We did not put it on this site, and here is the whole reasoning, including what could overturn it.

What it spends, and whose money it is

Prefetching means fetching the document. Prerendering is something else: the browser actually runs the page, off to one side, with everything in it.

The bill is not paid by the server, it is paid by the visitor’s device. Mobile data spent on pages they will not open, processor time, battery. On a metered connection or an entry-level phone the promise inverts: you have made one page in four instant by charging the other three for it.

The eagerness setting exists for exactly this, and it deserves to be read before it is copied. immediate prerenders everything declared, at once. moderate waits for a hover of roughly two hundred milliseconds. conservative waits for the mouse button to go down, which buys only a few tens of milliseconds but never wastes anything. The default is not the one you want: hovering across a menu on a site with fifty links sets off a long run of loads, almost none of which will be used.

What it says to a third party

A prerendered page is a loaded page. Its requests go out, its analytics count a visit that did not happen, its cookies get written.

The platform has a remedy, the Document.prerendering API, which lets a script know it is running in a ghost tab and hold off. That assumes every embedded script uses it. On a site loading an analytics tag, a map, a social feed and a consent module, which is to say on most sites, the assumption is doubtful.

We build sites that call no third party. So the problem does not arise here, and that is precisely what weakens the argument in the other direction: on a site with no third parties, there is not much left to gain either.

What it brings here: nothing measurable

A page of this site weighs a little over six kilobytes of HTML, five of CSS, no JavaScript, and it is served from a machine in Switzerland. Moving from one page to the next is already below the threshold at which the eye registers a wait.

Prerendering would turn an imperceptible wait into no wait at all, in exchange for very real data usage on the visitor’s device. That is not a hard call.

And one last point, harder to argue with

Speculation rules currently work only in Chromium-based browsers. MDN says so plainly: the feature is not part of the common baseline, because it is missing from some of the most widely used browsers. WebKit is working on it, Firefox is not.

That does not forbid it: this is progressive enhancement in the strict sense, and those who do not get it lose nothing. But it changes the question. You are no longer asking “do I want this gain”, you are asking “do I want this gain for some of my visitors, at a real cost on their devices”.

Where we would use it

On a shop, a catalogue, a documentation site: many pages, deep navigation, a visitor moving through them. With prefetch rather than prerender, and eagerness set to moderate. There the gain is clear and the spending stays bounded to the document.

On a ten-page site already served in a few milliseconds, like the titles in our catalogue, the honest answer is that there is nothing to gain. We would rather write that than ship it in order to be able to say we shipped it.