Google Tag Manager a szybkość strony: porządek w tagach i regułach uruchamiania

Dlaczego kontener z tagami spowalnia stronę

Kontener spowalnia stronę, ponieważ wszystko, co do niego trafia, przeglądarka musi pobrać, przeanalizować i wykonać, a robi to na tym samym wątku, który obsługuje kliknięcia i rysowanie ekranu. Menedżer tagów Google (Google Tag Manager, w skrócie GTM) pozwala dodawać do strony kody pomiarowe i reklamowe bez zmian w szablonie. Wygoda ma swoją cenę: tagów przybywa łatwo, a ubywa rzadko.

Według opracowania o dobrych praktykach dla tagów i menedżerów tagów w serwisie web.dev menedżer tagów wpływa na szybkość pośrednio: zajmuje łącze w czasie wczytywania strony i zużywa czas procesora na głównym wątku. Autorzy podkreślają, że pojedynczy tag bywa niemal niezauważalny, natomiast kilkadziesiąt lub kilkaset tagów na jednej podstronie to już wyraźne obciążenie.

To samo źródło podaje kilka liczb. Menedżer tagów Google ogranicza rozmiar kontenera do 300 KB i ostrzega po przekroczeniu 70 procent tego limitu. Mediana rozmiaru kontenera wynosi około 50 KB, a sama biblioteka menedżera po kompresji około 33 KB. Rozmiar nie jest przy tym najważniejszą miarą: duży kontener bywa raczej sygnałem, że nikt go od dawna nie porządkował.

Główny wątek i długie zadania

Główny wątek to miejsce, w którym przeglądarka wykonuje niemal cały kod JavaScript strony. Może zajmować się tylko jednym zadaniem naraz. Jak wyjaśnia opracowanie web.dev o długich zadaniach, każde zadanie trwające dłużej niż 50 milisekund jest uznawane za długie, a dopóki ono trwa, przeglądarka nie odpowie na działanie użytkownika. Kliknięcie w przycisk menu czeka wtedy w kolejce, aż skrypt reklamowy lub analityczny skończy pracę.

Dobrze pokazuje to hipotetyczny przykład. Sklep z Poznania ma w kontenerze tag analityczny, trzy piksele sieci reklamowych, narzędzie do nagrywania sesji, okno czatu, ankietę i kilka własnych fragmentów kodu po dawnych kampaniach. Każdy z tych elementów osobno wydaje się niegroźny. Razem uruchamiają się w pierwszych sekundach wizyty, czyli wtedy, gdy klient próbuje otworzyć menu kategorii albo dodać produkt do koszyka.

O skryptach dostawców jako takich pisaliśmy we wpisie o skryptach zewnętrznych i ich wpływie na szybkość. Tutaj zajmujemy się samym menedżerem: tym, co dzieje się w kontenerze i jak go ustawić.

Jak tagi wpływają na INP, LCP i CLS

Tagi najmocniej szkodzą wskaźnikowi INP, ponieważ zajmują główny wątek w chwili, gdy użytkownik próbuje coś kliknąć, ale mogą też opóźnić wyświetlenie największego elementu i wywołać przeskoki układu. Opracowanie web.dev o tagach wskazuje na związek między rozmiarem menedżera tagów a gorszymi wynikami INP.

Zgodnie z opisem wskaźnika INP w serwisie web.dev dobry wynik to 200 milisekund lub mniej, a wynik powyżej 500 milisekund jest słaby. Ocenia się 75. percentyl wizyt, osobno dla telefonów i komputerów. Na czas interakcji składają się trzy części: opóźnienie wejścia, czas przetwarzania i opóźnienie prezentacji. Tagi najczęściej wydłużają pierwszą z nich, bo kliknięcie trafia na moment, w którym wątek jest zajęty długim zadaniem. Szerzej piszemy o tym we wpisie o tym, dlaczego strona reaguje z opóźnieniem na kliknięcie.

Z tego samego źródła wynika ważna zasada: menedżer tagów nie jest dobrym miejscem na ładowanie rzeczy, od których zależy pierwsze wrażenie, takich jak powiadomienie o plikach cookie, główna grafika czy funkcje samej witryny. Zasoby dodawane przez menedżer pojawiają się później niż te zapisane w kodzie strony, co wydłuża LCP i sprzyja przeskokom układu. Część użytkowników blokuje ponadto menedżery tagów, więc funkcja zależna od kontenera może u nich nie zadziałać. Całość tematu wskaźników omawiamy we wpisie o poprawie Core Web Vitals na stronie firmy.

Przegląd kontenera: które tagi zostawić, a które usunąć

Przegląd kontenera polega na przejściu przez listę tagów, reguł i zmiennych i ustaleniu przy każdej pozycji trzech rzeczy: do czego służy, kto z niej korzysta i czy dane nadal do kogoś trafiają. Wszystko, na co nie ma odpowiedzi, jest kandydatem do wstrzymania, a po okresie obserwacji do usunięcia.

W panelu menedżera lista znajduje się w obszarze roboczym, w częściach Tagi, Reguły i Zmienne. Z naszej praktyki wynika, że przegląd najwygodniej zacząć od tagów z regułą obejmującą wszystkie strony, bo to one działają przy każdej wizycie.

Co zwykle znajduje się w zaniedbanym kontenerze

Najczęściej są to tagi po zakończonych kampaniach, piksele platform, na których firma dawno nie prowadzi reklam, kody narzędzi testowanych przez miesiąc i porzuconych oraz tagi zdublowane. Web.dev zwraca uwagę na ten ostatni przypadek: ten sam kod bywa jednocześnie wpisany w szablon strony i dodany przez menedżer tagów. Hipotetyczna kancelaria z Krakowa, która współpracowała kolejno z trzema wykonawcami kampanii, może mieć trzy tagi konwersji dla tego samego formularza. Żaden nie wywołuje widocznego błędu, więc nikt ich nie rusza, a strona wykonuje je przy każdej wizycie.

Wstrzymanie tagu a wyjątek w regule

Nieużywany tag należy wstrzymać albo usunąć, a nie blokować wyjątkiem w regule. Różnicę opisuje web.dev: tag zablokowany wyjątkiem nadal jest częścią kontenera i jego kod trafia do przeglądarki, natomiast tag wstrzymany lub usunięty z kontenera wypada. Wstrzymane tagi wciąż w pewnym stopniu wliczają się do rozmiaru kontenera, choć łączna waga jest mniejsza niż przy tagach aktywnych. Wstrzymanie warto więc traktować jako stan przejściowy przed usunięciem.

Po usunięciu tagów trzeba przejrzeć reguły i zmienne, które po nich zostały. Zmienne są obliczane na bieżąco, a zmienne z własnym kodem JavaScript mogą mieć dowolny rozmiar. Każda reguła dodaje do kontenera własny fragment kodu, a kilka reguł kliknięcia lub liczników czasu potrafi wyraźnie zwiększyć ilość pracy.

Reguły uruchamiania: kiedy tag ma prawo zadziałać

Reguła decyduje o tym, w którym momencie i na których podstronach tag się uruchomi, a więc także o tym, czy jego praca zbiegnie się z pierwszymi kliknięciami użytkownika. Im wcześniej tag startuje, tym większy ma wpływ na wczytywanie, zwłaszcza gdy jest duży albo długo się wykonuje.

Pomoc Menedżera tagów na stronie Typy reguł wymienia w grupie reguł wyświetlenia strony pięć pozycji: Inicjacja zgody, Zdarzenie inicjujące, Wyświetlenie strony, Element DOM dostępny oraz Wczytanie okna. Poza tą grupą są między innymi reguły kliknięcia, widoczności elementu, przesyłania formularza, głębokości przewijania, licznika czasu i zdarzenia niestandardowe.

Tagi, które mogą poczekać

Web.dev zaleca, aby tagi, które nie są niezbędne, uruchamiać po zdarzeniu wczytania okna. Jeżeli jest to zbyt późno, pozostaje zdarzenie niestandardowe: między chwilą, w której struktura strony jest gotowa, a pełnym wczytaniem okna mija czasem sporo czasu. Strona wysyła wtedy do warstwy danych własne zdarzenie, a reguła typu Zdarzenie niestandardowe uruchamia tag.

window.dataLayer = window.dataLayer || [];
setTimeout(function () {
  window.dataLayer.push({ event: 'tagi_dodatkowe' });
}, 1500);

Drugim sposobem jest powiązanie tagu z działaniem użytkownika. Okno czatu hipotetycznego hydraulika z Łodzi nie musi ładować się każdemu odwiedzającemu w pierwszej sekundzie. Właściwy skrypt może wystartować dopiero po kliknięciu w lekką ikonę albo po przewinięciu strony do określonej głębokości. To decyzja nie tylko techniczna: opóźniony tag nie zarejestruje wizyt, które zakończyły się przed jego uruchomieniem.

Tag tylko tam, gdzie jest potrzebny

Tag konwersji potrzebny na stronie podziękowania nie musi działać w całym serwisie. Web.dev zaleca ograniczanie tagów do podstron, na których są wykorzystywane, i ostrzega przed drugą skrajnością: rozbudowane warunki i wyjątki same wydłużają czas przetwarzania. Najlepiej sprawdzają się proste warunki oparte na ścieżce adresu.

Jest jeszcze poziom wyżej. Menedżer nie uruchomi żadnej reguły, dopóki sam się nie wczyta, dlatego moment załadowania kontenera wpływa na wszystkie tagi jednocześnie. Autorzy web.dev oceniają, że późniejsze wczytanie menedżera może dać efekt równy dopracowaniu poszczególnych tagów albo większy. Taką zmianę trzeba uzgodnić z osobami odpowiedzialnymi za pomiar, bo przesuwa w czasie całą analitykę.

Zgoda użytkownika a uruchamianie tagów

Powiązanie tagów ze zgodą użytkownika porządkuje kontener z dwóch powodów: tagi reklamowe i analityczne nie wykonują się u osób, które zgody nie udzieliły, a cała logika zostaje w jednym miejscu zamiast w dziesiątkach wyjątków w regułach. Menedżer tagów ma do tego wbudowane ustawienia, opisane na stronie pomocy Obsługa trybu uzyskiwania zgody w Menedżerze tagów.

Każdy tag internetowy ma własne ustawienia zgody. Znajdują się w edycji tagu, w części Ustawienia zaawansowane, pod nazwą Ustawienia dotyczące wyrażania zgody. W sekcji dodatkowej zgody są trzy możliwości: Nie ustawiono, Brak wymogu uzyskania dodatkowej zgody oraz Wymagaj dodatkowej zgody na uruchomienie tagu. Przy trzeciej tag uruchomi się tylko wtedy, gdy wszystkie wskazane rodzaje zgody mają stan przyznany. Pomoc wymienia wśród nich ad_storage (przechowywanie danych związanych z reklamami), ad_user_data, ad_personalization i analytics_storage (przechowywanie danych statystycznych).

Przegląd ustawień zgody dla całego kontenera

Aby nie otwierać tagów pojedynczo, można włączyć widok zbiorczy. W panelu należy przejść do części Administracja, wybrać Ustawienia kontenerów i w sekcji Ustawienia dodatkowe zaznaczyć opcję włączającą przegląd ustawień uzyskiwania zgody. Opcja Brak wymogu uzyskania dodatkowej zgody służy według pomocy do odróżnienia tagów już sprawdzonych od niesprawdzonych.

Reguła Inicjacja zgody uruchamia się przed wszystkimi innymi, także przed regułą Zdarzenie inicjujące, i jest przeznaczona dla tagów, które ustawiają lub aktualizują stan zgody. Wstawianie do niej tagów pomiarowych jest błędem zarówno ze względu na zgodę, jak i na szybkość.

To, które tagi wymagają zgody i jakiej, jest kwestią prawną, a nie wyłącznie techniczną. Ustawienia w kontenerze powinny wynikać z ustaleń z prawnikiem lub osobą odpowiedzialną w firmie za ochronę danych.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Własny kod HTML w tagach: największe ryzyko w kontenerze

Tag z własnym kodem HTML (Custom HTML) pozwala wstawić do strony dowolny skrypt niemal bez ograniczeń i dlatego jest najbardziej ryzykownym rodzajem tagu. Web.dev ustawia rodzaje tagów w kolejności od najlżejszych: tagi graficzne nazywane pikselami, następnie szablony niestandardowe, a na końcu własny kod HTML. Autorzy zastrzegają, że o wpływie decyduje sposób użycia tagu, a nie sam typ.

Piksel to mały obrazek, zwykle poniżej 1 KB, który po wysłaniu nie uruchamia kodu JavaScript i nie powoduje przeskoków układu. Szablony niestandardowe działają w ograniczonym środowisku JavaScript. Osoba techniczna może przygotować szablon z myślą o wydajności, a dział marketingu używa go potem bez dostępu do surowego kodu. Web.dev wskazuje szablon jako zalecany sposób wstawiania skryptów.

Typowe błędy we własnym kodzie

Pierwszym błędem jest wklejanie do tagu całej biblioteki zamiast odwołania do pliku. Kod wpisany w tag powiększa kontener i nie może być osobno zapisany w pamięci podręcznej przeglądarki. Większe skrypty należy wczytywać przez znacznik script z adresem pliku.

Drugim jest wstawianie widocznych elementów. Pasek promocji czy okno zapisu na newsletter, dodane z kontenera po wyświetleniu strony, przesuwają treść i pogarszają CLS. Wstawianie elementów może też wymuszać wielokrotne przeliczanie układu, co według web.dev jest szczególnie odczuwalne na słabszych urządzeniach. Elementy widoczne powinny być częścią szablonu strony.

Trzeci błąd dotyczy diagnozy. Większość narzędzi przypisuje pracę własnego kodu HTML menedżerowi tagów, a nie konkretnemu tagowi. W raporcie widać więc, że kontener jest ciężki, ale nie widać, który fragment za to odpowiada. Przy każdym tagu z własnym kodem warto zadać pytanie, czy tego samego nie załatwi gotowy typ tagu, szablon albo piksel.

Tagowanie po stronie serwera: co przenosi i czego nie rozwiązuje

Tagowanie po stronie serwera przenosi część pracy z przeglądarki użytkownika na serwer kontrolowany przez firmę, dzięki czemu strona wysyła mniej żądań i wykonuje mniej cudzego kodu. Nie usuwa jednak skryptów z przeglądarki całkowicie i nie zastąpi porządku w kontenerze.

Jak wyjaśnia wprowadzenie do tagowania po stronie serwera w dokumentacji Google, kontener serwerowy działa na serwerze, nad którym firma ma kontrolę, a tagi, reguły i zmienne zachowują się w nim tak jak w kontenerze internetowym. Nowym elementem są klienty: odbierają przychodzące żądania, zamieniają je na zdarzenia i przekazują do kontenera, a tagi wysyłają dane dalej.

W przykładzie z dokumentacji w przeglądarce nadal działa skrypt tagu Google, który wysyła zdarzenia pod adres kontenera serwerowego. Zysk dla szybkości opisuje web.dev: zamiast osobnych żądań do każdego dostawcy przeglądarka wysyła jedno, a kod dostawców znika ze strony. Zgodność z tym modelem zależy od dostawcy. Web.dev poleca to rozwiązanie szczególnie większym serwisom, którym zależy na kontroli nad danymi.

Z naszej praktyki wynika, że kontener serwerowy to dodatkowy element do utrzymania, a narzędzia działające na ekranie użytkownika, takie jak okna czatu czy nagrania sesji, i tak pozostają w przeglądarce. Dla małej strony usługowej z kilkoma tagami zwykłe porządki dają zazwyczaj więcej niż zmiana architektury. Przy rozbudowanym pomiarze kampanii, o którym piszemy we wpisie o śledzeniu konwersji w Google Ads, rozmowa o serwerze ma więcej sensu.

Pomiar wpływu kontenera w narzędziach Chrome

Wpływ kontenera najprościej zmierzyć, nagrywając wczytanie strony dwa razy w panelu Wydajność w Narzędziach deweloperskich Chrome: raz normalnie, a raz z zablokowanymi żądaniami do menedżera tagów. Różnica między nagraniami pokazuje, ile pracy głównego wątku przypada na tagi.

Nagranie w panelu Wydajność

Funkcje panelu opisuje dokumentacja Chrome na stronie Informacje o funkcjach wydajności. Nagranie wczytywania uruchamia przycisk rejestrowania połączonego z ponownym załadowaniem strony. W ustawieniach przechwytywania można spowolnić procesor, co przybliża warunki do telefonu, choć dokumentacja zastrzega, że narzędzia nie odwzorowują procesorów mobilnych w pełni.

Po nagraniu warto obejrzeć trzy miejsca. Ścieżka głównego wątku pokazuje długie zadania z czerwonym trójkątem, a ich część powyżej 50 milisekund jest zacieniowana na czerwono. Ścieżka Interakcje pokazuje każde kliknięcie z podziałem na opóźnienie wejścia, czas przetwarzania i opóźnienie prezentacji, a interakcje dłuższe niż 200 milisekund są oznaczone czerwonym trójkątem. Tabela podmiotów w części Podsumowanie zestawia rozmiar pobranych danych i czas głównego wątku z podziałem na podmiot własny i podmioty zewnętrzne. Pozycja menedżera tagów oraz pozycje dostawców, których skrypty on wczytuje, pokazują skalę problemu. Praca tagów z własnym kodem HTML bywa przy tym przypisana samemu menedżerowi.

Porównanie z zablokowanym menedżerem

Dokumentacja Chrome na stronie o warunkach żądania opisuje, jak zablokować wybrane żądania sieciowe. W panelu Sieć wystarczy kliknąć prawym przyciskiem myszy żądanie w kolumnie Nazwa i wybrać pozycję blokującą to żądanie. Otworzy się panel Warunki żądania, w którym można też ręcznie dodać wzorzec adresu z gwiazdką zastępującą dowolny fragment. Zablokowane żądania mają w kolumnie Stan wpis blocked:devtools. Po zamknięciu narzędzi blokowanie się wyłącza.

1. Nagranie wyjściowe

   Ze spowolnionym procesorem należy nagrać wczytanie wybranej podstrony i wykonać kilka typowych kliknięć: otwarcie menu, rozwinięcie filtra, dodanie produktu do koszyka.

2. Blokada menedżera tagów

   W panelu Sieć trzeba odszukać żądanie pliku kontenera z domeny googletagmanager.com i zablokować je. Wraz z nim nie wczytają się tagi uruchamiane przez kontener.

3. Drugie nagranie

   Te same czynności w tych samych ustawieniach. Porównuje się liczbę długich zadań, czas głównego wątku w tabeli podmiotów oraz czasy na ścieżce Interakcje.

4. Szukanie winnego

   Jeśli różnica jest duża, w wersji roboczej kontenera wstrzymuje się kolejne grupy tagów i powtarza pomiar, aż widać, które z nich odpowiadają za największą część obciążenia.

Nagranie z jednego komputera to pomiar laboratoryjny. O tym, czy porządki pomogły rzeczywistym odwiedzającym, mówią dopiero dane od użytkowników. Różnicę wyjaśniamy we wpisie o pomiarze szybkości strony i danych od użytkowników.

Jak utrzymać porządek w kontenerze na stałe

Porządek utrzymuje się wtedy, gdy zmiany w kontenerze podlegają takiej samej kontroli jak zmiany w kodzie strony: ktoś je sprawdza, testuje i zapisuje, po co zostały wprowadzone. Web.dev opisuje typowy podział: skrypty w kodzie strony przechodzą przez programistów, a tagi dodaje dział marketingu przez menedżer, zwykle bez przeglądu.

Strona pomocy Publikowanie, wersje i zatwierdzenia wyjaśnia, że wersja jest migawką konfiguracji kontenera, którą można przywrócić, a historię publikacji widać na karcie Wersje. Uprawnienia mają poziomy Edycja, Zatwierdzanie i Publikacja, więc prawo do publikowania można zostawić jednej, dwóm osobom. Formalny obieg zatwierdzeń jest według pomocy dostępny tylko w Menedżerze tagów 360.

Przed publikacją każdy nowy tag warto sprawdzić w trybie opisanym na stronie pomocy Podgląd i debugowanie kontenerów. Podgląd uruchamia się w obszarze roboczym przyciskiem w prawym górnym rogu, po czym w osobnej karcie otwiera się Tag Assistant i prosi o adres witryny. Widać w nim, czy tag się uruchomił i które reguły o tym zdecydowały.

• Każdy tag ma w nazwie lub notatce cel i osobę odpowiedzialną.
• Na jednej stronie działa jeden kontener, a ten sam kod nie jest wpisany dodatkowo w szablon.
• Tagi po zakończonych kampaniach są wstrzymywane od razu i usuwane przy najbliższym przeglądzie.
• Nowy tag z własnym kodem HTML wymaga zgody osoby technicznej.
• Tagi, które mogą poczekać, mają regułę wczytania okna, zdarzenia niestandardowego albo działania użytkownika.
• Każdy tag ma sprawdzone ustawienia zgody.
• Publikować mogą tylko wyznaczone osoby, a wersje mają opisowe nazwy.

Zalecenie jednego kontenera pochodzi z web.dev: kilka kontenerów na stronie oznacza dodatkowy narzut, ponieważ podstawowy kod menedżera nie jest między nimi współdzielony.

Porządki wymagają współpracy osób od reklamy, analityki i strony, bo usunięcie tagu bez uzgodnienia potrafi przerwać pomiar konwersji. Pomoc z zewnątrz przydaje się zwłaszcza wtedy, gdy nikt w firmie nie wie, skąd wzięła się większość tagów, albo gdy słaby wynik INP utrzymuje się mimo wcześniejszych poprawek. Przegląd tagów wykonujemy w ramach SEO technicznego i audytu SEO, a uporządkowanie pomiaru należy do analityki i raportowania SEO.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl