Created this, cause I hated having to slow down my websites by adding the gigantic Google Tag Manager and Analytics libraries, combined with their randomly slow CDN, just to track some basic page views.
You're getting downvoted, probably because your comment is whataboutery at best. You're only relevant when you asume someone with a 6Mb homepage is starting with replacing his Analytics code. A usecase that will probably never occur.
Nothing is ever really cached anymore, meaningfully at least.
We're in an age where websites happily serve up 8mb JavaScript bundles to display their static homepage to a mobile browser that has maybe a couple hundred MB allocated to caching things. Sure, it may be there if you immediately load another page on that site (and the devs aren't using a bundler that serves a different 8mb next time).
But if they leave and come back, they'll get the same full download experience.
For what it's worth, I run a/b tests in my work where I consistently see large caching effects. For example, when we compare an experimental version of something to the currently deployed version it's critical that we cache-bust the control group. And changes that improve caching generally make things significantly better.
Caching effects are much smaller on Safari with its per-domain cache, but even there if something broke caching for us it would be a high priority to fix.
It depends. Browsers that care about user privacy and tracking are moving to first-party-isolated caching. So GA will be cached for a user on your site only if the user has visited _your_ site before.
Both of Google's recommended methods of adding Analytics to a website load Google's JS library asynchronously[1]. Including it has no meaningful impact a site's time to first paint or interactivity.
There's a good argument to say loading 70Kb of JS you're not using is a bad idea, and if that's the case then your smaller script is an improvement, but there's also a good argument to say Google Analytics is powerful and useful and maybe you should be using the features that those 70Kb give you in order to improve you site in ways the user would notice. I guess it's down to your specific use case.
My firefox never cache anything. Going forth and back in history always reloads the page. That's the reason I have many tabs open - to prevent reloading and waiting.
about.cache says:
Number of entries: 418
Maximum storage size: 30720 KiB
Storage in use: 12698 KiB
Storage disk location: none, only stored in memory
Really good point and I agree. This was intriguing at first glance because who doesn't want less JS on their site?! Of course! However, missing out on other events being tracked, advanced demographic information(?), and what else?? That's a huge miss - especially if you work with Google Ads and have your Analytics linked. Your ad campaigns won't be as effective and could potentially cost more money to save someone an unknown amount of loading time.
Would you expect Google's API to change often? My biggest concern with something like this is their /collect endpoint changing and analytics data stops being tracked.
It's cool that in also works with SPA frameworks. Thanks for sharing.
In other surveilance news, I've been adding Matomo[1] for web analytics to my site for the first time. Used to be called Piwik? It's free/selfhostable web analytics, which is more than enough for small projects and landing pages.
I've been pleasantly surprised with how it works so far, but I had to write some code to trigger it in the right part of my react-router initialization.
For the surveillance conscious I can also recommend using Fathom (https://usefathom.com). I’ve been using it for a few weeks now and have only good things to say.
I haven't tried Mamoto/Piwik, but from the looks of it they look like they have a pretty heavy feature set. If it works for you, I don't see any reason to switch. But if you prefer something that's intentionally low on features and "minimal", Fathom is pretty cool.
Small piece of history: I used to work on Analytics and they would give out swag. One piece was a T-shirt with the entire tracking snippet on it. It was a great conversation starter.
Sad to see that Tag Manager and the currently tracking JS are big enough to force website owners to compromise.
So I think it's a totally legit way to use GA, since you don't always have the ability to add libraries. For example if you want to track GA server side.
Isn't the tag manager and analytics library likely to be cached, thus using zero bytes on average versus the non-zero number of bytes for this library?
GTM used to load async, but they wanted to support A/B testing.. If you aren't using A/B testing then you would get perfectly good performance by using the older GTM snippet, it will just continue to use bandwidth at these 15 minute intervals. Even then it probably will only test the hash to see if the container changed..
This seems to me like one real problem that is pretty trivial to fix leading to a lot of over tuning for some kind of ideal.. and then being stuck if you need to support anything else.
That only means it needs to check if there's a new version every 15 minutes though (e.g. by file hash or modification date), not that it has to download it again even if there's no changes every 15 minutes. I haven't looked into the cache settings though.
Could you make it a tiny bit smaller by aliasing `window` and `document` and `localStorage` to remove the duplicated calls? `var w=window;var d=document;var l=localStorage;`
Interstingly, copying/pasting the code into https://www.minifier.org/ gains 69b of savings, but https://jscompress.com/ shows an error: `Invalid regular expression: /+/: Nothing to repeat (line: 3, col: 48)`
Will add an option for that as soon as I'm home. Also got many feature requests for exposing an event function. Both of these things shouldn't add any significant size to the snippet.
The snippet seems to circumvent the Google Analytics Opt-out Browser Add-on which many sites mention as a way to disable GA tracking in their privacy policy. So if you use the snippet, don't tell your users that they can opt out with the add-on.
Are you sure it circumvents it? My uBlock Origin is still properly blocking the API call to google analytics. But since the Add-on is from Google itself it could work in different ways indeed.
While you're at it, why not be less invasive and neuter some of the data you send across? Does Google need to know about screen colordepth, language settings and text encodings, or fine-grained viewport dimensions, or is that stuff just bits of entropy to fingerprint users? Hardcode it!
When I see the hoops people have to jump through to get basic privacy from Google, it makes me happy that my company's legal department prohibits us from using Google products for HIPAA reasons.
You can also pretty reasonably remove "colorDepth:true", I can not possibly imagine you have many indexed or RGB545 displays going to your site these days.
72 comments
[ 2.8 ms ] story [ 127 ms ] threadIf you are that concerned then your page views should be sent from the server side.
We're in an age where websites happily serve up 8mb JavaScript bundles to display their static homepage to a mobile browser that has maybe a couple hundred MB allocated to caching things. Sure, it may be there if you immediately load another page on that site (and the devs aren't using a bundler that serves a different 8mb next time).
But if they leave and come back, they'll get the same full download experience.
Caching effects are much smaller on Safari with its per-domain cache, but even there if something broke caching for us it would be a high priority to fix.
(I work at Google on ad tags)
Thanks for that. It explains why even on very high-end new phones, switching between complicated web sites in different tabs causes a reload.
This is because your UAID is part of the URL to download the GTM snippit.
The old-school analytics.js file can be cached, though.
Someone correct me if this isn't true.
There's a good argument to say loading 70Kb of JS you're not using is a bad idea, and if that's the case then your smaller script is an improvement, but there's also a good argument to say Google Analytics is powerful and useful and maybe you should be using the features that those 70Kb give you in order to improve you site in ways the user would notice. I guess it's down to your specific use case.
[1] https://developers.google.com/analytics/devguides/collection...
about.cache says:
Number of entries: 418
Maximum storage size: 30720 KiB
Storage in use: 12698 KiB
Storage disk location: none, only stored in memory
This is pretty creative though.
https://en.wikipedia.org/wiki/Snippet_(programming)
Would you expect Google's API to change often? My biggest concern with something like this is their /collect endpoint changing and analytics data stops being tracked.
So I think they won't change it or just add a different version with the old version still working.
In other surveilance news, I've been adding Matomo[1] for web analytics to my site for the first time. Used to be called Piwik? It's free/selfhostable web analytics, which is more than enough for small projects and landing pages.
I've been pleasantly surprised with how it works so far, but I had to write some code to trigger it in the right part of my react-router initialization.
[1] https://permanent.cloud/apps/matomo
(and its cool I'm not helping Google spy on people who visit and help me out)
Sad to see that Tag Manager and the currently tracking JS are big enough to force website owners to compromise.
So I think it's a totally legit way to use GA, since you don't always have the ability to add libraries. For example if you want to track GA server side.
If users spend a bit of time navigating your site, you might get better caching by adding this to your JS file and caching for longer.
This seems to me like one real problem that is pretty trivial to fix leading to a lot of over tuning for some kind of ideal.. and then being stuck if you need to support anything else.
Interstingly, copying/pasting the code into https://www.minifier.org/ gains 69b of savings, but https://jscompress.com/ shows an error: `Invalid regular expression: /+/: Nothing to repeat (line: 3, col: 48)`
ga('set', 'anonymizeIp', true);
'can you make it bigger'
'...'
> SyntaxError: nothing to repeat
The line seems to be this:
> return l?l[2]?decodeURIComponent(l[2].replace(/+/g,' ')):void 0:void 0},
Might it be related to AdBlock? I'm using Firefox with AdBlockPlus, Cookiebro and the default Privacy settings turned up in Firefox.
Edit: oops, it's clearly coming from the regex: /+/g → /\+/g
https://stackoverflow.com/a/6288596
[1] https://github.com/Rob--W/crxviewer#chrome-extension-source-...
Now using navigator.sendBeacon if available (not even GA does that by default yet), ability to track events and ability to track exceptions.
All of that by keeping it tiny.