Why is Google Tag Manager slowing down my website?

Kilian Müller
Kilian MüllerOwner of 1hold.de · Google PartnerUpdated
Google Tag ManagerGoogle Certified Specialist

Usually it is not Google Tag Manager itself that slows your website down, but the tags it fires. If Google Tag Manager is slowing down your site, look at Custom HTML tags, a second Google tag loaded by a plugin and everything that starts the moment a visitor accepts cookies – the container snippet itself loads gtm.js asynchronously and does not block your HTML.

So measure before you delete anything. In our client accounts GTM caused slow interactions (INP) more often than slow loading (LCP), and in one case it was blamed for a problem that sat on the server. If your page views are also counted twice, read why GTM duplicates Google Analytics page views.

How do I check whether Google Tag Manager is slowing down my site?

  1. Open PageSpeed Insights, enter the URL and select Mobile. The top block shows field data from real Chrome users over 28 days. Note LCP and INP: good is up to 2.5 seconds and up to 200 milliseconds.
  2. In the lab results further down, open the diagnostics on unused JavaScript and third-party code. googletagmanager.com is listed there with its transfer size and main-thread time.
  3. In Chrome, open DevTools → Performance, record a page load and then a tap on the cookie banner’s accept button. Long tasks (marked with a red corner) that come from gtm.js or the tags it loads are what hurts INP.
  4. Compare the timing. If the GTM tasks only start after the largest element has been painted, GTM is not your LCP problem.

What makes Tag Manager slow in practice?

  • Custom HTML tags. Google’s guide to tags and tag managers ranks image pixels as the fastest tag type, then custom templates, then Custom HTML. A Custom HTML tag that contains a whole vendor library cannot be cached separately.
  • Everything fires on page load. Heatmaps, chat widgets or remarketing are not needed for the first paint. The same guide recommends firing non-essential tags after Window Loaded.
  • Two Google tags. A WordPress plugin such as Site Kit, or a cookie plugin with its own Analytics service, loads gtag.js next to GTM. That costs main-thread time and duplicates your data.
  • Consent timing. In basic consent mode Google tags stay blocked until the visitor answers the banner. The accept tap then has to download and run the whole container – exactly the interaction INP measures.
  • Blocked instead of removed. Pausing or deleting a tag removes its code from the container. A blocking trigger does not, so the code is still downloaded.

What did two client cases show: GTM or the server?

A retail client had a mobile INP of 278 ms in May 2026. Lab traces showed the pattern: first-time visitors reached 300 to 368 ms when they tapped “accept”, returning visitors only 72 ms. The cookie banner held GTM back until consent, and a WordPress plugin loaded the Google tag a second time. We removed the duplicate and start GTM about 800 ms after the load event, once the browser is idle. Server caching was improved in the same weeks, so not every millisecond is down to GTM, but the field INP fell from 229 ms in mid-June to 137 ms in late July and has stayed under 155 ms since.

Interaction delay (INP), mobileRetail client · 75th percentile, real usersEarly May278 msMid-June229 msLate July137 msMid-October145 msgood ≤ 200 msSource: Chrome UX Report (28-day field data), origin, mobile

A B2B client suspected GTM because PageSpeed listed it under unused JavaScript. Mobile LCP was 4.1 seconds in August. The trace showed GTM’s long tasks at 3.7, 7.4 and 9.3 seconds, all after the main content had been painted, and INP was already good. The real cause was the server: the first byte alone took 4.2 seconds because the page cache had stopped working. After the cache was fixed, mobile LCP dropped to 1.6 seconds. We left the container as it was.

Largest Contentful Paint (LCP), mobileB2B client · GTM unchanged, server cache fixedMid-August4.1 sLate September1.6 sMid-October1.7 sgood ≤ 2.5 sSource: Chrome UX Report (28-day field data), origin, mobile

Should I lazy-load Google Tag Manager?

Only after measuring, and only with a delay based on idle time. Loading GTM on the first scroll or click moves its work into exactly the interaction that INP measures. A short delay after the load event (we use requestIdleCallback) keeps the first paint free. The price: visitors who leave within that second are not tracked, and the consent default still has to be set before any Google tag runs.

Fix the cause the field data shows. If INP suffers when visitors accept cookies, remove duplicate Google tags, then either load GTM once the browser is idle or switch to advanced consent mode, which loads the tags with consent denied (a legal decision for the site owner). If LCP is poor, check the server response time before you touch GTM.

Which five quick checks can you run in your container?

  1. Open Tags and sort by Type. For every Custom HTML tag, check whether a built-in tag type or a template from Templates → Search Gallery does the same job.
  2. Pause or delete tags nobody uses any more (open the tag → three-dot menu → Pause), then remove triggers and variables that are left without a tag.
  3. Move non-essential tags to a Window Loaded trigger (Triggers → New → Trigger Configuration → Window Loaded).
  4. Run Preview and confirm in Tag Assistant that GA4 sends exactly one page_view per page.
  5. Publish with Submit and test the live site again. A preview does not change what your visitors load.

Sources

Want to know which of your tags cost time? We check your GTM container against your field data and fix what we find. Book a free initial call or see how we handle Google Ads and conversion tracking for our clients.

Need personal advice?

Our Google-certified experts are happy to help – free and without obligation.

Book a meeting