Site Speed, Javascript, and Google Analytics
Yesterday a friend of mine had some questions about installing the newer asynchronous version of Google Analytics and our conversation raised a few concepts that I thought were interesting.
First off, I'd like to say that Google Analytics is a great tool for anyone involved with websites, but especially if you are interested in SEO. You can access traffic source data like what keywords people are using to get to your site, or segment your search customers by any metric you can think of. Plus it's free. Well, it's Google's version of free in that you turn over your data to them in exchange for the service.
Anyway, my friend was trying to find out if the newer script would only be compatible with browsers that support AJAX. (In case you were wondering, AJAX is a way to make server calls without reloading the entire webpage.) The thing about it is, the asynchronous tracking code is not using AJAX at all. The "asynchronous" aspect of the tracking code has to do with the way the page loads.
Page loading is an important part of SEO. Websites that load fast quite obviously offer a much better user experience than slow sites that take forever to load content. And Google announced that site speed was one of their search ranking factors in April of last year.
The tracking code is written in javascript. And when browsers need a javascript resource they stop rendering a page until the resource is fully downloaded. With the old Analytics tracking code this meant slower page load times. So often SEOs would opt to put the script at the bottom of the page so that it would render last. This way users could at least see site content while the tracking code loaded. But if the user left the page before the tracking code was finished they would lose that page view.
The new asynchronous tracking code attacks this problem in several ways:
- It starts packing user data up into a queue so when the javascript code is finally ready it can send everything immediately to Google. This will help address the problem of the tracking code not always being rendered.
- It dynamically adds the <script> element to the DOM, which works around the download bottleneck.
- It adds the async=true attribute to the script tag. This is a new attribute that was added in the HTML5 spec, so only browsers that can render HTML5 can make use of it. It redundantly works around the download bottleneck, but Google is obviously looking forward here, hoping to keep the tag as efficient as possible before having to make another change to it.
One thing to note, Google recommends putting this tracking code in the bottom of the <head> element. This is an important point from a page load time perspective in itself. You should always load your CSS, Meta tags and other header elements before any script resources so that they don't slow down the page load process.
While preparing this post I found a cool post from a guy who decided to further optimize the actual tracking code itself. While I am not sure this gains most sites too much, especially if you compress your resources, I think it's a nice walkthrough for anyone interested in how the tracking code works.
Finally, here's a usage guide for asynchronous tracking.
