v151 · loading · origin trial

Prefetch activation beacon

The proposed on-prefetch-activation response header lets a server name a telemetry endpoint. When an enabled browser uses a prefetched response for navigation, the design dispatches a credentialless HEAD request to that endpoint — a browser-generated signal that page script does not send or modify.

concepts

  1. Prefetch and activation, observed

    Inject a real Speculation Rules prefetch of a same-origin page, then navigate to it and inspect deliveryType === "navigational-prefetch". That proves this navigation consumed a prefetch; it does not prove the separate server-facing HEAD request fired.

    interactive

  2. The on-prefetch-activation header

    Build the header and speculation rules interactively and preview the proposed HEAD request properties — method, credential mode, and same-origin endpoint — with live origin-trial and Speculation Rules context. No request is sent.

    interactive

  3. Why not client-side JavaScript?

    The explainer rejects sendBeacon-on-load reporting as unreliable. See why live, using real visibilitychange, pagehide, and back/forward-cache pageshow events that make a client-side counter miss and double-count.

    interactive

why it shipped

Measuring whether a prefetch was actually used is hard. Client-side scripts can miss relevant visits, double-count lifecycle events, or race the navigation. The proposal moves dispatch into the browser navigation stack after commit and specifies that page script, the origin's service worker, and extensions do not intercept or modify it. This is intended to provide a more reliable server signal, but these demos cannot verify the server round trip. To limit tracking risk, the endpoint must be same-origin with the prefetched page, the request carries no credentials, and the browser only echoes the URL the server supplied.

references