Prefetch activation beacon

at a glance

why it exists

Sites that use the Speculation Rules API need to know how often their prefetches actually pay off. Today that measurement relies on client-side JavaScript (for example a sendBeacon fired when the page becomes visible), which the explainer rejects as unreliable for three reasons:

• Cache ambiguity — telemetry often filters back/forward navigations to avoid double-counting, but back/forward navigation to prefetched pages is then missed entirely.
• Duplicate reporting — cache restores can re-run scripts, producing duplicate activation signals and wrong attribution.
• Race conditions — scripts often fail to execute early enough to capture rapid page transitions.

Because the activation beacon is dispatched directly by the browser's navigation stack when a prefetch is consumed, it is immune to all three failure modes: no script executes, no Service Worker boots, and no extension can block, delay, or tamper with the signal.

syntax

The server includes the header on the response to the speculative (prefetch or prerender) request. The value is the relative URL of the telemetry endpoint:

on-prefetch-activation: <relative-endpoint-path>

Key properties of the grammar:

• The value is a relative URL resolved against the prefetched page's URL — the reported endpoint is always same-origin with the prefetched page (see origin boundaries).
• The server can embed its own identifiers (for example an event id) as URL parameters; the browser echoes them back verbatim and adds nothing of its own (the “echo back” principle).
• Only the header on the final response is honored when the speculative request redirects; headers on intermediate redirect responses are dropped (see redirect rules).

browser mechanism

1. The browser process consumes the header from the prefetch response and associates the endpoint URL with the prefetched document in its internal cache.
2. Activation is defined as the point at which a document loaded via a speculative trigger transitions to the active state in its browsing context — typically when a user-initiated navigation is satisfied by the previously prefetched response.
3. The beacon is dispatched after the navigation commits (post-commit dispatch), so the signal means the page was actually shown to the user, not merely speculated.
4. The browser sends a credentialless HTTP HEAD request to the endpoint — no cookies, no authentication headers, no stored credentials.
5. Dispatch is non-interceptable: it does not pass through the origin's Service Worker, cannot be observed or modified by client-side JavaScript, and cannot be blocked by browser extensions.

endpoint lifetime and devalidation

To prevent “zombie” beacons from unrelated navigations, the activation trigger has a deliberately short, scoped lifetime:

The explainer's three canonical scenarios:

• Same-origin prefetch and activation — the user loads a.com/, which prefetches a.com/target; the beacon is sent when the user then navigates to a.com/target.
• Cross-origin prefetch and activation — a.com/ prefetches b.com/target; the beacon is sent (to the b.com endpoint only) when the user navigates to b.com/target.
• Devalidation on navigating away — a.com/ prefetches a.com/target, then the user navigates to c.com; the beacon is not sent when the user later navigates to a.com/target.

The same rules as a state summary:

active speculative context + committed navigation → beacon sent once → trigger devalidated
referrer navigated away before activation        → activation metadata discarded (no beacon)
speculative context expired (disk-cache hit)     → no beacon
second navigation to the same prefetched page    → no beacon (one-time use)

origin boundaries

To prevent the API from becoming a cross-site tracking vector, the reporting endpoint must be same-origin with the prefetched page:

• If the browser prefetches target.com on the user's initiative, the beacon can only go to an endpoint on target.com.
• If referer.com prefetches target.com, the beacon can still only go to target.com — reporting back to referer.com or any third party other.com is prohibited.

Only the site being prefetched — which already learns that the user visited — receives the signal.

redirect rules

coverage: prefetch, prerender, and explicit non-goals

The Chromium runtime feature is named PrefetchAndPrerenderActivationBeacon and WPT carries both a prefetch and a prerender activation-beacon test, so the feature covers both Speculation Rules load types. One explainer sentence — that the beacon fires when the navigation “is successfully committed in a non-prerender context” — reads against that; the redirect section, the flag name, and the prerender WPT all treat prerender activation as in scope. gendn records the wording difference rather than resolving it.

Explicit non-goals (the header has no effect here):

• Legacy <link rel=prefetch> / <link rel=prerender> loads — those are being deprecated in favor of the Speculation Rules API.
• Subresource prefetches (images, scripts) — “prewarm” mechanisms or specialized APIs are the intended measurement path.
• Acting as a dynamic data channel for arbitrary client-side state — the beacon only ever reports the server-defined activation event.

examples

A server opting a prefetched page into activation reporting:

# Response to the speculative (prefetch) request
HTTP/1.1 200 OK
Content-Type: text/html
on-prefetch-activation: /telemetry/prefetch-hit?rule=product-page&id=92

When the user later navigates to that prefetched page and the navigation commits, the browser sends — once, with no cookies or authorization headers:

HEAD /telemetry/prefetch-hit?rule=product-page&id=92 HTTP/1.1
Host: shop.example

The page that issues the speculation needs nothing new beyond its normal speculation rules (plus the origin-trial token):

<script type="speculationrules">
{
  "prefetch": [{ "urls": ["/products/92"] }]
}
</script>

security and privacy

• “Echo back” principle — the browser conveys no new client-side information: it echoes only the URL and parameters the server itself provided. The API generates no identifiers (Questionnaire §2, §13).
• Static & non-modifiable — the beacon URL comes from an HTTP header, so third-party JavaScript cannot read or rewrite it and cannot inject tracking identifiers into it.
• Origin boundaries — the endpoint is same-origin with the prefetched page; cross-origin reporting is prohibited and cross-origin beacon redirects are blocked (see origin boundaries and redirect rules).
• Credentialless — no cookies, authentication headers, or stored credentials, so the beacon cannot join user sessions across security contexts.
• No persistent state — activation metadata is scoped to the speculative loading context and discarded on expiry; nothing persists across sessions (Questionnaire §6).
• No new script execution — the beacon runs in the browser navigation stack; it boots no Service Worker and runs no page script (Questionnaire §10).

error and edge behavior

web platform tests

The feature has upstream (tentative) WPT coverage under speculation-rules/activation-header/:

• prefetch-activation-beacon.tentative.https.html — prefetches a URL served with the header, navigates to it, then polls a server-side stash to assert the beacon was received (and the resource was actually fetched).
• prerender-activation-beacon.tentative.https.html — the same flow through a prerender triggered by speculation rules.
• resources/activation_beacon.py — the test server: emits on-prefetch-activation with a relative URL, and rejects any beacon request whose method is not HEAD with a 405.

Both tests are tentative, matching the feature's pre-ship status.

browser compatibility

Interim table. There is no BCD entry (BCD http/headers/ has no on-prefetch-activation.json, verified 2026-07-28) and no web-features entry (webstatus.dev query, zero matches). Rows below are compiled from the linked primary sources, not from BCD.

specifications

see also

• Chrome Platform Status — Prefetch activation beacon (API record)
• blink-dev — Intent to Prototype: Prefetch activation beacon (mail-archive mirror)
• blink-dev — Intent to Experiment: Prefetch activation beacon (mail-archive mirror)
• MDN — Speculation Rules API (the host API; MDN does not cover this header — MDN header URL 404, search returned no matching document, 2026-07-28)
• Chrome origin trials console (trial PrefetchAndPrerenderActivationBeacon, id 3433431765916581889)
• Chrome Platform Showcase — interactive demo for this feature