{"id":1119,"date":"2026-05-20T15:24:33","date_gmt":"2026-05-20T13:24:33","guid":{"rendered":"https:\/\/www.sabatka.net\/cs\/?p=1119"},"modified":"2026-06-17T20:47:48","modified_gmt":"2026-06-17T18:47:48","slug":"gtm-page-speed-impact","status":"publish","type":"post","link":"https:\/\/www.sabatka.net\/en\/gtm-page-speed-impact\/","title":{"rendered":"GTM and Page Speed: Why Runtime and INP Matter More Than Script Size"},"content":{"rendered":"\n
\n

Updated after a LinkedIn discussion. I reworked and expanded this article based on the discussion underneath it. Thanks to everyone who jumped in.<\/p>\n<\/blockquote>\n\n\n\n

<\/div>\n\n\n\n

Site speed stopped being a developer concern and became a business one. It shows up directly in revenue: Akamai data from 10 billion visits<\/a> found that 53 % of mobile users abandon a site that takes over three seconds to load, and Google and Deloitte measured<\/a> that improving load time by just a tenth of a second lifted retail conversions by 8.4 %.<\/p>\n\n\n\n

“Speed” has two faces. One is how fast the page loads and renders (measured by LCP). The other is how fast the site responds when a user clicks (measured by INP).<\/p>\n\n\n\n

GTM is the usual suspect here. You add it, the site slows down, the conclusion suggests itself. Except that conclusion is usually wrong. And occasionally right. Let’s untangle it.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n
Contact me<\/a><\/div>\n\n\n\n
Share on LinkedIN<\/a><\/div>\n<\/div>\n\n\n\n
<\/div>\n\n\n\n

GTM takes the blame. But it only sometimes deserves it.<\/h2>\n\n\n\n

An empty Google Tag Manager (GTM) container downloads, parses, and runs. The GTM library itself is roughly 33 KB compressed<\/a> \u2014 less than an average SVG icon.<\/p>\n\n\n\n

You could stop here and declare that GTM doesn’t slow your site. More precisely: the container itself doesn’t. However:<\/p>\n\n\n\n

    \n
  1. What you put in GTM has a huge impact.<\/strong> If you load Google Analytics 4 (GA4) and nothing else, the effect is likely minimal. Add Meta pixel, Google Ads, Sklik, Hotjar, and a pile of other tools, and you’re looking at a significant slowdown. And the impact of those tools is usually far bigger than the GTM script itself.<\/li>\n\n\n\n
  2. The way you use GTM can slow the site down too.<\/strong> With large containers built up over years, I see it regularly. The more hands that touched the container over time, the more likely something inside is eating performance.<\/li>\n<\/ol>\n\n\n\n

    I won’t dwell on the first point \u2014 deploying a pile of platforms is a business (or marketing) decision you have to accept. But it’s worth breaking down how to actually use GTM.<\/p>\n\n\n\n

    <\/div>\n\n\n\n

    Page load \u2014 when size matters<\/h2>\n\n\n\n

    Let’s look at two basic metrics \u2014 how big a script is, and how much time it spends on the browser’s main thread.<\/p>\n\n\n\n

    Script<\/strong><\/th>Size (gzip)<\/strong><\/th>Main-thread time<\/strong><\/th><\/tr><\/thead>
    GA4 (gtag.js)<\/td>~135 KB<\/td>108 ms<\/td><\/tr>
    Meta pixel<\/td>~98 KB<\/td>514 ms<\/td><\/tr>
    Hotjar<\/td>~60 KB<\/td>732 ms<\/td><\/tr>
    Microsoft Clarity<\/td>~25 KB<\/td>405 ms<\/td><\/tr>
    LinkedIn Insight Tag<\/td>~10 KB<\/td>133 ms<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Size: measured directly from production scripts (gzip transfer), June 2026. Main-thread time: the median time a script spends on the main thread across all sites where it actually runs \u2014 the third-party-web<\/a> dataset (Patrick Hulce), built on HTTP Archive<\/a> data from Lighthouse measurements of millions of sites, 2024 snapshot.<\/em><\/p>\n\n\n\n

    Notice the mismatch. GA4 is the largest in the table, yet it loads the main thread the least. Clarity is the smallest, and takes nearly 4\u00d7 as much as GA4. A script’s size and its impact on speed are unrelated.<\/strong><\/p>\n\n\n\n

    Why size matters so little: GTM and tags load asynchronously and at low network priority<\/a>. An async script doesn’t block HTML parsing \u2014 the browser fetches it on the side and keeps building the page, even with the snippet sitting in the head. It’s not entirely free, though: tags compete for bandwidth with critical resources, and once downloaded their code runs on the main thread<\/a>. A lot of tags on a slow device can delay rendering \u2014 but that’s a second-order effect. The real hit to LCP comes in two cases: when someone drops a synchronous script (without the async attribute) into the head, blocking page parsing, and with A\/B testing tools that use an anti-flicker snippet, which deliberately hides the page until the test loads<\/a>.<\/p>\n\n\n\n

    What matters is runtime \u2014 how long the code runs on the main thread and blocks it. And size doesn’t help here: even a one-kilobyte script can freeze the browser with one badly written loop. A large library that spreads its work out over time may not hurt at all.<\/p>\n\n\n\n

    By the way, I deliberately left GTM out of the table. In this dataset it actually ranks among the worst \u2014 over 1000 ms<\/a> \u2014 but that’s misleading. GTM is a “loader”: its number includes everything you fire through it. That’s not a property of GTM, it’s the bill for the tags inside. Which is exactly the point of this article.<\/p>\n\n\n\n

    One more note: TBT (Total Blocking Time) sums up all main-thread blocking during load \u2014 including the kind broken into small chunks. But fragmented blocking often doesn’t bother the user at all. What bothers them is a continuous freeze exactly when they want to click. And TBT can’t see that.<\/p>\n\n\n\n

    <\/div>\n\n\n\n

    GTM and how fast your site responds<\/h2>\n\n\n\n

    How fast a site responds to user actions is described by INP (Interaction to Next Paint)<\/a>. It measures something simple: you click (or tap, or press a key) and INP measures how long it takes the site to visibly respond. The fewer milliseconds, the snappier the site feels. A response under 200 ms counts as good.<\/p>\n\n\n\n

    And it’s not a fringe issue: in 2024 only 74 % of mobile sites had good INP versus 97 % on desktop<\/a>. So it’s mainly a mobile problem \u2014 and that’s where GTM and tags hurt most.<\/p>\n\n\n\n

    Why do I talk about INP rather than TBT, which you might know from PageSpeed Insights? Because they measure different things. TBT is calculated in a lab \u2014 Google loads your page on a simulated device and counts blocking during load. INP, on the other hand, is measured on real visitors (Chrome collects it directly). And that’s what reveals the truth: people often click while the page is still loading, when tags are keeping the browser busy \u2014 and a lab test misses that. web.dev<\/a> puts it bluntly: TBT is not a substitute for INP<\/a>. You can have great TBT and still a site that drags under your fingers.<\/p>\n\n\n\n

    That INP isn’t just numbers for Google is shown by case studies: redBus improved INP by 72 % \u2014 and its sales rose 7 %<\/a>. Economic Times cut main-thread blocking \u2014 and its bounce rate dropped by half<\/a>.<\/p>\n\n\n\n

    <\/div>\n\n\n\n

    How GTM hurts INP<\/h2>\n\n\n\n

    Loading GTM and tags at the start barely affects INP \u2014 the browser gets that out of the way when the page starts. What hurts response to clicks is something else: tags that install “watchers” across the whole page \u2014 on every click, scroll, or mouse move. Auto-event tracking, some heatmaps, and session recorders do this routinely. Such a watcher doesn’t run once. It fires on every interaction and inserts its code between your click and the site’s response \u2014 right into the window INP measures. The more such watchers on the page, the lazier every further click. So it’s not so much about GTM’s size as about what the specific tags inside do once the site is running.<\/p>\n\n\n\n

    And what about GTM’s own built-in triggers \u2014 Click and Form Submission? They watch the whole page too, but do it efficiently: GTM doesn’t attach a listener to every element, just a single one on the document<\/a>. The listener itself is light \u2014 it only reports that a click or form submit happened. What loads INP is what you hang on that event, and one specific trigger: “Click \u2013 All Elements” reacts to literally every click anywhere on the page. How to keep the built-in triggers in check, I cover in the next chapter.<\/p>\n\n\n\n

    <\/div>\n\n\n\n

    How to keep GTM fast<\/h2>\n\n\n\n

    There are a few techniques for making GTM as fast as possible.<\/p>\n\n\n\n

    Custom JavaScript variables that recompute over and over.<\/strong> Every custom JS variable in GTM is a function the browser evaluates synchronously on the main thread \u2014 again, every time something references it. The variable’s size doesn’t matter. Two things hurt. First, chaining: variable A reads variable B, which reads variable C \u2014 and every use of A runs the whole cascade again. Second, computationally heavy operations inside: a regex over long text, parsing a large JSON, walking the entire DOM or a growing dataLayer. On a classic site this gets lost, but in a single-page app the dataLayer grows with every page view \u2014 and the same variables and tags walk it again and again. Real-world measurements<\/a> show how this pushes individual tag execution from tens of milliseconds into the hundreds, even seconds. And by the way \u2014 the number of variables isn’t the problem; have thousands of them. What matters is what they do.<\/p>\n\n\n\n

    Ask developers for clean data.<\/strong> The ideal looks like this: the developer hands clean, complete data into the dataLayer, and in GTM you just read it without computing anything. Note: in practice that often doesn’t happen and you need to clean, filter, and derive data in GTM. Just do it as little as possible.<\/p>\n\n\n\n

    Measure interactions only after the response renders<\/strong> \u2014 if a developer passes you information about an interaction, defer the dataLayer.push()<\/code> as late as possible (ideally after the response renders) \u2014 it saves tens of milliseconds of INP<\/a>. The logic stays, the runtime work drops.<\/p>\n\n\n\n

    Templates, not Custom HTML.<\/strong> A Custom HTML tag is a chunk of code GTM injects into the page at runtime \u2014 and the browser has work to do every time it runs. A template does the same thing more cheaply: it’s prepared up front and GTM runs it in a controlled way. Templates also have template storage<\/a>: you can store the result of a heavier computation and just read the value for the rest of the page’s life \u2014 so the computation runs only once. If a template exists for your tool (GA4, Meta pixel, Clarity, Hotjar \u2014 they all do), use it.<\/p>\n\n\n\n

    Use simple triggers.<\/strong> Every event push in the dataLayer runs through all active triggers, evaluates their conditions, and resolves the variables those conditions touch. The more events flowing and the heavier the variables in the conditions, the more work on every event. So build trigger conditions on values already in the dataLayer \u2014 not on variables that have to compute something.<\/p>\n\n\n\n

    Enable built-in click and form listeners deliberately.<\/strong> The “Click \u2013 All Elements” trigger captures literally every click on the page, so GTM evaluates something even for clicks you don’t measure at all. If links are enough for you, use “Just Links”; otherwise constrain the trigger with a condition<\/a> (URL or CSS selector) to what you actually track. Google recommends this itself, anyway.<\/p>\n\n\n\n

    Don’t fire tags too early.<\/strong> Lots of tags fire on Page View, “because that’s how it’s always been.” But Page View happens before the page renders. Analytics, heatmap, and remarketing tags have no reason to start that early \u2014 DOM Ready is a sensible compromise. The exception is tags where send speed matters, typically transaction measurement.<\/p>\n\n\n\n

    Cleanup (paused tags, exceptions, unused variables).<\/strong> A paused or deleted tag is excluded from the container. But watch out for blocking via an exception: a tag that “never fires” thanks to a trigger exception still stays in the container \u2014 downloaded and compiled for nothing. If you don’t want a tag, pause or delete it \u2014 don’t block it with an exception. And unused variables stay in the compiled container too, so clean them out from time to time.<\/p>\n\n\n\n

    By the way \u2014 GTM has concerns beyond speed. On the legal side, the Hannover court ruling that GTM without consent violates GDPR<\/a> goes into detail. And if you gate tag firing on consent, check the most common mistakes in cookie banner setup<\/a> too.<\/p>\n\n\n\n

    <\/div>\n\n\n\n

    Is there a problem? And how big?<\/h2>\n\n\n\n

    First, find out whether there’s anything to fix at all. I built a playground for it at sandbox.sabatka.net\/speed\/start<\/a> \u2014 it compares your configuration against an empty container running just a basic GA4 tag. You’ll see the relative difference. It’s not a precise benchmark, but you’ll immediately know whether the problem is negligible or not.<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \n
    GTM speed sandbox<\/a><\/div>\n<\/div>\n\n\n\n
    <\/div>\n\n\n\n

    For a quick second opinion, use PageSpeed Insights<\/a> \u2014 enter your URL and check whether it flags third-party script issues or poor INP. If not, don’t bother. Focus on something that actually helps, like content or conversions.<\/p>\n\n\n\n

    If you want to measure it yourself, set up realistic conditions:<\/p>\n\n\n\n

    Step 1: Copy your production container.<\/strong> Never test in production. Remove or deactivate production IDs (GA4 Measurement ID, Meta pixel ID, etc.) \u2014 otherwise you’ll send test data to live accounts, and GA4 doesn’t offer a clean way to filter that out retroactively.<\/p>\n\n\n\n

    Step 2: Set up test conditions.<\/strong> Open DevTools (F12) and set:<\/p>\n\n\n\n