Summary

  • W3C's first public Navigation Timing draft appeared on 26 October 2010; the 17 December 2012 Recommendation gave web pages browser-recorded milestones from navigation through network and DOM work.
  • The interface exposed an itemized clock. Applications still had to decide what to collect, compare and repair, while cache reuse and cross-origin redirects shaped what the clock could show.

The browser checks into the hotel long after the journey began. The clerk at the desk starts a stopwatch, watches the guest walk to a room, and announces a brisk check-in. The guest has already waited for a taxi, searched for the address, queued at the door and stood outside while someone found the keys. A stopwatch started in the lobby cannot explain the trip.

That was the opening complaint in W3C's first public Navigation Timing Working Draft of 26 October 2010. A script near the top of a page could mark the time when it ran and subtract that from the load event. It still missed the interval before the script arrived: navigation, connection and the server's delivery of the document. To the person waiting for the page, those seconds were as real as the script's seconds. To the old stopwatch, they were off the books.

The draft proposed a browser-maintained starting point, navigationStart, and a sequence of further stamps. The first simple calculation was almost comically satisfying: take the time at load and subtract performance.timing.navigationStart. The page could finally begin counting when the trip began, not when the hotel clerk happened to look up. The draft described the interface; it left collection, storage and reporting to the application. The browser supplied the clock, while the service decided whether to keep a diary.

The value was in the divisions. fetchStart marked the beginning of fetching or checking a relevant cache. domainLookupStart and domainLookupEnd located name lookup. connectStart and connectEnd bracketed the connection. requestStart, responseStart and responseEnd showed the document request and arrival. Later stamps described when the document began loading, became interactive, completed its DOM work and fired its load event. One impatient number became a sequence of questions: was the address slow to resolve, did the connection take time, did the response arrive late, or did the page then take its own leisurely stroll through the DOM?

The 2 June 2011 Candidate Recommendation shows the idea moving through the standards process; the 17 December 2012 Recommendation fixes the familiar PerformanceTiming vocabulary. W3C's publication history records the route from the October 2010 draft through the 2011 candidate snapshots to the 2012 Recommendation. The dates matter because the receipt acquired firmer rules as it traveled. A time printed on a bill is useful only if the buyer and seller agree what it measures.

Those rules made the bill subtler than a string of always-positive durations. A reused connection could make the connection fields coincide; a cache hit could do the same for earlier network stages. A zero or equal timestamp was therefore sometimes an account of reuse, not a broken clock. The Recommendation also required a monotonic time base so a system-clock adjustment during navigation could not make elapsed stages run backward. A guest may complain that the elevator is slow. An elevator arriving before it left would require a different investigation.

The document took care with doors it could not safely open. If a redirect crossed origins, the detailed redirect fields were zeroed rather than turning the new page into a spy on the old route. Even on the same host, the Recommendation noted that different authors sharing an origin could see timing from each other's paths. That is a concrete boundary around a useful measurement interface, not a mystery tax on performance work. The page gets a receipt for its own journey, with some lines deliberately left blank.

The first draft made another useful limit explicit: this interface was not intended as a benchmark for browsers. A page load on one device, network and application is a diagnosis of that trip. It cannot settle a contest between browser brands by itself. The browser also did not phone the data to anyone or make a slow site fast by revealing its minutes. A developer had to choose a sample, a question and a fix. The standard took the blame game out of the lobby; it did not repair the elevator.

What changed was the location of knowledge. The browser already saw the navigation and the document's transitions. The page, arriving later, could not reconstruct them with a stopwatch in its own script. Navigation Timing gave that first-hand account to the application in a shared format. Once the receipt existed, a service could stop asking whether a page merely “felt slow” and start asking which part of this visit had kept its reader waiting.