GTM a vliv na rychlost webu

Rychlost webu přestala být technická záležitost a stala se byznysová. Google ji zahrnul do rankingového algoritmu přes Core Web Vitals — a e-commerce data ukazují, že každá sekunda zpoždění stojí přibližně 7 % konverzí. Sekundy, které pravděpodobně vidíte v číslu TBT (Total Blocking Time) ve svém Page Speed reportu.

GTM je v tomhle příběhu klasický podezřelý. Přidáte ho na web, web se zpomalí, závěr je jasný. Problém je, že závěr je špatně.

Google Tag Manager (GTM) samotný přidá na stránku zhruba 33 KB. To je méně než průměrná ikona v SVG. Skutečné zpomalení přijde od skriptů, které přes GTM pouštíte — a záleží víc na tom, jak je pustíte, než na tom, kolik jich máte.

GTM samotný vs. skripty, které do něj dáte

Prázdný GTM kontejner se stáhne, parsuje a spustí. Tím svůj vliv skončil. Co nastane potom, záleží výhradně na tagách uvnitř.

Tabulka níže ukazuje reálné velikosti nejčastějších skriptů po gzip kompresi. Tyhle čísla nejsou akademické — jsou to bajty navíc, které prohlížeč musí parsovat před tím, než stránka začne reagovat na uživatelův klik.

Typický stack na středním e-shopu vypadá takto: GTM + GA4 + Meta Pixel + consent management. To je klidně 400–600 KB JavaScriptu navíc. Než se prohlížeč prokouše tímhle množstvím kódu, uživatel čeká.

Co GTM doopravdy zpomaluje — implementační chyby

Tady je místo, kde se rozhoduje, jestli váš GTM kontejner může být jak slušný soused, tak nepřítel renderování stránky. Google má k tomuhle tématu doporučení pro tagy na webu a dokumentaci k GTM výkonu. Co z nich vyplývá?

Šablony, ne Custom HTML

Custom HTML tag je pro GTM černá skříňka — GTM ho vloží do stránky a nemá žádnou kontrolu nad tím, co se uvnitř děje. Takový tag může řetězově stahovat další skripty, manipulovat s DOMem (a vynutit si tím překreslení stránky) nebo blokovat hlavní vlákno. GTM šablona je oproti tomu řízená: GTM přesně ví, jaké API volání šablona potřebuje, a může je naplánovat efektivněji. Šablona navíc nestahuje kód po částech — je to jeden předpřipravený balíček.

Pokud pro váš nástroj šablona existuje (GA4, Meta Pixel, Clarity, Hotjar — pro všechny existují), použijte ji.

Triggery a timing

Spousta GTM spouští tagy na Page View jen proto, že tenhle trigger byl v GTM už vytvořen. Jenže Page View většinou nastane dřív, než se stránka vykreslí. Pro analytické skripty, heatmapové nástroje a remarketingové pixely není žádný důvod startovat tak brzy.

Rozumný kompromis je DOM Ready — stránka má vykreslený DOM, ale nemusíte čekat na načtení všech obrázků a externích zdrojů.

Výjimkou jsou tagy, kde záleží na rychlosti odeslání — typicky měření transakcí. Tam chcete data odeslat co nejdřív, aby se neztrácela.

Řetězení závislostí proměnných.

Tohle je nejméně diskutovaný zdroj problémů. Situace, kdy proměnná A závisí na proměnné B, která závisí na proměnné C — a GTM musí celý řetěz vyhodnotit synchronně. Viděl jsem kontejnery, kde tohle řetězení přidalo přes 200 ms ke každému page view. Dramaticky.

Pozastavené (paused) tagy kontejner neovlivňují.

Tohle je dobrá zpráva — pauzovaný tag se v kontejneru neobjeví ani neiniciuje. Nicméně pozor na blokovací trigger (výjimku triggeru) – tag s výjimkou sice nevystřelí, ale jeho kód v kontejneru zůstává a zabírá místo. Navíc se pokaždé vyhodnotí triggery. Pokud tag nechcete, pauzněte ho nebo smažte — neblokujte výjimkou.

Nepoužívané proměnné.

Proměnné, které nejsou přiřazené k žádnému tagu, zůstávají v kompilovaném kontejneru. Pokud máte v kontejneru desítky nepoužívaných proměnných, stojí za to je uklidit. Nejen kvůli pořádku, ale i rychlosti.
Tohle je spíš ladění — dopad na výkon je malý.

Mimochodem — GTM má přitom i jiné problémy než jen rychlost — pokud vás zajímá právní stránka věci, k tomu se podrobněji vyjadřuje rozsudek soudu v Hannoveru, který rozhodl, že GTM bez souhlasu porušuje GDPR.

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

Nejdřív zjistěte, jestli vůbec máte co řešit. Otevřete PageSpeed Insights, zadejte svůj web a podívejte se, jestli vám hlásí problémy se skripty třetích stran. 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.

Pokud PageSpeed problémy ukazuje, zkuste si změřit, jak moc váš kontejner zpomaluje. 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.

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 realistické podmínky:

• Záložka Network → zaškrtněte Disable cache (simuluje první návštěvu, ne cachedou)
• Záložka Performance → CPU throttling na 4x slowdown (simuluje průměrný Android telefon, ne váš M3 MacBook)
• Záložka 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: Do testovacího nástroje nikdy nedávejte produkční ID (GA4 Measurement ID, Meta Pixel ID apod.). Jde o playground pro orientační srovnání, ne o prostředí s ostrými daty.

Pokud je rozdíl malý, asi to dále 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, stavíte měřicí framework nebo chcete mít kontejner vyladěný na maximum, otevřete Chrome DevTools.

Krok 1: Nastavte Chrome DevTools (F12) pomalejší připojení, v záložce Network zapněte Disable cache a Network throttling na Fast 4G, v záložce Performance nastavte CPU throttling na 4x slowdown. Simulujete tím reálné podmínky vašich zákazníků na mobilech. Stejně jako v předchozím testu.

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) — čas, kdy hlavní vlákno blokuje interakci
• 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: Přidávejte tagy postupně. Aktivujte tagy jeden po druhém, vždy naměřte, zapište delta. Jedině tak zjistíte, který konkrétní skript za co může.

Krok 4: Porovnejte „s tagy“ vs. „bez tagů“. Výsledný rozdíl v TBT a LCP je váš skutečný „measurement tax“ — cena, kterou platíte za měření.

Na tomhle stupni už má smysl zvažovat i strukturální změny: přepsat Custom HTML tagy na šablony, zrušit řetězení závislostí proměnných, nebo přejít na server-side tracking, který přesune zpracování z prohlížeče na server.

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

Shrnutí a co dál

GTM sám o sobě web nezpomaluje nijak dramaticky. Většinou jsou daleko větší problém skripty uvnitř. Ty byste ale na webu stejně stahovali, byť by to bylo přímo v HTML stránky. Nebo můžete přestat dělat marketing a pak bude web superrychlý 😉

Samotná konfigurace GTM může mít také vliv na výkon webu — špatný trigger timing, neuklidněné proměnné a řetězení závislostí mohou v extrémním případě přidat sekundy navíc.

Postup je jednoduchý: změřte baseline v DevTools, přidávejte skripty postupně, dokumentujte delta. Pokud čísla překračují 1,5 s overhead, je čas na audit nebo přechod na server-side architekturu.

Otestujte svůj web. Pokud nevíte, co s výsledky, nebo chcete pomoci s auditem GTM kontejneru — ozvěte se mi.