The first rule of benchmarking: make sure you know what you actually measured
Google Analytics has a very handy "Site Speed" report which measures the average load time for your pages as seen by your users. Unfortunately, there are two implementation details which are important to keep in mind:
- The reports are heavily based on the average load time, which can skew the results pretty heavily: one multi-minute load time from someone in Haiti on a satellite connection outweighs quite a few users with .8 second load times. There is a bucket report but it's a bit clunky and there's no easy way to get the data out to run your own stats. Even a simple switch to using the median would make this report less ominous at first glance and it'd be a really good use for some sort of distribution graphic.
The more interesting problem is that Google Analytics uses the W3C Navigation Timing API and reports only the value of
window.performance.timing.loadEventStart - window.performance.timing.navigationStart. The browser won't fire the load event until all resources on the page have been loaded including external services like Google Analytics. Unfortunately, you will find situations where http://google-analytics.com/ga.js takes a considerable amount of time to respond (yesterday I had 40 second response in a webpagetest.org session) and this will be reflected in your stats even if the page loaded considerably faster from the user's perspective.
I'm currently experimenting with deferring loading Google Analytics until after the load event using this code. Initial testing appears promising and the elapsed time to load everything else is definitely more accurate:Relying on NavigationTiming does mean that you won't receive any information from older versions of Internet Explorer unless they have the Google Toolbar installed, which means some of your worst-performing clients will be invisible. Chrome Frame would be my preferred response…