Instant Navigation

The problem

Everything so far has been about making a page load faster. There is a more radical option: make the load happen before the click. If the browser has already fetched, built and rendered the next page by the time you ask for it, the navigation is instant, whatever the network and the CPU are doing.

There are two separate tools. The back/forward cache makes going back instant by keeping the whole page in memory. Speculative loading makes going forward instant by guessing where you’re going. Both are gambles with different costs, and both fail for reasons that are easy to introduce by accident.

Things to try

1. “Prefetch on hover”. A modest, cheap win: only the document request is saved. The page still has to fetch its styles, scripts and images.
2. “Prerender on hover”. At a typical 350 ms between resting on a link and clicking, a prerender only gets a partial head start. Raise “Pointer rests, then clicks after” to a second and a right guess becomes near-instant; drop it to 250 ms and it barely helps.
3. “Prerender immediately”. The page is nearly always ready, but now it guesses three links at once, and most of the work is thrown away. Look at the data and CPU wasted.
4. Lower the chance the guess is right. The savings shrink and the waste doesn’t.
5. Add an unload handler and watch the four back navigations go from instant to a reload.
6. Switch the CPU to Desktop and the network to 100 Mbps. A cold load is already fast, so there is much less to gain.

Going back: the back/forward cache

When a visitor leaves a page, the browser can keep the entire page in memory (the DOM, the JavaScript heap, scroll position, everything) and bring it back as it was when they press back or forward. It isn’t the HTTP cache, which stores files. It stores a live page. Restoring one takes a few tens of milliseconds, whatever the network is doing.

It’s on by default in the major browsers, and the thing to know is that pages quietly opt out. Common reasons:

• An unload event handler. Desktop Chrome and Firefox treat it as disqualifying; Chrome on Android and Safari will still try to cache the page, but don’t rely on that. Use pagehide (and visibilitychange) instead.
• Cache-Control: no-store on the page. Browsers are loosening this, but don’t count on it.
• An open connection (a WebSocket, WebRTC, a pending transaction) when the user leaves. Close it on pagehide.
• A page opened with window.open that keeps a reference to the window that opened it.

When a page is restored from the cache, load doesn’t fire again. Listen for pageshow and check event.persisted if you need to refresh anything such as a stale session, a cart count or a timer.

Going forward: speculative loading

The modern way to speculate is the Speculation Rules API, a JSON block in the page:

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

prefetch

Fetches the next page’s document only. Cheap. It saves one request, and the page still loads its resources after the click.

prerender

Loads and renders the whole page in a hidden context, scripts and all. Activating it when the visitor clicks is close to instant. It costs the full load, whether or not the visitor goes there.

eagerness

How readily to speculate. conservative acts on pointer-down, moderate when the pointer rests on a link (about 200 ms on desktop Chrome) or is pressed, eager after a very short hover on desktop, and immediate as soon as the rules are seen. The more eager, the better the head start, and the more wrong guesses.

Support is currently in Chromium browsers. Others ignore the script block, so it’s a safe progressive enhancement: supporting browsers get instant navigations, the rest behave as before. Cross-origin speculation has extra privacy restrictions.

What can go wrong with prerendering

• Side effects. A prerendered page runs its JavaScript. Analytics fire for a page nobody visited, a “view” counter ticks, a one-time offer is consumed. Defer that work until the page is activated using document.prerendering and the prerenderingchange event.
• Never speculate on URLs that change state. A link like /logout or /add-to-cart?id=3 must not be prerendered or prefetched. Use rules that match only safe, read-only pages.
• Cost. Data, CPU and battery, and load on your servers. Measure how often the guess is right before going eager.
• Server awareness. Speculative requests carry a Sec-Purpose header, so your server can recognise and, if needed, treat them differently.

One related tool, view transitions, makes navigation look smoother with an animated hand-off between pages. It doesn’t make the next page arrive any sooner, so treat it as polish.

Common misconceptions

See it on a real page

1. In DevTools, Application → Back/forward cache has a “Test back/forward cache” button that reports exactly why a page isn’t eligible.
2. Application → Speculative loads shows which rules matched and whether each speculation was used or failed.
3. On a page, find out whether it was prerendered:

   const nav = performance.getEntriesByType('navigation')[0];
   console.log(nav.activationStart > 0 ? 'prerendered' : 'normal load');

4. Count how often back navigations restore from the cache in the field, using pageshow with event.persisted.

Model assumptions