⚡ GTM i szybkość strony: testy, wnioski i 8 sposobów na przyspieszenie witryny

Marketerzy lubią powtarzać: „Google Tag Manager przyspiesza stronę, strony z GTM ładują się szybciej". Deweloperzy zazwyczaj spierają się: „GTM tylko spowalnia". Prawda, jak zwykle, leży pomiędzy tymi skrajnościami.

Przeprowadziliśmy serię testów z różnymi konfiguracjami GTM: pusty kontener, kontener z 8 kodami śledzącymi, tagi wstawione na sztywno, różne momenty wyzwalania reguł, dziesiątki niestandardowych tagów HTML z manipulacjami DOM. Mierzyliśmy szybkość za pomocą webpagetest.org i Lighthouse. Wyniki okazały się nie tak jednoznaczne, jak piszą w prezentacjach GTM.

Oto, co ustaliliśmy: sam kontener GTM prawie nie spowalnia, ale to, co do niego włożycie, może dodać i 3, i 10 sekund do ładowania. I co najważniejsze: można tym sterować.

💡 Szybki przegląd:

Pusty kontener GTM dodaje do ładowania około 100 milisekund
Osiem tagów śledzących przez GTM spowalnia stronę o 3 sekundy przy szybkim 3G i do 10 sekund przy wolnym
Te same 8 tagów, wstawione na sztywno bezpośrednio w kod strony, spowalniają jeszcze bardziej
Im później uruchamiają się tagi, tym mniejszy wpływ: opóźnienie o 1,5 sekundy po Window Loaded skraca czas ładowania o 6 sekund na wolnym 3G
Przemyślane skonfigurowanie reguł i wyczyszczenie kontenera ze śmieci przywracają szybkość bez utraty danych

Jak testowaliśmy

Metodyka prosta, ale drobiazgowa. Każdy test przeprowadzaliśmy co najmniej trzy razy i liczyliśmy średnią.

Narzędzia: webpagetest.org (serwer w Irlandii, EC2, Chrome i Firefox dla desktopa, OnePlus 5 do testów mobilnych) i wbudowany audyt Lighthouse w Chrome DevTools. W Lighthouse sprawdzaliśmy zarówno raporty mobilne, jak i desktopowe. Chrome uruchamialiśmy w trybie incognito, bez żadnych rozszerzeń, wydajność laptopa na maksimum.

Metryki, które mierzyliśmy:

W webpagetest.org: Document complete (sekundy do załadowania statycznej treści, obrazów, stylów) i Fully loaded (punkt po onLoad, gdy aktywność sieciowa cichnie na 2 sekundy). W Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle i Max Potential First Input Delay (FID).

Kody śledzące w testach: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Osiem powszechnie używanych skryptów.

Jakie scenariusze porównaliśmy:

Czysta strona bez zewnętrznych skryptów i bez GTM
Strona z 8 kodami śledzącymi, wstawionymi na sztywno przed </head>, bez GTM
Pusty kontener GTM bez tagów
Wszystkie 8 tagów przez GTM, reguła All Pages (czyli gtm.js)
Te same 8 tagów przez GTM, reguła DOM Ready (gtm.dom)
Te same 8 tagów przez GTM, reguła Window Loaded (gtm.load)
Te same 8 tagów, uruchomienie 1,5 sekundy po Window Loaded
Kontener GTM z włączonym trybem podglądu i debugowania
Kontener GTM ze 100 niestandardowymi tagami HTML, które dodają elementy na koniec <body>
Kontener GTM ze 100 niestandardowymi tagami HTML, które dodają elementy w konkretne miejsce strony (po H2)
Kontener GTM ze 100 niestandardowymi tagami HTML, które wyszukują wszystkie linki i wstawiają element po 21.
Kontener GTM z 1976 stałymi zmiennymi (wypełniony po brzegi, 200 KB)

Co pokazały testy

Asynchroniczny nie oznacza „bez konsekwencji"

Skrypty asynchroniczne nie blokują renderowania bezpośrednio. Ale wciąż potrzebują zasobów procesora, a to oznacza, że główne skrypty strony wykonują się wolniej. W praktyce: zdarzenie Document Complete na czystej stronie następowało po 4 sekundach. Z ośmioma tagami, po 7,7 sekundy. Różnica 3,7 sekundy tylko z tego powodu, że procesor jest zajęty zewnętrznymi skryptami.

Porównanie czasu Document Complete bez tagów i z tagami

Nawet pusty kontener GTM nieznacznie zwiększał czas ładowania, o około 100 milisekund.

Wpływ pustego kontenera GTM na czas ładowania

Problem nie leży w GTM, lecz w tym, co do niego wkładacie

Pusty kontener GTM dodaje do ładowania około 100 milisekund, czasem opóźnienia nie ma wcale. Problemy zaczynają się, gdy wypełniacie kontener tagami. Ale i tutaj nie wszystko jest liniowe.

Osiem tagów śledzących spowolniło stronę o około 3 sekundy przy szybkim połączeniu 3G i o 10 sekund przy wolnym. Każdy tag pobiera swój skrypt, a przeglądarka poświęca czas na ich wykonanie.

Document Complete bez tagów i z 8 tagami w GTM

Natomiast kontener wypełniony 1976 stałymi zmiennymi (200 KB, limit GTM) dodał zaledwie 0,1-0,3 sekundy. Zmienne nie ładują zewnętrznych skryptów i nie manipulują DOM, więc ich wpływ jest minimalny.

Wniosek: ważny jest nie rozmiar kontenera, ale to, jakie działania wykonują jego elementy.

Tagi wstawione na sztywno spowalniają bardziej niż te same tagi przez GTM

Gdy dodaliśmy 8 skryptów śledzących bezpośrednio w kod strony, strona spowolniła jeszcze wyraźniej. Na szybkim 3G tagi wstawione na sztywno dodały około 600 milisekund więcej opóźnienia w porównaniu z tymi samymi tagami uruchomionymi przez GTM.

Porównanie tagów wbudowanych na sztywno i tagów przez GTM

Na drugim wykresie ten sam obraz w innym ujęciu: skrypty wstawione na sztywno stale przegrywają z GTM pod względem czasu Document Complete.

Document Complete tagi wbudowane na sztywno vs GTM

GTM rzeczywiście pomaga ładować się nieco szybciej niż przy bezpośrednim dodawaniu skryptów w kodzie. Ale nie jest to uniwersalna zasada. Istnieją scenariusze, w których uruchamianie JS bez GTM można zrealizować efektywniej, z czym zgadza się również Simo Ahava, jeden z czołowych ekspertów od GTM.

Moment uruchomienia tagu decyduje o wszystkim

Im później uruchamia się tag, tym mniejszy ma wpływ na początkowe ładowanie. Przetestowaliśmy cztery momenty:

Page View (gtm.js), natychmiast przy załadowaniu kontenera
DOM Ready (gtm.dom), gdy DOM jest zbudowany
Window Loaded (gtm.load), gdy wszystkie zasoby są załadowane
afterLoad, 1,5 sekundy po Window Loaded (reguła niestandardowa)

Kod niestandardowej reguły afterLoad:

1 <script>
2   (function() {
3     try {
4       window.setTimeout(function(){
5         dataLayer.push({
6           'event': 'afterLoad'
7         });
8       }, 1500);
9     } catch (err) {}
10   })();
11 </script>

Wynik: DOM Ready i Window Loaded dały niewielką poprawę. Jednak największy zysk przyniósł właśnie afterLoad. Na wolnym 3G opóźnienie skróciło się o 6 sekund w porównaniu z wyzwalaczem Page View. Na szybkim 3G o 600 milisekund.

Porównanie Fully Loaded dla różnych momentów wyzwalania tagów

Dlaczego to działa? Na stronie mogą znajdować się elementy ładowane dynamicznie dopiero po pełnym załadowaniu zasobów. Jeśli tagi spowalniają początkowe ładowanie, te elementy również pojawiają się później. Odkładając niekrytyczne tagi, pozwalają Państwo załadować się głównej treści bez przeszkód.

Jest jednak pewien niuans: jeśli odkładają Państwo tagi, od których zależy dokładność danych (Google Analytics), część odwiedzających może opuścić stronę, zanim licznik zdąży zadziałać. Raporty stracą część danych. Decyzja o opóźnieniu tagów powinna być podejmowana wspólnie z zespołem, a nie jednoosobowo przez developera czy marketera.

Tagi śledzące to nie jedyni winowajcy

Inną grupą „ciężkich" tagów są te, które manipulują DOM. Na przykład niestandardowe tagi HTML, które dodają lub zmieniają elementy na stronie.

Przetestowaliśmy kilka wariantów:

100 niestandardowych tagów HTML dodających elementy na koniec <body>. Każdy tag wykonywał prosty skrypt console.log('hello') i tworzył <div>Hello!</div>. Bez wskazywania konkretnego miejsca wstawienia. Wpływ na szybkość ładowania okazał się minimalny, elementy były po prostu dopisywane na końcu.

100 niestandardowych tagów HTML dodających elementy w konkretnym miejscu strony. Każdy tag wyszukiwał pierwszy h2 i wstawiał po nim h3. Skrypt:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var title = document.querySelector('h2');
6     if (title) {
7       title.parentElement.insertBefore(h3, title.nextSibling);
8     }
9   })();
10 </script>

To dodało kilkaset milisekund do ładowania. Mimo że skrypt jest prymitywny, wyszukiwanie elementu i wstawianie wymagają zasobów.

Wpływ 100 tagów z manipulacjami DOM na Fully Loaded

100 niestandardowych tagów HTML, które wyszukują wszystkie linki na stronie i wstawiają element po 21. z nich. Skrypt:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var element = document.querySelectorAll('a')[20];
6     if (element) {
7       element.parentElement.insertBefore(h3, element.nextSibling);
8     }
9   })();
10 </script>

Różnica w porównaniu z poprzednim eksperymentem: querySelectorAll przegląda wszystkie elementy na stronie, sprawdza każdy z nich, jest to bardziej kosztowne. W webpagetest.org różnica była niewielka (100-200 ms), ale Lighthouse pokazał wzrost wskaźnika Time to Interactive o 2-3 sekundy. Oznacza to, że podczas ładowania strony przeglądarka jest tak zajęta wstawianiem elementów, że nie reaguje na działania użytkownika.

Time to Interactive przy ciężkich manipulacjach DOM

Tak, 100 identycznych skryptów to przesada. Chodzi jednak o to, że nawet kilka złożonych tagów manipulujących DOM może dać podobny efekt.

Jak zmniejszyć wpływ GTM na szybkość: 8 technik

Regularnie czyść kontener z porzuconych tagów

Praktyka audytów pokazuje: nawet jedna trzecia kodów śledzących na stronach należy do narzędzi, z których firma już nie korzysta. Przeszli Państwo z narzędzia analitycznego X na Z, a kody X wciąż ładują się na każdej stronie i spowalniają ją.

Co robić:

Proszę poprosić developera o listę wszystkich żądań HTTP i skryptów na stronie
Proszę wygooglować domeny tych żądań, ustalić, do jakich narzędzi należą
Proszę zapytać kolegów z różnych działów, które narzędzia są jeszcze używane
Proszę znaleźć „osierocone" skrypty, których nie ma na liście używanych
Jeśli skrypt jest zaimplementowany przez GTM, proszę go wstrzymać na miesiąc; jeśli nikt nie zgłasza problemów, proszę go całkowicie usunąć
Jeśli skrypt jest wszyty w kod, proszę poprosić developera o tymczasowe zakomentowanie go, a po miesiącu o usunięcie

Kontener GTM przed audytem porzuconych tagów

Odkładaj niekrytyczne tagi

Im mniej tagów na wyzwalaczu All Pages, tym szybsze początkowe ładowanie. Nie wszystkie tagi można odłożyć, ale jeśli zastosują Państwo to podejście choćby do części z nich, poprawa będzie zauważalna.

Jak zaimplementować opóźnienie (sposób Pavla Brechika):

Krok 1. Proszę utworzyć niestandardowy tag HTML z kodem:

1 <script>
2   (function() {
3    try {
4      window.setTimeout(
5       function(){
6        dataLayer.push({'event': 'afterLoad'});
7       }, 1500);
8     } catch (err) {}
9   })();
10 </script>

Krok 2. Proszę uruchomić ten tag na wyzwalaczu Window Loaded.

Konfiguracja wyzwalacza Window Loaded dla niestandardowego tagu HTML

Krok 3. Proszę utworzyć niestandardowy wyzwalacz dla zdarzenia afterLoad.

Tworzenie niestandardowego wyzwalacza afterLoad w GTM

Krok 4. Proszę przypisać ten wyzwalacz tagom, które można odłożyć.

Rezultat na wolnym 3G: opóźnienie skróciło się o 6 sekund, na szybkim 3G o 600 milisekund.

Fully Loaded przy różnych momentach wyzwalania tagów

Które tagi można odłożyć, a które nie, proszę decydować z zespołem. Developerzy idealnie usunęliby wszystko dla szybkości, marketerzy dodaliby wszystko dla dokładności danych. Prawda leży pośrodku.

Używaj tagów tylko na potrzebnych stronach

Nie każdy tag musi uruchamiać się na całej witrynie. Pixel remarketingowy Google Ads może uruchamiać się tylko na stronach docelowych kampanii, a nie na całej witrynie. LinkedIn Insights tylko na stronach, na które kierowany jest ruch z LinkedIn. Proszę skonfigurować wyjątki w wyzwalaczach, to zmniejszy liczbę wykonywanych skryptów na typowej stronie.

Konfiguracja wyzwalacza tylko dla określonych stron w GTM

Unikaj ciężkich manipulacji DOM

Jeśli potrzebują Państwo niestandardowego tagu HTML, który coś dodaje na stronę, proszę starać się robić to możliwie jak najlżej. Proszę unikać querySelectorAll z przeglądaniem wszystkich elementów. Proszę nie wstawiać dziesiątek podobnych elementów w różne miejsca strony. Każda manipulacja DOM zużywa zasoby przeglądarki w momencie, gdy jest ona i tak zajęta renderowaniem strony.

Przykład zoptymalizowanego niestandardowego tagu HTML w GTM

Nie mierz szybkości z włączonym trybem podglądu

Tryb Preview and Debug w GTM dodaje dodatkowe obciążenie przeglądarki, którego nie ma u rzeczywistych odwiedzających. Jeśli mierzą Państwo szybkość z włączonym podglądem, wyniki będą celowo gorsze od rzeczywistych. Przed audytem szybkości zawsze proszę wyłączać tryb debugowania.

Wyłączenie trybu podglądu GTM na potrzeby testów prędkości

Testuj szybkość po każdej zmianie kontenera

Wprowadzili Państwo nowy tag lub zmienili wyzwalacz, proszę natychmiast sprawdzić szybkość strony przez webpagetest.org lub Lighthouse. Proszę zrobić pomiar przed i po. To pozwoli wychwycić problematyczny tag od razu, a nie zgadywać później, dlaczego strona zaczęła się ładować o 2 sekundy dłużej.

Utrzymuj kontener w szczupłej formie

Proszę usuwać nieużywane tagi, wyzwalacze i zmienne. Chodzi tu nie tyle o szybkość (jak pokazał test z 1976 zmiennymi), ile o łatwość zarządzania. W kontenerze z setką tagów łatwo zgubić problematyczny skrypt. W kontenerze z dwoma tuzinami każda jednostka jest na widoku.

Oddzielaj ziarno od plew: co realnie oszczędza czas ładowania

Podsumujmy eksperymenty. Oto co daje maksymalny efekt w kolejności malejącej:

Zbiorcza tabela wpływu różnych czynników na prędkość ładowania

Zgodnie z wynikami naszych pomiarów, największą poprawę daje opóźnienie tagów przez afterLoad, do 6 sekund na wolnym połączeniu. Na drugim miejscu, usunięcie porzuconych kodów śledzących. Na trzecim, ograniczenie zakresu działania tagów do konkretnych stron.

⁉️🤔 Często zadawane pytania

Czy pusty GTM spowalnia stronę?

Praktycznie nie. W naszych testach pusty kontener dodawał około 100 milisekund do ładowania. Czasami opóźnienia nie było wcale. To błąd pomiaru, niezauważalny ani dla użytkownika, ani dla wyszukiwarek.

Co bardziej spowalnia: GTM czy skrypty wszyte na stałe?

Skrypty wszyte na stałe spowalniają nieco bardziej. W naszym teście 8 tagów śledzących dodanych bezpośrednio w kod spowolniło stronę o około 600 milisekund bardziej niż te same tagi przez GTM. Ale nie jest to uniwersalna reguła: dobrze napisany niestandardowy JS może być wydajniejszy niż GTM.

Czy można odłożyć absolutnie wszystkie tagi?

Technicznie tak. Ale stracą Państwo dane: część odwiedzających opuści stronę przed uruchomieniem się liczników. Google Analytics i podobne narzędzia nie doliczą się ruchu. Proszę odkładać tylko te tagi, które nie wymagają wysokiej dokładności, na przykład widżety czatów lub piksele remarketingowe. Analitykę lepiej zostawić na Page View.

Jak sprawdzić, które tagi w GTM realnie spowalniają?

Proszę uruchomić audyt Lighthouse z otwartą zakładką Network. Proszę sprawdzić, które skrypty ładują się najdłużej i które blokują renderowanie. Proszę zestawić domeny tych skryptów z tagami w kontenerze. Albo proszę przeprowadzić test A/B: tymczasowo wyłączać podejrzane tagi pojedynczo i mierzyć szybkość.

A co z server-side GTM?

Server-side GTM przenosi przetwarzanie tagów z przeglądarki użytkownika na Państwa serwer. Przeglądarka otrzymuje tylko jeden kontener zamiast tuzina zewnętrznych skryptów. To radykalnie zmniejsza obciążenie po stronie klienta. Jeśli mają Państwo dziesiątki tagów śledzących, warto rozważyć server-side GTM. Technologia jest dostępna od 2020 roku, a do 2026 roku jej wdrożenie stało się zauważalnie prostsze.

Co w rezultacie: GTM przyspiesza czy spowalnia?

Ani jedno, ani drugie w czystej postaci. GTM to dyspozytor: sam w sobie jest prawie nieważki, a szybkość strony zależy od tego, jakie tagi i w jakiej ilości Pan przez niego uruchamia.

Osiem standardowych tagów śledzących przez GTM dodaje 3-10 sekund do ładowania. Ale te same tagi, wszyte bezpośrednio, spowalniają jeszcze bardziej. Opóźnione uruchomienie przez afterLoad odzyskuje do 6 sekund. Usunięcie porzuconych tagów, kolejne kilka sekund. A zatem, przy rozsądnej konfiguracji GTM może dać fory sztywno wszytym skryptom, a bez konfiguracji, przegrać z pustą stroną na całego.

Główna zasada jest prosta: to nie GTM upiększa stronę, tylko Pan sam. Proszę przeprowadzić audyt kontenera, usunąć śmieci, odłożyć niekrytyczne tagi, skonfigurować wyjątki według stron, a szybkość Pana strony Panu podziękuje.

1	<script>
2	(function() {
3	try {
4	window.setTimeout(function(){
5	dataLayer.push({
6	'event': 'afterLoad'
7	});
8	}, 1500);
9	} catch (err) {}
10	})();
11	</script>

1	<script>
2	(function() {
3	var h3 = document.createElement('h3');
4	h3.innerText = "An additional element";
5	var title = document.querySelector('h2');
6	if (title) {
7	title.parentElement.insertBefore(h3, title.nextSibling);
8	}
9	})();
10	</script>

Wszystko o WordPressie, tworzeniu stron — i nie tylko

🚀 Google Tag Manager i szybkość strony: co mówią testy