Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Westbrook opened this issue Oct 2, 2017 · 2 comments

Comments

@Westbrook
Copy link

commented Oct 2, 2017

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

This comment has been minimized.

Copy link
Owner

commented Oct 3, 2017

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

This comment has been minimized.

Copy link
Author

commented Oct 3, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.