GTM a vliv na rychlost webu

Článek jsem po diskuzi na LinkedIN výrazně přepracoval a doplnil na základě diskuze pod ním. Díky všem, kdo se do ní pustili.

Rychlost webu přestala být věc pro vývojáře a stala se byznysovou. Promítá se přímo do peněz: data Akamai z 10 miliard návštěv ukázala, že 53 % lidí na mobilu opustí web, který se načítá přes tři sekundy, a Google s Deloitte naměřili, že zrychlení o pouhou desetinu sekundy zvedlo konverze v retailu o 8,4 %.

„Rychlost“ má dvě tváře. Jedna je, jak rychle se stránka načte a vykreslí (měří ji LCP). Druhá je, jak rychle web zareaguje, když na něj uživatel klikne (měří ji INP).

GTM je v tomhle příběhu klasický podezřelý. Přidáte ho na web, web se zpomalí, závěr se nabízí. Jenže ten závěr je většinou špatně. A občas správně. Pojďme to rozplést.

GTM bývá obětní beránek. Oprávněně ale jen někdy.

Prázdný kontejner Google Tag Manageru (GTM) se stáhne, naparsuje a spustí. Samotná knihovna GTM je velká zhruba 33 KB po kompresi — méně než průměrná ikona v SVG.

Tady by se dalo udělat tečku a prohlásit, že GTM web nezpomaluje. Přesněji: samotný kontejner ne. Nicméně:

1. Obrovský vliv má, co v GTM máte pokud načítáte Google Analytics 4 (GA4) a nic dalšího, bude vliv pravděpodobně minimální. Pokud přidáte Meta pixel, Google Ads, Sklik, Hotjar a hromadu dalších nástrojů, bude to znamenat významné zpomalení. A vliv těchto nástrojů na rychlost bývá výrazně větší než samotný skript GTM.
2. Způsob, jakým GTM používáte, web zpomalit může u velkých, roky budovaných kontejnerů to vídám docela běžně. Čím víc rukou do kontejneru během let sahalo, tím spíš v něm něco požírá výkon.

Nebudu se zabývat prvním bodem — nasazení hromady platforem je byznysové (nebo marketingové) rozhodnutí, které je třeba akceptovat. Dává ale smysl rozebrat, jak tedy GTM používat.

Načtení stránky — když na velikosti záleží

Pojďme se podívat na dvě základní metriky — jak velký skript je a kolik času skript spotřebuje na hlavním vlákně prohlížeče.

Velikost: změřeno přímo z produkčních skriptů (gzip přenos), červen 2026. Čas na hlavním vlákně: medián doby, kterou skript spotřebuje na hlavním vlákně napříč všemi weby, kde reálně běží — dataset third-party-web (Patrick Hulce), postavený na datech HTTP Archive z měření milionů webů v Lighthouse, snapshot 2024.

Všimněte si toho nesouladu. GA4 je v tabulce největší, a přitom hlavní vlákno zatíží nejmíň. Clarity je nejmenší, a zabere skoro 4× tolik co GA4. Velikost skriptu a jeho dopad na rychlost spolu nesouvisí.

Proč velikost tolik nerozhoduje: GTM i tagy se načítají asynchronně a s nízkou síťovou prioritou. Asynchronní skript neblokuje zpracování HTML — prohlížeč ho stahuje bokem a stránku staví dál, i když snippet sedí v hlavičce stránky. Úplně zadarmo to ale není: tagy soupeří o šířku pásma s kritickými zdroji a po stažení se jejich kód vykonává na hlavním vlákně. Hodně tagů na pomalém zařízení proto vykreslení zdržet dokáže — bývá to ale efekt druhého řádu. Skutečný zásah do LCP přijde ve dvou případech: když někdo vloží do hlavičky synchronní skript (bez atributu async), který parsování stránky blokuje, a u A/B testovacích nástrojů s anti-flicker snippetem, který stránku záměrně skryje, dokud se test nenačte.

Co rozhoduje, je runtime — jak dlouho kód běží na hlavním vlákně a blokuje ho. A tady velikost nepomáhá: i jednokilobajtový skript dokáže prohlížeč zaseknout, stačí špatně napsaná smyčka. Naopak velká knihovna, která se chytře rozloží v čase, nemusí vadit vůbec.

Mimochodem, schválně jsem do tabulky nedal samotný GTM. V téhle statistice totiž vychází jako jeden z nejhorších — přes 1000 ms — jenže to je klam. GTM je „loader“: do jeho čísla se počítá všechno, co přes něj spustíte. Není to vlastnost GTM, je to účet za tagy uvnitř. Což je přesně pointa celého článku.

Ještě poznamenám, že TBT (Total Blocking Time) sčítá veškerou blokaci hlavního vlákna během načítání — i tu rozdrobenou do malých dávek. Jenže rozdrobená blokace uživatele často vůbec netrápí. Co ho trápí, je souvislé zaseknutí přesně ve chvíli, kdy chce kliknout. A to TBT nepozná.

GTM a rychlost odezvy webu

Jak rychle web reaguje na akce uživatele popisuje metrika INP (Interaction to Next Paint). Měří jednoduchou věc: kliknete (nebo kliknete myčí či zmáčknete klávesu) a INP změří, za jak dlouho na to web viditelně zareaguje. Čím méně milisekund, tím svižější web pod prsty. Za dobrou hodnotu se považuje odezva do 200 ms.

A není to okrajová věc: v roce 2024 mělo dobré INP jen 74 % mobilních webů oproti 97 % desktopových. Je to tedy hlavně mobilní problém — a tam GTM a tagy bolí nejvíc.

Že INP nejsou jen čísla pro Google, ukazují případovky: redBus zlepšil INP o 72 % — a prodeje mu vzrostly o 7 %. Economic Times srazil dobu blokace hlavního vlákna — a bounce rate mu klesl o polovinu.

Jak GTM zhoršuje INP

Samotné načtení GTM a tagů při načtení stránly má na INP vliv minimální. Odezvu na klikání zhoršuje něco jiného – tagy, které si nasadí „posluchače“ na celou stránku — na každý klik, scroll nebo pohyb myší. Dělají to běžně auto-event tracking, některé heatmapy a session recordery. Takový hlídač se totiž nespustí jednou. Naskočí při každé interakci a vloží svůj kód mezi váš klik a reakci webu — přesně do okénka, které INP měří. Čím víc takových hlídačů na stránce je, tím línější je každé další kliknutí. Není to tedy ani tak o velikosti GTM, jako o tom, co konkrétní tagy uvnitř dělají, když už web běží.

A co vestavěné spouštěče samotného GTM — Click a Form Submission? Ty sledují celou stránku taky, ale dělají to úsporně: GTM nenasazuje posluchač na každý prvek, ale jediný na celý dokument. Sám o sobě je lehký — jen ohlásí, že se kliklo nebo odeslal formulář. INP zatíží teprve to, co na tu událost navěsíte, a jeden konkrétní spouštěč: „Click – All Elements“ reaguje doslova na každé kliknutí kdekoli na stránce. Jak vestavěné spouštěče krotit, ukažuju v další kapitole.

Jak pracovat v GTM, aby byl rychlý

Je několik technik pro to, jak udělat GTM co nejrychlejší.

Custom JavaScript proměnné, které se počítají pořád dokola. Každá custom JS proměnná v GTM je funkce, kterou prohlížeč vyhodnotí synchronně na hlavním vlákně — a to znovu pokaždé, když se na ni někdo odkáže. Nerozhoduje přitom, jak je proměnná malá. Bolí dvě věci. Zaprvé řetězení: proměnná A čte proměnnou B, ta čte proměnnou C — a každé použití proměnné A spustí celou kaskádu znovu. Zadruhé výpočetně náročné operace uvnitř: regulární výraz nad dlouhým textem, parsování velkého JSONu, procházení celého DOMu nebo rostoucího dataLayer. Na klasickém webu se to ztratí, ale na single-page aplikaci dataLayer s každým dalším page view roste — a tytéž proměnné a tagy ho procházejí znovu a znovu. Měření z praxe ukazují, jak se kvůli tomu doba běhu jednotlivých tagů vyšplhá z desítek milisekund na stovky až jednotky sekund. Mimochodem — sám počet proměnných problém není; klidně jich mějte tisíce. Záleží, co dělají.

Chtějte čistá data od vývojářů. Ideál vypadá takhle: vývojář předá do dataLayer čistá a kompletní data, v GTM je jen čtete a nic nedopočítáváte. Pozn.: v praxi to tak často nefunguje a data potřebujete v GTM čistit, filtrovat a dopočítávat. Dělejte to ale co nejméně.

Interakce měřte až po vykreslení odezvy – pokud vám předává programátor informace o interakci s webem, odložte volání dataLayer.push() na co nejpozději (ideálně až po vykreslení odezvy) — ušetří to desítky milisekund INP. Logika zůstává, práce za běhu klesne.

Šablony, ne Custom HTML. Custom HTML tag je kus kódu, který GTM vkládá do stránky až za běhu — a prohlížeč s ním má práci při každém spuštění. Šablona umí totéž úsporněji: je připravená dopředu a GTM ji spouští kontrolovaně. Šablony navíc mají template storage: výsledek náročnějšího výpočtu můžete uložit a po zbytek života načtené stránky hodnotu jen číst— výpočet tak proběhne jedinkrát. Pokud pro váš nástroj šablona existuje (GA4, Meta pixel, Clarity, Hotjar — pro všechny existují), použijte ji.

Používejte jednoduché triggery. Každý event push v dataLayeru projde všechny aktivní triggery, vyhodnotí jejich podmínky a k tomu vyřeší proměnné, na které sahají. Čím víc událostí teče a čím těžší proměnné v podmínkách jsou, tím víc práce při každé události. Podmínky triggerů proto stavějte na hodnotách, které už v dataLayer jsou — ne na proměnných, které musí něco počítat.

Vestavěné click a form listenery zapínejte cíleně. Spouštěč „Click – All Elements“ odchytává úplně každé kliknutí na stránce, takže GTM něco vyhodnocuje i u kliknutí, která vůbec neměříte. Když vám stačí odkazy, sáhněte po „Just Links“; jinde spouštěč omezte podmínkou (URL nebo CSS selektor) na to, co opravdu sledujete. Google to ostatně doporučuje sám.

Nespouštějte tagy zbytečně brzo. Spousta tagů se spouští na Page View, „protože to tak bylo vždy“. Jenže Page View nastane dřív, než se stránka vykreslí. Analytické, heatmapové a remarketingové tagy nemají důvod startovat tak brzy — rozumný kompromis je DOM Ready. Výjimka jsou tagy, kde záleží na rychlosti odeslání, typicky měření transakcí.

Úklid (paused tagy, výjimky, nepoužívané proměnné). Pozastavený nebo smazaný tag se z kontejneru vyřadí. Pozor ale na blokování výjimkou: tag, který „nikdy nevystřelí“ díky výjimce triggeru, v kontejneru i tak zůstává — stahuje a kompiluje se zbytečně. Pokud tag nechcete, pausněte ho nebo smažte — neblokujte výjimkou. A nepoužívané proměnné v kompilovaném kontejneru zůstávají taky, takže je čas od času ukliďte.

Mimochodem — GTM má i jiné problémy než rychlost. K té právní stránce se podrobně vyjadřuje rozsudek soudu v Hannoveru, který rozhodl, že GTM bez souhlasu porušuje GDPR. A pokud spouštění tagů řídíte souhlasem, zkontrolujte si i nejčastější chyby v nastavení cookie lišt.

Máte problém? A jak velký?

Nejdřív zjistěte, jestli vůbec máte co řešit. Připravil jsem na to playground na sandbox.sabatka.net/speed/start — porovná vaši konfiguraci s prázdným kontejnerem, ve kterém běží jen základní GA4 tag. Uvidíte relativní rozdíl. Není to přesný benchmark, ale okamžitě poznáte, jestli je problém zanedbatelný, nebo ne.

Rychlý druhý pohled nabídne PageSpeed Insights — zadejte svůj web a podívejte se, jestli hlásí problémy se skripty třetích stran nebo špatné INP. Pokud ne, neřešte to. Soustřeďte se na něco, co vám reálně pomůže, třeba na obsah nebo konverze.

Když chcete změřit sami, nastavte realistické podmínky:

Krok 1: Udělejte kopii produkčního kontejneru. Nikdy netestujte přímo v produkci. Odstraňte nebo deaktivujte produkční ID (GA4 Measurement ID, Meta pixel ID atd.) — jinak budete posílat testovací data do ostrých účtů, a to v GA4 nejde snadno odfiltrovat zpětně.

Krok 2: Nastavte podmínky testování. Otevřete DevTools (F12) a nastavte:

• Network → Disable cache (simuluje první návštěvu)
• Performance → CPU throttling na 4x slowdown (průměrný Android, ne váš M3 MacBook)
• Network → Network throttling na Fast 4G

Vaši zákazníci na mobilech jsou přesně v těchto podmínkách — nebo horších.

Pozor: Totéž platí pro sandbox playground — nikdy do něj nezadávejte produkční ID (GA4 Measurement ID, Meta pixel ID apod.). Jde o orientační srovnání, ne o prostředí s ostrými daty.

Pokud je rozdíl malý, asi to dál nemusíte řešit. Projděte jednou za čas obsah kontejneru — vyhoďte tagy, které už nepoužíváte, ukliďte nepoužívané proměnné, přesuňte analytické a remarketingové tagy z Page View na DOM Ready. Tohle samo o sobě často stačí.

Vědecká poznámka

Tohle je Observer Effect — princip z kvantové fyziky, podle kterého samotné měření ovlivňuje měřený jev. Každý tag, který přidáte pro měření, zpomaluje web, jehož výkon chcete měřit. Čím víc měříte, tím pomalejší web máte.

Když chcete jít do hloubky — Chrome DevTools

Pokud řešíte opravdu každou milisekundu nebo chcete kontejner vyladěný na maximum, otevřete Chrome DevTools.

Krok 1: Nastavte realistické podmínky. Stejně jako výše — Disable cache, Network throttling na Fast 4G, CPU throttling na 4x slowdown.

Krok 2: Naměřte baseline. Otestujte stránku s GTM načteným, ale prázdným (všechny tagy pausnuté). Zaznamenejte:

• TBT (Total Blocking Time) — kolik hlavní vlákno blokuje při načítání
• LCP (Largest Contentful Paint) — kdy se zobrazí největší viditelný element
• Waterfall v záložce Network — pořadí a délka stahování skriptů

Krok 3: Změřte i interakci, ne jen načtení. Tohle je část, kterou většina testů vynechá. Po načtení proveďte typické interakce — klik do menu, otevření filtru, přidání do košíku — a v záložce Performance sledujte, jak dlouho běží hlavní vlákno mezi kliknutím a překreslením. Tady se ukážou globální posluchače, které kazí INP. Záznam reálné interakce vám řekne víc než jakékoli číslo z laboratoře.

Krok 4: Přidávejte tagy postupně. Aktivujte tagy jeden po druhém, vždy naměřte načtení i interakci, zapište deltu. Jedině tak zjistíte, který konkrétní skript za co může.

Na tomhle stupni už má smysl zvažovat i strukturální změny: přepsat Custom HTML tagy na šablony, odlehčit těžké proměnné, rozbít dlouhé úlohy na hlavním vlákně, nebo přejít na server-side tracking, který přesune část zpracování z prohlížeče na server.

Jaké chyby v měření se při takových auditech nacházejí nejčastěji, jsem popsal v přednášce na MeasureCamp Czechia.

Shrnutí a co dál

Samotný GTM kontejner web nezpomaluje nijak dramaticky — 33 KB a dost. Co web zpomaluje doopravdy, je obsah kontejneru — tagy, které přes něj načítáte. Svůj podíl má ale i způsob, jakým GTM používáte: nastavení tagů, triggerů a proměnných. O dopadu přitom nerozhoduje velikost skriptů, jak se často píše. Rozhoduje, co kód dělá za běhu a jak rychle web zareaguje na klik.

A poslední věc na pravou míru — k SEO. Core Web Vitals jsou jedním ze signálů, které Google posuzuje, ne dominantní faktor. Relevantní obsah se umístí i na pomalejším webu. Rychlost slabý obsah nezachrání — ale za jinak srovnatelného obsahu rozhoduje, a hlavně vám ovlivňuje konverze a míru opuštění. Což je nakonec důležitější než pozice ve výsledcích.

Postup zůstává stejný: změřte Core Web Vitals, než začnete optimalizovat. Nejrychleji přes PageSpeed Insights, dlouhodobě na reálných uživatelích v Search Console; další nástroje shrnuje tenhle přehled.