Do You Know How Slow Your Web Page Is?
Wednesday, July 28, 2010
Labels: googlechrome, New Features, webkit, webtiming
The Web Timing draft specification presents a standard set of metrics for measuring web page load time across browsers. We’re happy to announce that in Chrome 6, web developers can now access these new metrics under window.webkitPerformance.
Measuring web page load time is a notoriously tricky but important endeavor. One of the most common challenges is simply getting a true start time. Historically, the earliest a web page could reliably begin measurement is when the browser begins to parse an HTML document (by marking a start time in a <script> block at the top of the document).
Unfortunately, that is too late to include a significant portion of the time web surfers spend waiting for the page: much of the time is spent fetching the page from the web server. To address this shortcoming, some clever web developers work around the problem by storing the navigation start time in a cookie during the previous page’s onbeforeunload handler. However, this doesn’t work for the critical first page load which likely has a cold cache.
Web Timing now gives developers the ability to measure the true page load time by including the time to request, generate, and receive the HTML document. The timeline below illustrates the metrics it provides. The vertical line labeled "Legacy navigation started" is the earliest time a web page can reliably measure without Web Timing. In this case, instead of a misleading 80ms load time, it is now possible to see that the user actually experienced a 274ms time. Including this missing phase will make your measurements appear to increase. It’s not because pages are getting slower – we’re just getting a better view on where the time is actually being spent.
Across other browsers: Web Timing metrics are under window.msPerformance in the third platform preview of Internet Explorer 9 and work is underway to add window.mozPerformance to Firefox. The specification is still being finalized, so expect slight changes before the browser prefixes are dropped. If you’re running a supported browser, please try the Web Timing demonstration and send us feedback.


10 comments:
Wim Leers said...
Excellent! Then I'll be able to achieve greater accuracy in the conclusions that my WPO Analytics software will generate.
I'm basically building Google Analytics for WPO (Web Performance Optimization) for my master thesis: http://wimleers.com/blog/master-thesis-proposal-web-performance-optimization-analytics
Thanks for bringing support for the Web Timing spec to Chrome/WebKit! :)
July 28, 2010 2:28 PM
Blues said...
Nice. Boomerang (http://github.com/yahoo/boomerang/) already supports the IE9 implementation of WebTiming. I'm gonna go add the chrome version now.
We also support chrome.csi() for older versions of chrome.
July 28, 2010 6:49 PM
avindra said...
Thanks for deleting my comment about Firebug. Very neutral of you, Chrome.
July 29, 2010 9:56 PM
Ajay Kumar Singh said...
This is good news. There was really no way to find out page load time quickly without resorting to external tools. Knowing page load time from browser itself would be helpful to optimize the page for faster loading.
Looking froward for the relese date.
July 30, 2010 12:42 AM
Ian Fette said...
@avindra, I deleted your comment "firebug ftw" because it, like many other comments (such as "please implement the stop/reload button in this manner") were off topic for the post. I can assure you, it's not because of any feelings for or against Firebug - Firebug is awesome, but that's really orthogonal to this post.
July 30, 2010 10:37 AM
tonyg said...
@Ian Fette: "firebug ftw" was not a particularly coherent comment, but @avindra actually brings up an interesting point.
There are plenty of awesome developer tools that provide much greater detail about web page performance than the Web Timing spec (Firebug, SpeedTracer, HTTPWatch, etc).
But Web Timing serves an entirely different purpose. The goal of Web Timing is to always expose timing metrics to the DOM so that a web site can gather statistics about its performance for real users "in the wild." It isn't meant to be used during the development cycle.
July 30, 2010 11:11 AM
Alexsandro_xpt said...
Good tools, I will test it on my web sites.
July 31, 2010 2:22 PM
Henrik said...
What I do know is that whenever I push the "Back" button, after clicking a link, it takes 10-20 seconds before the previous page has re-loaded. Why don't you provide an option, that the previous page is not re-loaded, but immediately taken from the cache memory? Hint: try Opera Mini
August 11, 2010 2:20 AM
Victor Guerra said...
So I downloaded Chrome 6 beta in order to give it a try but while doing some testing, I noticed that some attributes on the NavigationTiming interface are missing ( whatever missing means, at least they are mentioned in this draft http://dev.w3.org/2006/webapi/WebTiming/#navigation-timing ) : domLoading, domInteractive, domContentLoaded and domComplete.
So I was just wondering if this attributes will be supported in feature beta releases?
September 2, 2010 7:51 AM
tonyg said...
@Victor Guerra: Yes, the dom* timing marks are a relatively recent addition to the spec. They will be implemented by Chrome.
September 21, 2010 9:14 AM
Post a Comment