Navigation Timing API

The W3C-sanctioned Navigation Timing API provides access to a built-in DOM object that contains timing data for a sequence of about twenty events, encompassing nine stages in the processing of a new web page request from the point of view of the web client. The nine processing stages that take place inside the web browser to load a new page are:

  • Prompt for unload
  • Redirect
  • App cache
  • DNS lookup
  • TCP connection handshaking
  • Request
  • Response
  • Processing
  • Load event

The DOM’s built-in Timing object contains a set of Properties marking the beginning and end of each processing stage, plus a few additional timers. The complete set of timing events from the NavTiming spec, and the processing stage they are associated with, is depicted in Figure 11.

NavTiming Drawing

The NavTiming API establishes a performance object associated with the window object of the DOM that has two sets of properties, one for timing the window load events and one detailing the navigation sequence. The timing object contains a timer value for each of the properties shown in Figure 11 corresponding to the sequence of events associated with page composition. The timer values are standard JavaScript timestamps, calibrated in milliseconds from the zero date, which is January 1, 1970. Subtracting the navigationStart value from loadEventEnd time gives the Page Load time in milliseconds.

Other useful metrics that can be obtaining from the window.performance object’s properties include the network latency or network delay time, which is interpreted as the time between the fetchStart and requestEnd timers. In addition, the time to first byte can be calculated by subtracting the responseStart timestamp from navigationStart. Note that performance analysts associated with web page caching and TCP/IP networking hardware and software sometimes prefer to focus on the Time to First Byte measurement because that is the portion of the page composition process that web page caching and network optimization can influence directly. The overall Page Load time measurement is more meaningful to the web application developers that are in a position to determine the size and complexity of the entire web page composition process.

Finally, the browser page composition and render time can be calculated as the time between the responseEnd and the loadEventEnd timer value. Note that not all requests have delays due to redirects, or for DNS look-ups or TCP connection handshaking, so it is not unusual to see timer duplicate values of some of the timers. The most commonly used web application response time measurements that are derived from the NavTiming’s window.performance object are summarized in Table 1.



Page Load time loadEventEnd navigationStart
Network delay time requestEnd fetchStart
Time to First Byte responseStart navigationStart
Render time responseEnd – loadEventEnd


The JavaScript code to access the timing values for Page Load events is trivial, as illustrated in Listing 1, and all recent releases of the major browsers support the standard.

Prior to the navigation timing API, it was possible to gather basic Page Load time measurements by subscribing to the DOM window.unload and window.load events and gathering timer values in JavaScript code when those events were raised. The fact that the window.unload event that occurs when a new GET Request is issued fires in the context of processing the previous web page presents some difficulty, however. Since the HTTP protocol is stateless and connectionless by design, there was no reliable mechanism built into the browser to feed a start timer value gathered for the previous Request forward to the subsequent Request.

A solution to this difficulty was to store the timer value for the window.unload event in a cookie so that it is passed in the subsequent GET Request, where it can then be retrieved by a window.load event handler. However, cookies are not an entirely foolproof method that a JavaScript-based timing script can use to pass the timer value from the window.unload event since there are visitors that choose to disable them out of privacy concerns. In the interest of helping Google Analytics gather measurement data reliably, Chrome supported a proprietary extension to the DOM called, a precursor of the NavTiming API. In addition, whenever the Google Toolbar was installed inside web client program other than Chrome, the Google toolbar also enabled the object.

Prior to the NavTiming API, it was also difficult to negotiate the discrepancies among different browsers, some of which were due to underlying architectural differences. However, since the navigation timing API was adopted by the developers of the main browsers, all the major discrepancies seem to have been resolved. While the specific browser implementations are largely consistent, you will still notice some minor differences in the order in which certain events fire in different browsers.

The NavTiming API also established a standard DOMHighResTimeStamp type that is consistent with 100 nanosecond timer ticks in Microsoft Windows and a method to retrieve the current time. (If the underlying OS is not Windows, however, DOMHighResTimeStamp values revert to milliseconds.)


Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *