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...
This is pretty creative though.
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
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.
If you are that concerned then your page views should be sent from the server side.