navigation timing milestones run in their spec-defined causal order

Check id nav-timing-order

What an ordinary browser yields

Every non-zero milestone occurs at or after the one before it, and none is later than performance.now().

What a detector infers

Akamai Bot Manager v2 devotes an entire signal category to timing — navigation timing, resource timing, first paint, DOM-ready — and this audit had no coverage of it at all. What makes the surface worth reading is that its milestones are not free-floating numbers. The Navigation Timing specification defines them as a causal sequence: fetching starts before the domain is looked up, the request is sent before the response arrives, parsing finishes before load fires. So the check reads the PerformanceNavigationTiming entry and asserts only the order, which the browser wrote as the load actually happened. Fabricating convincing timings means fabricating an entire partial order rather than a handful of plausible durations, and an order is far harder to get right. Three details keep it honest. Zeros are dropped rather than compared, because a milestone that legitimately did not occur reports zero — redirectStart with no redirect, secureConnectionStart on plain http, workerStart with no service worker — and comparing those would fail every ordinary page. The assertion is non-decreasing rather than strictly increasing, because a reused or cached connection collapses the lookup and connect milestones onto requestStart, and equal timings are normal. And nothing may sit in the future: every milestone shares a clock with performance.now(), so a milestone beyond now() is not a slow page but a fabricated one. This is the rare reference the audit can afford, because the ordering comes from a specification rather than from a table of observed values — it can go quiet on a browser that exposes no entry, but it cannot go stale.

How to resolve it

Let the browser report its own load. Navigation timing is written as the page actually loads, so the milestones are a causal chain rather than a set of independent numbers — a response cannot precede its request. Rewriting the entries to look realistic means reproducing that whole order, including the zeros that correctly appear for a redirect that never happened or a connection that was reused.

How is a headless browser detected?

Nearby checks in Screen & display

See all 15 checks in Screen & display

Run this check on your browser All 197 checks How the test works

Who builds this test

Clearcote is a browser built for fingerprint coherence

It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.

This audit takes no position on how Clearcote scores on Screen & display checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.

See the other checks in Screen & display — the family nav-timing-order belongs to.