Improving Web Performance using Navigation Timing Specification
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.
* 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
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.)
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).
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)