Performance Zone is brought to you in partnership with:

Leigh has been in the technology industry for over 15 years, writing marketing and technical documentation for Sun Microsystems, Wells Fargo, and more. She currently works at New Relic as a Marketing Manager. Leigh is a DZone MVB and is not an employee of DZone and has posted 106 posts at DZone. You can read more from them at their website. View Full User Profile

Improving Web Performance using Navigation Timing Specification

10.23.2012
| 4203 views |
  • submit to reddit

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.

Published at DZone with permission of Leigh Shevchik, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ju Peter replied on Thu, 2012/11/29 - 1:59am

 Such a good idea for improving web performance and easy to use and work in all browsers.

Dew point transmitter

Krish Kumar replied on Tue, 2012/12/18 - 7:58am

 Information looks useful to add in project and make different from other to shown in college session.thanks for the useful information.

hrms saas model

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.