Universal Analytics for a Faster Web

At its exclusive event in Mountain View for Partners a couple weeks ago, Google announced Universal Analytics. This new platform brings exciting features to the table by switching a lot of the logic and control from the JavaScript tracking code back to the server side. It took Google significant re-engineering to make this happen and it will enable features that marketers have been waiting for; including cross-device and cross-channel insights.

But today I’ll focus on one important change that has not been well publicized that can be remarkable for webmasters. Universal Analytics comes with a completely redesigned tracking API, the biggest update to the tracking code in the last 10 years. This is no average piece of code, this is a piece of code that sits in over 10 Million Websites, it’s probably the most used JavaScript snippet on the whole web. It reduces the size of cookies used by Google Analytics by 80% from what it was previously.

Percentage of Websites using Google Analytics. Source: BuiltWith.

Why should you care?

All cookies in Google Analytics are first party. This means that they are set in your own domain and every HTTP request to that domain sends the cookie to your server; unnecessarily. It’s hard to avoid this behavior as cookies are the most reliable way to store state on the client side, but they are not very flexible.

It means that when using Google Analytics, its cookies will be sent to your server, potentially multiple times per page. If a page has images, style-sheets and scripts on the same domain, each of those resources will generate new HTTP requests and there goes the Google Analytics cookies once again.

Sending this information to the server on every request is not only unnecessary but will have an impact on how fast your site loads. To be fair, given the widespread usage of Google Analytics on the Web, it’s safe to say that the tool slows down the whole Web only a tiny fraction.

Measuring the impact

It’s hard to measure exactly how much having unnecessary cookies in the HTTP request really slows down your site.

Let’s start by looking at the size of a Google Analytics Cookie today. This is an example of a default standard set of cookies created by the Google Analytics Tracking Code.

>document.cookie
"__utma=96182344.347392035.1326382423.1326382423.1326382423.1; __utmb=96182344.1.10.1326382423; __utmc=96182344; __utmz=96182344.1326382423.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)"
>document.cookie.length
188

So, having GA cookies increase the size of HTTP requests by 188 bytes or even more. Having more bytes doesn’t necessarily mean slower requests though as data is sent in packages of 1500 bytes. So if you pass that threshold it means you need a second package which means that it will take almost twice as long to load. But even if the package is not split, a larger package has a higher chance of getting corrupted and also slowing the transfer a little bit more on average.

At this point it’s hard to tell how much an extra 188 bytes will really impact the site speed. It would depend on the size of the package and the network reliability. But one thing is clear, smaller cookies equals faster requests, especially on a high volume site. And now enters the new cookie for Google Analytics after Universal Analytics.

>document.cookie
"_ga=1.2.1135929135.1351731193978"
>document.cookie.length
32

Based on my tests it’s only 17% of the original cookie size.

Conclusion

“Universal Analytics” brings a lot more benefits to Google Analytics than speed. Over the next few weeks we’ll be posting more information about the new platform.

It is already available, but only as a beta. You can request early access, but Google is still working on some of the last details and some features that are missing. But you can start playing with it now until it’s ready for its prime time debut.