[pierrefar]

Just a heads up, and the post notes this, that this way of timing is already well into the page load sequence: the server has received the request, built the HTML and has started sending it, and the browser is already parsing it.

Also, be careful with when different browsers fire the onLoad event. For example, Safari 3: http://www.howtocreate.co.uk/safaribenchmarks.html

Overall though, a cool hack even with the caveats above as it could give you actionable data.

Another good source of loading time metrics is Google Webmaster Tools. They have two metrics, one in the download time in the Crawl Stats section the Site Performance metric in the Labs section. Combined, they give you a really good insight into how your website is doing over time. A good game to play is spot the (very clear) inverse relationship between the number of pages crawled vs download time.

[jrosoff]

Yes definitely some issues with measuring page load time this way. It is useful data to get started with. The web timing API will make this data much better, but it's still early (it's in IE9 and some early developer builds of chrome and firefox). Once this API is more widely deployed, this is the right way to measure performance as it allows you to take into account navigation time as well as rendering time.

Google Webmaster Tools does indeed give you a good perspective on performance. I believe this data comes from the google toolbar (can someone confirm this?). My problem with the data reported by webmaster tools is that it's an average. It doesn't tell me what the _worst_ page load time of the _best_ page load time my users are experiencing.

As a shameless plug, you can also check out our own tools from yottaa: http://www.yottaa.com that give you a bunch of detailed information about your websites performance. I think tools like these complement the approach detailed in the post.