Yes, Google Tag Manager slows down your site. You read everywhere that the tool is light and that only the tags you add to it weigh anything. The second half of that sentence is true. The first one no longer is.
What Google Tag Manager weighs before the first tag
Tag Manager is a container. Your marketing team or your agency stores its tools in it (Google Analytics, ad pixels, heatmaps, live chat) without asking the developer for a change every time a campaign starts. It’s convenient, and that’s why we set it up on the sites we deliver.
That container is a JavaScript file every visitor downloads. We measured its weight as Google’s servers send it, next to a few scripts that are often loaded through it:
| File | Transferred (compressed) | Code to run |
|---|---|---|
| Empty Tag Manager container, no tags at all | 90 KB | 245 KB |
| Containers of four well-known Quebec sites | 145 to 195 KB | 440 to 615 KB |
| Google Analytics 4 (gtag.js) | 155 KB | 445 KB |
| Meta pixel, before its configuration | 115 KB | 435 KB |
| All the JavaScript on our site, before consent | 35 KB | 115 KB |
In 2022, a guide on web.dev, the site where Google documents web performance, put the library at about 33 KB compressed. It has almost tripled since. An empty container now weighs more than twice all the JavaScript on our site.
The transfer is only half the cost. The browser then has to read and run that code. On a recent computer, nobody notices. On an entry-level phone, 600 KB of JavaScript is something you feel.
Tags cost more than the container
Every tag added in Tag Manager downloads its own script. Add up a real container, Google Analytics 4 and the Meta pixel: more than 400 KB compressed, before any heatmap or chat window. Twelve times our site.
Loading isn’t the worst part. Those scripts keep the phone’s processor busy just as the visitor tries to tap a menu or a button, and the page is slow to react. Google measures that delay with INP (Interaction to Next Paint), one of the three Core Web Vitals. The authors of the web.dev guide say they have seen a link between container size and poorer INP scores.
And a container never slims down on its own. It ends up like the little box by the front door: everyone drops something in, nobody sorts it. The pixel from a campaign that ended two years ago. The tool of an agency that no longer works with you. A test tag nobody removed. The same guide says it plainly: tags get added, and they rarely get removed.
Consent makes your site faster too
Quebec’s Law 25 requires you to inform visitors before using a technology that can identify or profile them, and to give them a way to turn those functions on (section 8.1 of the Act respecting the protection of personal information in the private sector). On the sites we deliver, nothing goes out before the visitor’s choice: no Google Analytics, no ad pixels.
A welcome side effect: the visitor who declines gets a lighter site. The one who accepts downloads the scripts after the click, once the page is already on screen.
Be careful with Google’s Consent Mode. In “advanced” mode, Google’s documentation says tags load as soon as the visitor arrives, then send cookieless measurements until consent is given. “Basic” mode waits for the choice. Some consent tools even load Google’s script before the choice as soon as you turn on their Consent Mode option. We saw it on our own site, and we turned it off.
That setting also changes what you measure. A PageSpeed test never clicks “Accept”. On a compliant site, it measures the page without your tags, while your visitors who accept do load them. Chrome’s real-world data, in the Core Web Vitals report of Search Console, mixes both.
How to lighten Google Tag Manager without losing data
No need to unplug everything. Here is what we do, in order, when a container weighs a site down:
- Take inventory. Every tag has an owner and a reason to exist. Those that no longer do are deleted, not just paused.
- Fire at the right time. The earlier a tag fires, the more it weighs on display. A tag that isn’t essential waits for the page to finish loading (the “Window Loaded” trigger).
- Fire in the right place. A campaign’s conversion tag has no business on the home page: it fires on the thank-you page, and nowhere else.
- Prefer templates to custom HTML tags. A template, from the gallery or your own, runs in a restricted sandbox with declared permissions. A custom HTML tag runs any code at all, often copied from documentation without anyone reviewing it.
- Take out of the container what belongs to the site. The consent banner, a font or a visible element of the page load with the site. Sent through Tag Manager, they arrive late and make the layout jump.
Then there is server-side tagging. Part of the work leaves the browser for a server, which you pay for every month. It makes sense for a site that spends a lot on advertising. For a business website, we rarely recommend it.
Measure before and after every cleanup. Our free speed test scores a page in a few seconds, and the Core Web Vitals report in Search Console shows the effect on your real visitors, a few weeks later. Sorting out third-party scripts is part of our speed optimization projects.
Should you keep Google Tag Manager?
Yes. A marketing team or an agency running campaigns adds its tags without waiting for a developer. The time saved on every campaign justifies the weight of the container, and consent keeps its tags away from visitors who decline.
Removing Tag Manager to paste the same tags into the site’s code solves nothing. The scripts weigh just as much, you only save the container, and every campaign change goes back through a developer. The problem is rarely the tool. It’s what was left to pile up inside.
One last point, which has nothing to do with speed. Anyone with access to your container can add code to every page of your site, without going through your developer. The Tag Manager account must be in your name, and the list of people with access, short. If you don’t know who has access to yours, start there. A website audit takes that inventory along with the scripts.
