Page Load Impact of Google Analytics

Google provides an amazing, free website analysis product called Analytics, also known as Urchin, the name of the company Google bought to acquire this technology. As with many things Google produces, it does a lot of what you want, how you want and for a price you can't beat. It's obviously aimed squarely at users of their AdWords product. Even so, I've added it to several websites just to do basic analysis, such as unique visitors, entry points, search terms, and so on.

But everything has a cost and I wanted to know what the cost of using Google Analytics would be.

This amounts to a back-of-the-envelope calculation. I'm sure there more thorough analysis can be found out there somewhere. Dare I say you should Google for it?

Some background

To add Analytics to you site, you simply add a few lines of JavaScript to your web page. Originally Google instructed people to add these lines to the section of their pages. Unfortunately, if the Analytics site is down or just slow, it means your pages content will be blocked or slower to load. They now suggest adding the JavaScript just before the tag and I recommend anyone using Analytics to go make this change immediately.

The code that is pulled from the Google site is urchin.js. Why pull it directly from Google? For one, it keeps your sites up-to-date with the latest changes. It does open up some privacy issues, which I'll talk about in another post.

The code snippet then calls urchinTracker() with a unique identifier for your website. Some calculations are done and urchinTracker asks for a transparent 1x1 pixel GIF (about 35 bytes) from Google. In the URL of this GIF is all the data that Analytics uses to track users on your site. Since this URL is different for every move a user makes on your site, the GIF cannot be cached. However at just 35 bytes, caching is not going to be the issue. The urchin.js file is about 7k bytes and can be cached so that will save you some time after the initial page is loaded for your site.

20 seconds on caching

Caching works by allowing your browser to short-cut downloading a given object (HTML file, JavaScript file, image, etc.) if the version they have in their cache is still fresh. "Freshness" is determined by two things: the max-age which is set in the file header and whether or not there is a newer version of the file on the web server. To check the latter, the browser needs to make a round-trip to the web server and ask. Oftentimes, that can take just as long as downloading the file in the first place. There are some so-called smart caching solutions out there, but those are beyond the scope of this article.

The results

I loaded the homepage of a development website 12 times with and 12 times without Analytics. Using FireBug on FireFox (2.0.0.8 on Windows) I recorded the load time of the urchin.js file, the urchin GIF, and the total load time for the page. Like the judges in the Olympics, I tossed the high and low time to get the averages and standard deviations listed below. I also recorded the execution time of urchinTracker() but found it to be 4ms or less on my somewhat-high-end development machine. Compared to the download and network round-trips, I considered this negligible.

Conclusions?

This test showed a 270ms increase in load time and 87ms increase in the standard deviation for load times. Percent wise, that's huge, but only a blink of an eye in real time. The test was done around lunch time (Pacific timezone) which is traditionally a time of average internet usage, but the round-trip to the server could also be affected by local internet traffic, server load, etc. In the next few days I'll try this again at a different time of day to see how the results compare.

But for now, I'll still add Analytics to my websites as the cost is well worth the benefit.