Keeping Websites Fast when Loading Google Tag Manager

In 2024, the average JavaScript payload on mobile jumped 14% to around 558 KB (source), which means phones (and other devices) had to work harder. A whopping 92% of web pages use third-party stuff, often through Google Tag Manager (GTM), and that can significantly bog down websites' performance.

Here is a thing: Google Tag Manager itself isn't the villain; it's all the third-party tags, custom HTML, and early-firing triggers hidden inside it.

Optimizing GTM is a big deal for both engineers (to stay within performance limits) and business/marketing folks (to boost user experience, SEO, and conversions). You can speed things up and make users happier by holding off on loading tags, only loading them with consent, or switching to server-side loading.

Let’s discuss why and how we can turn things around and achieve that high-performance score again, while keeping Google Tag Manager.

(Just make sure to measure any changes so you don't accidentally make things worse!)

Google Tag Manager (GTM) is a free tool from Google that allows you to manage and deploy marketing tags (snippets of code or tracking pixels) on your website (or mobile app) without having to modify the code.

This simplifies the process of implementing and maintaining various types of tracking and marketing optimization tags, including Google Analytics tracking codes, AdWords conversion scripts, and other similar tags.

Google Tag Manager simplifies the process of implementing tags on a website or mobile app, allowing marketers and webmasters to add, update, and manage tags without relying on developers to change the site code.

This means the process is easy to follow:

• Setup and Configuration. The first step involves creating a new account and container in the Google Tag Manager interface. A container typically corresponds to a website or a mobile app. Once the container is created, GTM generates a block of code for you to add to every page of your website. This code enables GTM to control when and where tags are fired.

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXX');</script>
<!-- End Google Tag Manager -->

• Tag Creation. Within the GTM interface, you can add various types of tags tailored to your specific tracking needs. For instance, you might create a Google Analytics pageview tag to track views of all pages or an AdWords conversion tag to track particular conversions. GTM supports a wide range of tag templates from Google and other third parties, as well as custom tags.
• Triggers and Variables. Triggers are the rules that determine when a tag should be fired, and variables provide additional information that may be needed for the tag to work correctly. For instance, a trigger might be set to fire a tag whenever a specific page is viewed, and a variable might be used to pass the value of a specific form field to that tag. GTM offers a variety of pre-defined triggers and variables, as well as the ability to create custom ones.
• Testing and Deployment. Before deploying tags, GTM provides a "Preview" mode that allows you to test and verify your setup. Once you've tested your tags and are confident they're working as intended, you can publish them to your live website or app with the click of a button.

These lines of code will download the GTM handler and register a global object, defaulted to “dataLayer”, which you use to talk to GTM. GTM will now load all the scripts that you have defined in your GTM account that should run when the page loads.

You can probably see the core components of GTM:

• Container: the bundle you publish that holds all your tags, triggers, and variables. One container per site (or per logical part of the site) keeps things manageable.
• Tags: bits of code (pixels, scripts, analytics, tracking) that fire under conditions you define. Some are essential, others are optional or experimental.
• Triggers: rules that define when (or under what conditions) a tag runs—on page load, click, scroll, custom events, etc.
• Variables: reusable values (dataLayer, custom variables, built-ins like page URL, etc.) that tags and triggers depend on.

This flexibility enables more rapid deployment of tracking and marketing optimization scripts, allowing businesses to adapt quickly to their analytics and marketing needs.

But it needs to be optimized, and that's not as easy as it sounds.

You should think of Google Tag Manager (GTM) as a power tool: super useful when used correctly, dangerous when mis-handled. Its strengths lie in flexibility, ease of deployment, and control. But its weaknesses are subtle, often hidden, and yet very real.

On the strengths side: GTM gives marketers the ability to deploy tracking tags, pixels, and analytics tools without requiring a full developer cycle. Need a new marketing tag for a campaign? GTM lets you add it, configure its trigger, publish, and go live.

Engineers love that GTM provides version control, workspaces, and preview/debug modes. Everything is centralized in one container, which helps with maintenance, rollback, and minimizing duplication. For business folks, this means faster time to market, more experimentation, and less dependency on engineering resources.

But, and this is where things get tricky, GTM’s weaknesses come into play when that flexibility is treated as a set-and-forget system. One of the biggest pitfalls is tag sprawl. Over time, as campaigns, third-party tools, A/B experiments, heat-maps, chat widgets, etc., are added, the container grows in complexity. Some tags run on every page; some fire early; many do things that aren’t strictly needed for initial page load or immediate user interaction.

Hidden performance costs also pile up. Custom HTML tags that manipulate the DOM, synchronous load behavior, or tags that trigger too early can block rendering or delay interactivity. Debugging becomes more challenging when you have dozens of triggers and variables interacting, especially when tags depend on dataLayer pushes or external resources that may be slow or unreliable.

So yes: GTM is powerful. It gives business agility. But without governance, dependency on monitoring, and regular auditing, its weaknesses can outweigh its strengths.

Slowing down may sound vague, but in modern web performance, it refers to the things you and real users feel: pages taking too long to load, buttons not responding for a moment, and layout shifts that cause clicks to land in the wrong spot.

These experiences are captured in metrics like Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS), which BTW can and should be your frontend performance KPIs (measure, monitor, and cultivate a performance-first culture).

Analytics Mania ran tests comparing an empty GTM container versus containers loaded with multiple (8, 100, or more) custom HTML tags. They found that an empty GTM container has minimal impact. The real cost comes from what’s inside: tags that manipulate the DOM, heavy custom HTML, or many tags firing early. In one test, 100 Custom HTML tags performing basic DOM insertions added hundreds of milliseconds to initial load; more complex tasks pushed up Time to Interactive (TBT) by 2-3 seconds.

web.dev, notes that large containers are warning signs: Google already imposes a container size limit (~300 KB) and recommends keeping containers well below that. A bloated container often correlates with misused or redundant tags.

So, what are the common problem patterns that show up over and over? Custom HTML tags that do heavy DOM querying or manipulation (e.g. document.querySelectorAll, insertAfter/insertBefore), especially when placed in the head or early in the body. Even simple scripts, when repeated, add up.

Excessive triggers firing on All Pages. Sometimes marketing tags are firing even on pages or for users where they aren’t needed.

Overuse of third-party pixels (ads, tracking, widgets). Each external script adds network requests, potential blocking, unpredictable latency, or dependency (if the third party is slow, down, or poorly optimized). 

Finally, tags that are executed synchronously, or tags that wait for window.load or similar late events, increase perceived delay in interactivity.

So, in short: GTM by itself isn’t slow, but GTM + too many tags + early/poor triggers + heavy custom code = real performance pain for users.

If GTM’s slowing your site, the good news is three levers tend to give you the best bang for buck—preconnect, lazy-load, and server-side tagging. What’s key is knowing when each one helps, and what trade-offs you accept.

Imagine you know that your GTM container will kick off a request to googletagmanager.com, or that analytics scripts hosted elsewhere are needed almost immediately after first paint. Preconnect allows the browser to begin the connection handshake (DNS lookup, TCP, TLS) before those requests are actually required.

If you do it correctly, it reduces latency. If you do it excessively, you open many connections early that may never be used.

How to implement safely:

<link rel="preconnect" href="https://www.googletagmanager.com" crossorigin>
<link rel="dns-prefetch" href="//www.googletagmanager.com">

• Add the preconnect only if the GTM container or its tags are required on the initial view.
• Use crossorigin when the origin requests require it (e.g., loading related resources that depend on CORS).
• Pair with dns-prefetch for domains used less critically or later.

When it helps vs when it's wasteful:

• Helps if you care about first contentful paint / first meaningful paint / if you fire crucial tags promptly.
• Wasteful if those tags are deferred, consent-gated, or rarely used; or if network overhead (such as sockets and early TLS) hurts more than delay.

Let’s say some tags are nice to have—heat maps, additional marketing pixels, or maybe certain A/B Tests—not critical for the first view. Lazy-loading or deferring them until after user interaction, or gating based on consent, can remove work from the critical rendering path.

Implementation suggestions:

• Use triggers in GTM, like first user interaction (scroll, click, pointer) to launch non-critical tags.
• Wrap tags in custom events fired only after consent (if your region or business needs consent) or after some idle time (e.g., .requestIdleCallback)
• Move tags out of the <head> section or avoid synchronous inline scripts.

When to use / when not:

• Use when you have lots of non-essential tags that fire early and interfere with LCP or TBT.
• When user consent policies require delaying marketing tags.
• Don’t use when those tags are strictly revenue-critical (e.g., ad-bidding, essential conversion tracking) and early data is needed, or when event loss from bounced sessions would hurt attribution badly.

This is shifting the heavy lifting off the user’s browser and into a server environment you control. With server-side GTM (sGTM), the browser sends a lighter set of data/events; your server receives that, processes/filters/enriches/transforms it, and then dispatches it to third-party tools (such as Google Analytics and Facebook). This reduces client-side overhead, helps with latency, privacy, and often consistency of data.

What implementing server-side involves:

• Set up a server container (e.g., Cloud Run in Google infra) to receive data from your web container.
• Move non-compatible or privacy-sensitive tags (e.g., ad network pixels, third-party trackers) to be handled server-side.
• Ensure data validation, transformations, and obey legal consent rules in the server environment.
• Use a custom domain so that the browser sees fewer third-party domains (helps with cookie policies, ad blockers).

When it helps & trade-offs:

• Helps when your site has a heavy tag load, you suffer from client performance issues (long TBT, slow input responsiveness), or you need stronger privacy/compliance controls. Also helps recover data lost due to ad blockers or browser restrictions.
• Trade-offs include added complexity and cost; you’ll pay for server infrastructure, maintenance logic, testing, and possibly increased latency between the browser and your server. Additionally, some tools don’t support server-side tagging or lose features when used outside the browser.

Finally, if you don’t have an existing GTM setup to worry about, using Partytown to manage GTM might be a good idea. It works by moving all script execution to its web worker, freeing up the main browser thread to handle only application code.

In theory, it will resolve most of the performance issues mentioned; however, there is a chance that not all scripts will work out of the box, as they are not running in their usual context.

When you’ve made changes, preconnect, lazy-loading, server-side, the only way to know whether they helped is to measure, first in controlled lab settings, then with real users in the field.

Remember how we talked about frontend performance KPIs? We've put together a simple how-to measure table (before vs. after) to help you out. Keep in mind that boosting performance is an ongoing process, not a one-time deal.

Sometimes you make changes, but things still don’t improve. What then? Well…

First, make sure you do not compare apples to oranges, e.g., baseline lab test done on “Fast 3G”, then change tested on “Slow 4G”, or vice versa. Always keep lab settings comparable.

If your traffic is low or users are mostly desktop, CrUX or other field metrics might lag or be noisy. Expect error bars.

If you delay conversion tags or analytics until the first interaction or after consent, you might miss some early events. Track drop-off/funnel metrics to see if this matters.

Watch not to over-optimize without understanding business priorities. For example, removing/restricting tags so much that marketing tracking, attribution, or ad performance suffers—leading to loss of revenue that outweighs performance gains.

When your site’s still feeling laggy after you think you’ve done your optimizations and you’ve avoided the common pitfalls, you need a methodical flow to gain clarity and improvement: first, find what causes the slowness, fix it, then verify the fix.

Identify → Mitigate → Re-measure

Start by taking inventory and diagnosing. List every tag, trigger, and variable in your GTM container. Include custom HTML tags, third-party pixels, chat widgets, experiment/tracking tools, etc. Note which tags fire on every page, which ones fire early in the page load, and which are deferred/after interaction.

Run Lighthouse or WebPageTest on a few representative pages (mobile, slow network) to see how tags contribute to network requests, blocking scripts, and long tasks. Then check for pages with high LCP / INP / TBT in field metrics. Identify which pages have worse performance and correlate with the firing of multiple tags early.

Use GTM’s preview/debug mode to see if tags are firing when expected. Validate dataLayer variables and see whether some tags are misfiring (duplicate triggers, incorrect conditions).

Once you know what’s heavy or wrong, move through mitigation options—from quick wins to more structural changes.

Don’t assume mitigation worked—verify with data. Use the same test setup as the baseline, i.e., the same pages, devices, and network throttling in the lab; the same segments in the field. Then capture core metrics again.

Check for collateral effects, ie, did lazy-loading cost you events? Did attribution shift? Did conversion tracking lose fidelity? For example, if you deferred a purchase confirmation tag, are sales being recorded accurately or not?

Finally, watch field metrics over time. Spike regressions or bounce rates may reveal issues the lab misses (e.g., device-specific or geography-specific lag).

As we said, fixing GTM isn’t one-and-done.

For developers, optimizing your GTM setup means faster load times, improved Core Web Vitals (LCP, INP, TBT, etc.), and fewer unpredictable third-party delays. That improves maintainability, user experience, and often makes debugging easier—fewer flaky tags, cleaner logic, faster interactive states.

For businesses, the upside is equally strong. Faster pages = happier users. Better SEO and ranking, lower bounce rates, and happier marketing/analytics stakeholders because the data you rely on becomes more accurate and more actionable.

But caution is necessary.

Optimizing GTM isn’t all upside. Some trade-offs are bound to happen. For example, if you delay or lazy-load tags, you might miss events from users who leave before those lazy-load tags fire. Or moving things server-side can reduce client overhead—but adds complexity.

Optimizing GTM (or switching to one of Google Tag Manager alternatives) is one of those high-leverage moves: done well, it yields real performance wins, happier users, and cleaner data—both a technical win and a business win.

But done hastily, or without measuring, the risks (data gaps, costs, broken tracking) can outweigh the gains.