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
- App cache
- DNS lookup
- TCP connection handshaking
- 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.
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|
TABLE 1. WEB APPLICATION PERFORMANCE MEASUREMENTS COMMON DERIVED FROM THE WINDOW.PERFORMANCE OBJECT’S PROPERTIES.
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 performance.now() method to retrieve the current time. (If the underlying OS is not Windows, however, DOMHighResTimeStamp values revert to milliseconds.)