Question: analyticsjs-boilerplate vs gtag? or with gtag?

[Westbrook]

This is a really great way to approach working with GA, thanks for sharing it. It includes so many of the ideas I've hacked support for into previous implementations, with many more I hadn't thought of, in a really flexible and clean package!

I wondered if you had thoughts on moving this code to support gtag, or whether you felt gtag gave you some of the flexibility you're going for in this code without some of the local boilerplate.

Or do you feel that the differences between ga and gtag are transparent enough to simply change the reference?

Thanks for the insight!

[philipwalton]

gtag was released without support for most of the advanced analytics.js features this boilerplate uses (e.g. tasks and plugins), so if you like these features then I wouldn't recommending using gtag.

The other thing to be aware of about gtag is it's not really an analytics.js replacement, it's a wrapper library on top of analytics.js (and others), meaning the gtag library still needs to load analytics.js, and it needs to convert all relevant gtag commands to analytics.js commands and run them.

As of right now, gtag is 54.5K and analytics.js is 33.7K, and since gtag will also load analytics.js, it's 262% more code for less functionality. There's also the problem that gtag is site-specific (because you add your tracking ID as a query string), so it's unlikely your users will have it cached; analytics.js on the other hand is used all over the web, so it's very likely to already be in your visitors cache when they load your site.

So, for all these reasons, I don't plan to switch to gtag as it'll just end up making my site take longer to load and consume more of my user's bandwidth.

[Westbrook]

Thanks @philipwalton! Very helpful in better understanding the goals of your boilerplate and the realities around gtag. Keep up the great work.