News of the recent release of an asynchronous version of the Google Analytics code is timely since it is no doubt a step to ensure that Google assist with improving site load times. It has initially however, filled me with mixed emotion!
First of all let’s put this into context. Back in November Matt Cutts of Google stated at PubCon that search engine ranking will also take into consideration page load times. To me, this is great and makes a lot of sense. If page load time improves user experience then I agree that search engines should serve this site content before a site that has a poorer user experience.
My own caveat is that I am not totally convinced that user experience should be judged entirely on the speed of page load. I would much rather wait for a few milliseconds (even up to a couple of seconds) longer to see a well presented page with beautifully designed interactive elements. It would be a shame to suffer a penalty for serving this sort of quality, conversion friendly content and have bare,text-heavy pages benefit. I realize this is about quality coding, but lets not mistake light pages for quality user experience.
My mixed emotion is this. On the one hand, I am happy! Good user experience is being rewarded! Gold star Google for improving their own Analytics code to improve page load time. On the other hand however, when you have many hundreds of profiles to manage the thought of changing every tracking code is daunting, if not downright frightening. So lets have a look at this new code and measure the impact on pageload time! Does it really help improve page load time that much?
The New Google Asynchronous Analytics Code vs The Standard Code Found on Most Sites
Step 1) For this test I’m using the Page Speed tool on Google Code. You need to use Firefox with Firebug installed to be able to install this tool. Now I’m a novice with this so don’t expect too much from my analysis!
Step 2) I created two copies of a homepage, one that uses the standard GA code calling GA.JS and synchronously processing from the Google servers and the other using the new asynchronous code that allows other page loading steps to process while the GA.JS loads in the background and transmits the relevant information.
Step 3) I cleared my cache and recorded the pageload results. The images below depict the timeline for each.
Standard Tracking Code
Asynchronous Tracking Code
Conclusion
Peering at this rather small scale interpretation of pageload what can we conclude?
1) The asynch code does indeed allow parallel processing of the GA.JS
2) A crude estimate of the improvement experienced is that it takes about 1/3 of the time as the standard code. What does this equate in time saved? Perhaps 50-100ms, a very, very small fragment of the time for this page to complete.
3) Overall, we have many more items on this page to address to improve load time, and this is of much greater priority than rolling the asynch tracking code out with urgency. Instead, we will schedule this as an ongoing improvement for our analytics team to address with all profiles over time.
Google have done a great job of resetting the focus towards user experience. Conversion is of course, a critical element of online success but user experience should never be sacrificed.
Final feelings - phew, feeling much less emotional now!
on
Thanks for going to this trouble. But the bigger issue for me is whether I should trust a beta version. I doubt Google would release something dodgy as a beta AND urge us to adopt it, so I guess it's OK, but I would be reassured if it was confirmed.
on
Since I came across the speed tool I have compressed my Css and enabled gzip but this is still considered slow according to Google I am not sure what else I can do.
on
Thank you Jon, for your elaborate coverage on this topic here. Really helpful post. Be back here soon with your next stage of study.