Google Tag Manager Performance: How Tags Slow Pages Down and How to Fix It

Google Tag Manager itself is a container: a script that loads and runs the tags configured in it. Beyond the container script itself, the performance cost comes from what the container is told to run: analytics, advertising pixels, heatmaps, chat widgets, A/B testing scripts and custom HTML. Each tag downloads code, executes on the main thread and sometimes injects more scripts or elements into the page. Without testing, it is easy to blame GTM for slowness caused by one heavy vendor script, or to miss that a single synchronous tag is delaying rendering. The fix starts with an audit that attributes cost to individual tags.

How tags slow pages down

web.dev’s guidance on third-party JavaScript notes that scripts using the async attribute execute “at the first opportunity after they finish downloading and before the window’s load event”, and that they can interrupt DOM building if they finish while the page is still parsing (efficiently loading third-party JavaScript). It also warns that some scripts block rendering until they complete processing, which “can be true even for asynchronous A/B testing scripts” (web.dev on third-party JavaScript).

A tag performance audit worksheet

Fill one row per tag in the container. The goal is to see each tag’s purpose, cost and timing in one place.

How to measure each tag’s cost

1. Record a baseline trace in Chrome DevTools on a throttled mobile profile for a key template.
2. Use GTM’s Preview mode to see which tags fire, when and on which trigger.
3. Block one tag’s domains at a time in DevTools (request blocking) and record the trace again. The difference in scripting time, long tasks and LCP is the measured effect of the blocked requests in that run, not necessarily the cost of one tag: several tags can load from the same domain, a blocked script can stop other scripts it would have loaded, and cache state changes between runs.
4. Confirm with a controlled tag test. In a GTM workspace, pause or disable only that tag, preview the container, and record several traces with and without it under the same throttling and cache condition (for example, cold cache each time). Compare medians, not single runs.
5. Check the coverage panel for unused code loaded by tags.
6. Repeat for the heaviest tags on each key template.

Together, the two tests attribute cost to individual tags instead of to “GTM” as a whole, within the limits of what one page and one profile can show.

Fixes

Remove what is not used. Old campaign pixels, duplicate analytics tags and tools from abandoned trials can accumulate in a long-lived container; each costs something on every page where it fires. Removing a tag is the only fix with no trade-off.

Restrict triggers to the pages that need them. A checkout conversion pixel does not need to fire on blog articles.

Delay non-essential tags. Fire chat widgets, heatmaps and secondary marketing tags on window loaded, after a delay, or on user intent (for example, when the user opens the chat), rather than at page view.

Avoid synchronous custom HTML. Custom HTML tags that use document.write or inline synchronous scripts block parsing. Replace them with built-in templates or asynchronous loaders.

Handle A/B testing scripts carefully. Anti-flicker snippets hide the page until the testing script runs, delaying LCP. Limit testing to pages under test, keep timeouts short, and consider server-side testing for high-traffic templates.

Reserve space for injected elements. If a tag inserts a banner, reserve its space in the layout or position it so it does not push content and cause layout shift.

Consolidate. Several vendors sending the same events can sometimes be replaced by one tag sending to multiple destinations, or by server-side tagging, which moves some processing off the browser.

Testing the result

• Publish each change as a new container version with a note of what changed, so a release that breaks measurement can be reverted to the previous version.
• Compare traces before and after for scripting time, long tasks and LCP.
• Compare PageSpeed Insights lab metrics, remembering that lab runs vary.
• Confirm that analytics and conversion data still arrive: a performance fix that breaks measurement is not a fix.
• Watch field Core Web Vitals over the following 28 days.

Finding the two tags behind poor INP

A hypothetical ecommerce site’s product pages fail INP in field data. The team suspects GTM.

• Audit: the container holds 34 tags; 9 belong to campaigns that ended; a session recording tool fires on every page at page view; a custom HTML tag runs a large synchronous script for a recommendations widget.
• Measurement: blocking the session recording domain reduces main-thread time during interactions in traces; blocking the recommendations widget’s script removes a long task that ran during the first interaction; blocking GTM’s other tags changes little. Pausing each of the two tags in a GTM preview workspace, with five cold-cache traces per state, shows the same direction of change.
• Changes: remove the 9 obsolete tags; restrict session recording to 10 percent of sessions and fire it after window load; move the recommendations widget to an asynchronous loader that runs after first input.
• Verification: check that traces show fewer long tasks during interactions and that analytics events are unchanged; recheck field INP for product pages after a month.
• Lesson: GTM was not the cause; two specific tags were. The audit prevented removing tags that cost almost nothing.

Auditing the container tag by tag

Treat the GTM container as a list of third-party code that runs on your pages. Audit it tag by tag, measure each tag’s cost, remove what is unused, and delay or restrict the rest. Avoid attributing every performance problem to GTM without testing; beyond its own script, the container is as heavy as what it runs. The site’s own JavaScript deserves the same scrutiny through bundle size and code splitting.