Cross-origin redirect timing opt-in

at a glance

Member reference

The developer-facing surface is one protocol element and three timing attributes, plus the fetch bookkeeping and algorithms that connect them. Each has stable detailed reference covering syntax, inputs, outputs, errors, context, lifecycle, examples, compatibility, and security/privacy:

• Timing-Allow-Origin on navigation redirects — the response header that opts a redirect forward into measurement by the destination origin
• PerformanceNavigationTiming.redirectCount — the chain length, now exposed for opted-in cross-origin chains
• PerformanceNavigationTiming.redirectStart — when the first redirect began (zero unless the chain is exposed)
• PerformanceNavigationTiming.redirectEnd — when the last redirect's response arrived (zero unless the chain is exposed)
• navigation timing allow values list — the request/response bookkeeping: per-redirect collection (append) and the final-response clone
• navigation TAO check — the algorithm that decides, once the destination origin is known, whether every redirect allowed it

How the opt-in works

For subresources, Timing-Allow-Origin has always opted backwards: a response names the requesting origins allowed to measure it. For a navigation, the meaningful opt-in runs the other way — the page that lands (the destination) is the one that wants to measure, and each redirect in the chain must allow it. The merged Fetch change therefore records every redirect response's Timing-Allow-Origin values during the chain and, once the destination origin is known, runs the navigation TAO check: every redirect must have named either * or the destination's serialized origin, or the chain stays opaque.

Two more boundaries from the normative text. First, the exposure conditional only engages when the chain has cross-origin redirects: a purely same-origin chain always exposes its real values, regardless of referrer policy. When the chain does include a cross-origin redirect, exposure requires both that the request's client is null or its referrer is not no-referrer, and that the navigation TAO check succeeds. Second, that check runs over every redirect response in the chain — including same-origin hops: once any cross-origin redirect exists, a hop that sends no Timing-Allow-Origin (or names neither * nor the destination) fails the whole chain, and the destination sees redirectCount === 0 and zeroed redirect times, exactly as before.

Examples

// On the destination page: read the navigation's redirect timing.
const [nav] = performance.getEntriesByType("navigation");
if (nav.redirectCount > 0) {
  // Every redirect in the chain opted this origin in via Timing-Allow-Origin.
  console.log(`${nav.redirectCount} redirect(s), chain took`,
    nav.redirectEnd - nav.redirectStart, "ms");
} else {
  // No redirects, OR at least one cross-origin redirect did not opt in,
  // OR this was a no-referrer navigation — the fields stay zero by design.
}

Browser compatibility

BCD has no entry for this opt-in (checked 2026-07-26) — its redirectCount entry (in api/PerformanceNavigationTiming.json) and redirectStart/redirectEnd entries (in api/PerformanceResourceTiming.json) cover the general properties, which predate and do not imply this feature. On webstatus.dev the query resolves to the broader Baseline Navigation timing feature (widely available) — not evidence about this addition, which has no distinct entry. The table below is an interim view from ChromeStatus, labelled as such.

Vendor signals come from the ChromeStatus API feature record (checked 2026-07-26): Firefox “No signal”, Safari “Positive”, web developers “Positive” (as labelled on the ChromeStatus feature entry). For the general property's BCD entry see BCD api/PerformanceNavigationTiming.json.

Specifications

See also

• whatwg/fetch PR #1931 — Add TAO destination check for navigation redirect chains (merged)
• whatwg/html PR #12513 — Expose redirectCount for TAO opted-in redirect chains (merged)
• w3c/navigation-timing issue #215 — the redirectCount exposure request these PRs resolve
• WebPerfWG meeting 2026-06-04 — where the forward opt-in was aligned
• Chromium runtime_enabled_features.json5 (NavigationTimingRedirectTimingViaTAO, stable)
• MDN — PerformanceNavigationTiming: redirectCount (general property; MDN does not cover this opt-in as of 2026-07-26)
• Chrome Platform Showcase — Cross-origin redirect timing opt-in (also: timing API probe)