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)
• Links or results to similar benchmarks

One (possible) method of testing Google Analytics (GA) on your site:

1. Serve ga.js (the Google Analytics JavaScript file) from your own server.
2. Update from Google Daily (test 1) and Weekly (test 2).

I would be interested to see how this reduces the communication between the client webserver and the GA server.

Has anyone conducted any of these tests? If so, can you provide your results? If not, does anyone have a better method for testing the performance hit (or lack thereof) for using GA?

Solution 1

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.

Solution 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).

Solution 3

I haven't done any fancy automated testing or programmatic number crunching, but using good old Firefox with the Firebug plugin and a pair of JS variables to tell the time difference before and after all GA code is executed, here is what I found.

Two things are downloaded:

1. ga.js is the JavaScript file containing the code. This is 9kb, so the initial download is negligible and the filename isn't dynamic so it's cached after the first request.

2. a 35 byte gif file with a dynamic url (via query string args), so this is requested every time. 35 bytes is a negligible download as well (firebug says it took me 70ms to dl it).

As far as execution time, my first request with a clean browser cache was an average of about 330ms each time and subsequent requests were between 35 and 130 ms.

Solution 4

You can host the ga.js on your servers with no problems whatsoever, but the idea is that your users will have the ga.js cached from some other site they may have visited. So downloading ga.js, because it's so popular, adds very little overhead in many cases (i.e., it's already been cached).

Plus, DNS lookups do not cost the same in different places due to network topology. Caching behavior would change depending on whether users use other sites that include ga.js or not.

Once the javascript has been loaded, the ga.js does communicate with Google servers, but that is an asynchronous process.

Hope this helps.

Solution 5

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.

View more solutions

Comments

[Dan Rosenstark]

Why do people mark the question as a "favorite" without upvoting it? If the question produces interesting answers, upvote the question!

[UnkwnTech]

Maybe they just want to see what people say in response, but are not exactly interested in the topic, (i.e. they are thinking about something related)

[Dan Rosenstark]

Right. Which deserves an upvote. Upvotes are not for questions that make you laugh. This is not YouTube. Upvotes are for questions that enrich our joint technical knowledge.

[UnkwnTech]

I suppose different people have different criteria for up-votes otherwise every question would have IMMENSE amounts of votes or be closed.

[M.N]

I guess people mark questions as 'favorite' more for bookmarking purposes than other reasons, hence no upvotes for favorite question(read bookmarks) :-).

[George Stocker]

@Daniel: I favorite questions to follow them. Most of the time I don't know if it's a good question or not. I'll know after being able to research it further, but I couldn't tell you at the outset whether this is one such question. So I come back to it. Not to mention I'm conservative with votes.

[George Stocker]

Rewrote question to clarify, improve structure, and get rid of sentence fragments.

[M.N]

Thanks Gortok. I appreciate your efforts.

[Admin]

I see a lot of posts about the page load time, but what about the consumption of asynch requests? Browsers have a limit on the number of pending requests, and surely the updates to Google consume some of these. If you have a site that makes heavy use of simultaneous asynch requests, couldn't the use of Google Analytics cause the blocking of the actual application's requests?

[Aluan Haddad]

@user748852 and that's still true

[M.N]

Thomas, do you have any numbers as to what improvements did you get after removing the GA code. In terms of response times, in %ages or values itself?

[Arne Evertsson]

Are you sure that "the browser will load the Google script in parallel along with all other embedded resources"? Tried it?

[Dan Rosenstark]

I love how everybody's so smart (me included) but the empirics of the situation are DIFFERENT (aren't they always?). Thanks for y our answer, fascinating.

[Arjan]

It's a bit odd that articles like the one above often only test while the Google Analytics servers are running fine. Things may be more troublesome when those servers are under heavy load. And if the servers are experiencing problems, many reloads of impatient users may make things even worse.

[Yahel]

I don't know if they weren't gzipping 2 years ago, but, they are now, and it reduces the file size from 30.92k to 12.63k as of this writing.

[Sabuncu]

thank you for the reference to Souders' slides, excellent information contained within them.

[tacone]

So wrong: the GA file is marked as no-cache. Nobody has it cached.

[Lazar Ljubenović]

I'm happy to find such a simple answer, but this is from 2009. I'm not saying that "old means bad", I'm just wondering: has anything changed in the recent years?

[Oli]

Updated for latest script. @tacone Your comment was some years after my original answer. Simple fact is Google has repeatedly changed how all this stuff works over the past decade. Current cache is 900s.

[OZZIE]

I am not sure this is still true 2019 imgur.com/a/HTnu8Wu :-) The irony is striking :D

[Oli]

@OZZIE Not sure what's still true? The tag insertion is still async. Yes, it has to download 42KB but it's not waiting to do that before displaying the page. We're talking about performance overhead here, not bandwidth.

[OZZIE]

@Oli "But it's all negligible compared to (eg) modern frontend frameworks." which you put in bold, doesn't seem to be negligible in latest Page Speed by Google, it's at the very top of third party js using Main Thread Time, and we have a lot of semi-heavy third party js on this site yet it says GA uses the most ^^ :(

[Oli]

@OZZIE That does not reflect my experience. GA et al are just tools to build and push a queue of events up to Google. If you're sending super-high numbers of events, spurious example: mouse movements, you're going to get correspondingly high CPU usage. It might be worth sticking a breakpoint in GA, or a watch on the array to see what's actually making it run that wild.

[user3425506]

When you say it took 70ms do you mean it added 70ms to the time taken taken between the viewer clicking on the link and the page being viewable by them? If that is the case then 70ms is very significant from what I have read. I read that anything under 100ms is perceived as instantaneous. So if 70ms has been used up you only have 30ms left to do all the other stuff before you end up with a noticeable delay. I am not at all sure whether what I have said makes sense because I do not understand the topic very well but it seems logical at least superficially.