It’s All in the Timing: How to Use the Navigation Timing Specification to Improve Web Performance

This post is written by Darin Wright. Darin is a Principal Software Engineer at New Relic who works on all things related to RUM — collecting, aggregating, persisting, and presenting end user metrics.

The Navigation Timing Specification is a JavaScript API detailing the timing information of a page load. Available in most newer browsers (including IE 9, Chrome, and Firefox 10+), it helps developers test user experiences remotely and easily, and quickly optimize their websites and web apps for different types of users. We’ve recently started to leverage the API more heavily in our Real User Monitoring (RUM) feature. RUM captures a few key points in time in order to aggregate page load times:

* Navigation Start: When the user begins a navigation to a new page
* First Byte: When the requested page returns to the browser
* DOM Ready: When the page has been parsed into a DOM
* Page Ready: When the page has completed loading

In browsers that don’t implement the Navigation Timing specification, navigation start time is captured as a user exits the previous page (via the beforeunload event,) and written to a cookie. The value is read from the cookie as the next page loads. When the requested page arrives back in the browser, RUM estimates the first byte time via the execution of the RUM header (JavaScript injected into the top of a page) and DOM ready via execution of the RUM footer (injected into the bottom of the page.) The page ready time is captured via the window onload event.

However when a browser implements the Navigation Timing specification, RUM can get the timing information directly from the browser – without having to rely on cookies or the header and footer execution for estimates. You should notice that the RUM footer is still required for context information (account and application identifiers, host to report to, web transaction name, etc.)

Perhaps the most notable difference in the end result of the two measurement techniques is the relative breakdown of DOM processing and network time. Essentially, the traditional estimation of first byte time is late since it relies on the execution of the JavaScript header. The deeper into a page the header is positioned, the later the estimation becomes. However, overall page load times remain similar. The following diagram shows what happened to our site’s response time breakdown as we flipped the switch to use navigation timing data. We saw that network time shrinks, DOM processing time increases, and the overall response time remains the same.

Browser Page Load Time

Of course, the degree of change in a site’s aggregate page load breakdown will depend on how many browsers on the site support the Navigation Timing specification.

RUM builds more detailed browser traces from navigation timing data. The DOM processing segment found in standard traces is now broken into DOM loading and interactive segments. These reflect the document’s ready state. In addition to the traditional queue, web application, network and page rendering time segments, and traces built from navigation timing data may contain time spent in redirects, cache lookup, DNS, TCP, SSL, and reading the response off the network (when non-zero).

Performance for this Trace

Remember RUM will continue to work in all browsers with both measuring techniques. Over time, we expect that more and more browsers will implement the Navigation Timing specification. This will simplify your data collection and provide you with a more detailed view of end user response times.'

Marketing Manager, Content View posts by .

Interested in writing for New Relic Blog? Send us a pitch!