Does Google Analytics have performance overhead?

Question

To what extent does Google Analytics impact performance?

I\'m looking for the following:

• Benchmarks (including response times/pageload times et al)

Answer 1

The traditional instructions from Google on how to include ga.js use document.write(). So, even if a browser would somehow asynchronously load external JavaScript libraries until some code is actually to be executed, the document.write() would still block the page loading. The later asynchronous instructions do not use document.write() directly, but maybe insertBefore also blocks page loading?

However, Google sets the cache's max-age to 86,400 seconds (being 1 day, and even set to be public, so also applicable to proxies). So, as many sites load the very same Google script, the JavaScript will often be fetched from the cache. Still, even when ga.js is cached, simply clicking the reload button will often make a browser ask Google about any changes. And then, just like when ga.js was not cached yet, the browser has to await the response before continuing:

GET /ga.js HTTP/1.1  
Host: www.google-analytics.com  
...  
If-Modified-Since: Mon, 22 Jun 2009 20:00:33 GMT  
Cache-Control: max-age=0  

HTTP/1.x 304 Not Modified  
Last-Modified: Mon, 22 Jun 2009 20:00:33 GMT  
Date: Sun, 26 Jul 2009 12:08:27 GMT  
Cache-Control: max-age=604800, public  
Server: Golfe  

Note that many users click reload for news sites, forums and blogs they already have open in a browser window, making many browsers block until a response from Google is received. How often do you reload the SO home page? When Google Analytics response is slow, then such users will notice right away. (There are many solutions published on the net to asynchronously load the ga.js script, especially useful for these kind of sites, but maybe no longer better than Google's updated instructions.)

Once the JavaScript has loaded and executed, the actual loading of the web bug (the tracking image) should be asynchronous. So, the loading of the tracking image should not block anything else, unless the page uses body.onload(). In this case, if the web bug fails to load promptly then clicking reload actually makes things worse because clicking reload will also make the browser request the script again, with the If-Modified-Since described above. Before the reload the browser was only awaiting the web bug, while after clicking reload it also needs the response for the ga.js script.

So, sites using Google Analytics should not use body.onload(). Instead, one should use something like jQuery's $(document).ready() or MooTools' domready event.

See also Google's Functional Overview, explaining How Does Google Analytics Collect Data?, including How the Tracking Code Works. (This also makes it official that Google collects the contents of first-party cookies. That is: the cookies from the site you're visiting.)

---

Update: in December 2009, Google has released an asynchronous version. The above should tell everyone to upgrade just to be sure, though upgrading does not solve everything.

Answer 2

There are some great slides by Steve Souders (client-side performance expert) about:

• Different techniques to load external JavaScript files in parallel
• their effect on loading time and page rendering
• what kind of "in progress" indicators the browser displays (e.g. 'loading' in the status bar, hourglass mouse cursor).

Answer 3

From my own experience it has adding Google-Analytics has not changed the load times.

According to FireBug it loads in less then a second (648MS avg), and according so some of my other test ~60% - 80% of that time was transferring the data from the server, which of course will vary from user to user.

I don't preticularly think that caching the analytics code locally will change the load times much, for the above reasons.

I use Google-Analytics on more then 40 websites without it ever being the cause of any, even small, slowdown, the most amount of time is spent getting the images which, due to their typical sizes, is understandable.

Answer 4

Well, I have have searched, researched and expored extensively on net. But I have not found any statistical data that claims either in favour or against of the premise.

However, this excerpt from http://www.ga-experts.com claims that its a Myth that GA slows down your website.

Err, well okay, maybe slightly, but we’re talking about milliseconds. GA works by page tagging, and any time you add more content to a web page, it will increase loading times. However if you follow best practice (adding the tag before the </body> tag) then your page will load first. Also, bear in mind that any page tag based web analytics package (which is the majority) will work the same way

From the answers above and all other sources, what I feel is that whatever slowdown it causes in not percieved by the user as the Script is included at the bottom of the page. But if we talk of complete page-loads we might say that it slows down the page-load time.

Please post in more info if you have and DATA if you have any.

Answer 5

I don't think this is what your looking for but what are you worried about performance for?

If its your server... then there's obviously no impact as it resides on Google servers.

If its your users that your worried about then there is no impact either. As long as you place it just above the body tag then your users will not receive anything slower than they would before... the script is loaded last and has no affect on the appearance to the user. So there essentially not waiting on anything and even continue to browse through the page without noticing that its still loading.

Answer 6

2018 update: Where and how you mount Analytics has changed over and over and over again. The current gtag.js code does a few things:

1. Load the gtag script but async (non-blocking). This means it doesn't slow your page down in any other way than bandwidth and processing.
2. Create an array on the page called window.datalayer
3. Define a little gtag() function that just pushes whatever you throw at it into that array.
4. Calls that with a pageload event.

Once the main gtag script loads, it syncs this array with Google and monitors it for changes. It's a good system and unlike the previous systems (eg stuffing code in just before </body>) it means you can call events before the DOM has rendered, and script order doesn't really matter, as long as you define gtag() first.

That's not to say there isn't a performance overhead here. We're still using bandwidth on loading up the script (it's cached locally for 15 minutes), and it's not a small pile of scripts that they throw at you, so there's some CPU time processing it.

But it's all negligible compared to (eg) modern frontend frameworks.

If you're going for the absolute, most cut-down website possible, avoid it completely. If you're trying to protect the privacy of your users, don't use any third party scripts... But if we're talking about an average modern website, there is much lower hanging fruit than gtag.js if you're hitting performance issues.