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:
- 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.
- Create an array on the page called
window.datalayer - Define a little
gtag()function that just pushes whatever you throw at it into that array. - 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.