UPDATE 2011-09-29:

Finally! On Tuesday — six months after I wrote this post about Chrome and IE9 support — Firefox 7.0 was released, with support for the W3C Nav Timing API: https://www.mozilla.org/en-US/firefox/7.0/releasenotes/. Now the big three desktop browsers all allow granular measurements of various performance-related metrics from within a page. This is a great step forward in making real-world, in-browser performance measurement ubiquitous. However, at a glance it seems Safari isn’t yet enabling the API, even though webkit supports it. If anyone reading this knows why and cares to comment, I’d be interested to hear. Thanks! (Original post follows below.)

This was a big week for the major desktop browser vendors. Microsoft released IE9 at the SXSW event in Austin. Google updated Chrome to version 10. Mozilla published what appears to be the final release candidate for Firefox 4. Each of these releases contains performance improvements of varying significance, which is good news for users and for a faster web. One of the features introduced in IE9 is of particular interest to those of us in the web performance optimization world: support for the
W3C Navigation Timing API.

DISAPPOINTMENT

To be honest, when I set out to write this post [in mid-March 2011] I had expected to celebrate support for this highly useful performance measurement API finally reaching all three of IE (9), Firefox (4) and Chrome (since version 6!). But even though early development builds of Firefox included support for window.moz Performance – leading those of us paying attention to believe it’d be supported at launch – it looks like the Mozilla team has decided not to include this support in the final 4.0 release. It’s a real shame, given how useful it is in understanding the actual user-perceived latency for web pages. It also represents a missed opportunity for Firefox to keep up with IE. [For the record, I don’t think I have ever written a sentence like that! I’ve been a big fan of FF ever since version 0.8, way back in 2004.] In any case, it is great to see support for Navigation Timing released in a big mainstream browser like IE9. I hope to see Mozilla follow suit in a 4.x point release sometime soon.
[Update: w00t! They finally did, in FF 7.0.]

Mainstream Browsers that Support Navigation Timing API (as of Sept. 29, 2011)

THE PROBLEM

Why is it a big deal? Well, the mechanisms for capturing page performance metrics from within real browsers have always suffered from the fundamental limitation of using a script within a page to time how long it takes that page to load. Such scripts can only begin the timer after the page has been retrieved from the server. There are of course a number of time-consuming things that happen after a user requests a URL and before the browser starts executing scripts in the resulting page, such as: DNS resolution; any SSL handshaking; sending potentially heavy request headers; waiting for the server to process the request and send its response; suffering any number of redirects that starts the process over again; and, finally, actually downloading the page. All of this takes time, which is completely ignored by typical in-page script timers. Solutions involving setting a cookie in a previous page when a navigation event occurs can help account for this hidden latency, but – critically – they are helpless to measure the delay in the very first page request to a site. So for anyone working to measure and report on actual user-perceived performance, there’s always been this fundamental gap.

THE SOLUTION

Enter the W3C Navigation Timing API. This is an interface that exposes all these performance details which the browser can know about (e.g., when the navigation event actually began, DNS resolution times, etc) but which are otherwise inaccessible to scripts within a given page. The API spec was just finalized a couple days ago (reaching official “”candidate recommendation”” status on March 15, 2011), but it has been in quite stable form for some time now and is highly useful as already implemented by Chrome and IE9. Here is a graphical depiction of the HTTP request/response/load lifecycle from the browser’s perspective, and where each of the 20 new timing measurements fits in:

(courtesy w3.org)

If you’re using Chrome 6+, you can see it in action here: https://webtimingdemo.appspot.com/

(Note that demo page seems to work in Chrome but not in IE9. If you’re using IE9, try this demo page instead: https://ie.microsoft.com/testdrive/Performance/msPerformance/Default.html)

Note the “”legacy navigation started”” time, which happens long after the user has started navigation and is waiting, and it becomes clear how flawed old-fashioned script timers really are. This is not to say they’re useless – typically, 80-90% of user-perceived latency occurs after the document has been retrieved from the server – but these new timings are really critical if we’re to accurately measure and understand the user experience.

HERE AT YOTTAA

One of the ways we are using the Navigation Timing API at Yottaa is in our work with private beta customers using Google Analytics. A couple months ago we wrote about using a JavaScript timer and Google Analytics custom variables to capture “”Direct UX”” page load measurements in GA. We’ve since updated that script to leverage the Navigation Timing API for those browsers that support it, and are working to pull that data back out of GA automatically and to visualize it in the Yottaa.com dashboard. I plan to write more on that sometime soon.

FEEDBACK

Do you share my enthusiasm for the Navigation Timing API? Are you psyched it’s in IE9 and now FF7? Any idea about Safari and Opera? Are you making use of it (or planning to) in your own performance measurements? Comment below or drop me a line if you have thoughts to share!