Accessing Navigation Timing Data (Web Timing)

Accessing Navigation Timing Data (Web Timing)

Nov 21

  • Created: Nov 21, 2010 4:32 PM

W3C Navigation Timing
Accurately measuring webpage performance across different browsers has always been a challenge. While there are benchmarks that are often quoted (such as the SunSpider JavaScript Benchmark and the ACID3 compliance test), measuring total page load time has always been problematic. Luckily for developers, and the users who will eventually benefit from all the optimization work, the W3 has a specification to remedy this. Their solution is called “Navigation Timing” and it’s currently a work in progress, but it should be quite helpful.

To understand the real problem with measuring page load time, we must first look at the traditional (inaccurate) methods being used to accomplish this. Right now, if you want to time how long it takes for your browser to “load” (a loosely defined term) a page, you can insert a JavaScript timer into the <head> element of a page, and use the onLoad event handler to stop the timer. The process is detailed here, if you’re interested.

The issues with starting the timer at the <head> tag of a page are many. Some of the more prominent issues that affect the load time greatly are:

  1. Connection time: How long it takes to connect to the web server.
  2. DNS: Any DNS events; incorrectly configured DNS records can take a significant amount of time.
  3. Request: Some sites send a significant amount of data to a web app. This can take a while on a slow connection.
  4. Redirects: Redirects can be slow and force the browser to load more than one page.
  5. Fetch: This is the time it takes to actually download the page. On almost any connection, this is significant.
  6. Render: The time it takes the browser to actually “draw” the page on the screen.

Another issue which might not have a huge effect yet, but might in the future, is the analysis of web pages by the browser at render-time for further optimization. For example, an advanced implementation of WebGL might pre-process some objects on the page and delegate more intensive tasks to the GPU, such as playing a video. While Navigation Timing could take this into account, a normal JavaScript timer might not report these events accurately.

Navagation Timing, or more specifically, ‘window.performance.navigation’ and ‘window.performance.timing’ will probably be implemented in the major browsers (Mozilla FireFox, Internet Explorer 9, and WebKit [the engine in Chromium, Chrome, and Safari]). Although FireFox 4.0b8pre doesn’t include this functionality, Google Chrome 6 and higher (and the version of Chromium that I’m running, 9.0.584.0 [66224]) do, and apparently the latest preview of Internet Explorer 9 does, as well. In Chrome / Chromium / IE9, to see Navigation Timing data, you can either take the blue pill and check out the Navigation Timing Demo, or take the red pill and hit ctrl+shift+J in Chrome / Chromium. Once your javascript console opens, you’ll want to enter the following:

var performance = window.performance || window.mozPerformance || window.msPerformance || window.webkitPerformance || {};
var timing = performance.timing || {};
var navigation = performance.navigation || {};

Then just enter ‘performance’ into the JS console. Enjoy.

This technology is very promising for developers as it will, at long last, allow us to accurately measure what end-users are seeing in terms of performance. I’m sure that this, along with all the other cutting-edge technology in modern browsers, will help shape the future of the web as we know it.

Below is a preview of Navigation Timing in action

This specification is still a work in progress, but you can view the latest draft of it in a comprehensive guide here: http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html

Further Reading: