PerformanceNavigationTiming.redirectEnd

Syntax

// PerformanceNavigationTiming (normative IDL, Navigation Timing)
readonly attribute DOMHighResTimeStamp redirectEnd;

// Read it from the navigation entry:
const t1 = performance.getEntriesByType("navigation")[0].redirectEnd;

Inputs

A read-only attribute — no page inputs. Its value follows the entry's redirect count: the getter returns 0 when the redirect count is 0, so everything that gates redirectCount exposure (the every-hop opt-in via Timing-Allow-Origin once any cross-origin redirect exists, and the no-referrer gate that only applies to such chains) gates this timestamp identically.

Outputs

A DOMHighResTimeStamp in milliseconds, relative to the time origin. The getter steps: if the entry's redirect count is 0, return 0; otherwise return the stored redirect end time. Navigation Timing notes that unlike PerformanceResourceTiming, the navigation versions of redirectStart/redirectEnd return zero for navigations with (non-exposed) cross-origin redirects.

Errors

No exceptions. As with redirectCount, 0 is ambiguous — it means “no redirects”, or “redirects not exposed”: a chain with cross-origin redirects where some hop withheld the opt-in, or such a chain navigated no-referrer with a non-null client. Do not subtract 0-valued fields: guard on redirectCount > 0 (or on the timestamp being non-zero) before computing chain duration.

Context

Receiver: the document's PerformanceNavigationTiming entry (the "navigation" entry in the performance timeline), in window contexts.

Implementation: Chromium's getters in performance_navigation_timing.cc return 0 unless the load's cross-origin-redirect-timing exposure flag is set. Availability: the cross-origin exposure is Chrome 151 per the milestone listing; runtime feature NavigationTimingRedirectTimingViaTAO (status stable at trunk). The attribute itself long predates the feature as part of Navigation Timing.

Lifecycle

The timestamp is captured by fetch while the redirect chain runs and fixed when the navigation timing entry is created at document commit; it never changes afterwards. It marks the end of the chain — pair it with redirectStart for total redirect time, and with fetchStart for the time from chain end to the final fetch.

Examples

const [nav] = performance.getEntriesByType("navigation");
if (nav.redirectCount > 0) {
  const chainMs = nav.redirectEnd - nav.redirectStart;
  console.log(`${nav.redirectCount} redirect(s) cost ${chainMs.toFixed(1)} ms`);
  // redirectStart is non-zero here by construction (getter guarantees it).
} else {
  // redirectEnd is 0: no redirects, or the chain was not exposed.
}

Compatibility

BCD tracks the general attribute under api/PerformanceResourceTiming.json (Chrome 43, Firefox 35, Safari 11) — it has no entry for this cross-origin exposure. Feature signals: ChromeStatus API feature record.

Security and privacy

The timestamp participates in the same consent boundary as redirectCount: cross-origin chain timing is disclosed only when every redirect operator opted the destination origin in, and — for chains with cross-origin redirects — never for no-referrer navigations with a non-null client. Timing of redirects can reveal infrastructure details (how many hops, how slow), which is why the default remains zero.