Loading the next page before the click: why we do not

It is now possible to tell a visitor’s browser: when the cursor approaches a link, go and fetch the page behind it, and if you have room to spare, prepare it entirely in advance. The result, the first time you see it, is disconcerting. The click no longer waits for anything. Not “fast”: instantaneous, because the page was already ready, invisible, in a ghost tab. It is one of the few novelties whose effect a non-specialist visitor notices without being told.

Browsers call this mechanism “speculation rules”. We have not put it on this site, and here is the full reasoning, including what could overturn it.

What it spends, and whose

Fetching a page in advance means using data. Preparing it entirely means, on top of that, making the visitor’s device work: its battery, its processor, its mobile plan.

The bill is not paid by the site, it is paid by the visitor. They use data for pages they will never open. On a metered connection or an entry-level phone the promise reverses: one page in four has been made instantaneous by making the other three pay. And on a menu of fifty links, merely moving the mouse across it sets off a long series of loads of which almost none will be used.

What it tells a third party

A page prepared in advance is a page loaded. Everything it contains runs: audience measurements count a visit that did not happen, tracking cookies are set, outside services are called. There are remedies, but they assume that every service built into the site respects them. On a site that loads an audience measurement, a map, a social network feed and a consent module, which is to say most sites, the assumption is doubtful, and the client ends up with distorted statistics and data passed to third parties for ghost visits.

We build sites that call no third party. The problem does not arise with us, and that is precisely what weakens the opposite argument: on a site without third parties there is not much left to gain either.

What it brings here: nothing measurable

A page on this site loads in a fraction of a second, and the time between two pages is already below the threshold where the eye perceives waiting. Preparing the next page would turn an imperceptible wait into no wait at all, in exchange for a very real consumption of data on the visitor’s device. It is not a difficult trade-off.

One last point, less debatable

This function exists today only in some browsers, those in the Chrome family, Edge included. MDN says so bluntly: it is not part of the web’s common core, because some of the most used browsers lack it. That does not rule it out: browsers that do not understand it lose nothing. But the question changes: it is no longer “do we want this gain”, it is “do we want this gain for part of the visitors, at the price of a real cost on their devices”.

Where we would do it

On a shop, a catalogue, documentation: many pages, deep navigation, a visitor who keeps going. By preparing only the document and not the whole page, and by waiting for the cursor to linger on the link, the gain there is clear and the expense stays bounded.

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. The same trade-off applies to moving between two pages, which costs the visitor’s device nothing and which we therefore kept. We prefer to write that rather than deploy a setting so that we can say we deployed it. If you are wondering what a faster site would really win you, the pricing page and the contact page are there to talk it over.