Baner zgody na pliki cookie a szybkość strony: wpływ na LCP, CLS i INP

Dlaczego baner zgody wpływa na szybkość strony

Baner zgody wpływa na szybkość, ponieważ jest jednocześnie dodatkowym plikiem do pobrania, dodatkowym kodem do wykonania i dodatkowym elementem do narysowania na ekranie, a wszystko to dzieje się w pierwszych chwilach wizyty. Do tego steruje on uruchamianiem innych skryptów: analityki, pikseli reklamowych, czatu, map. Od sposobu, w jaki to robi, zależy, kiedy i jak gwałtownie te skrypty obciążą przeglądarkę.

Zespół Google opisał ten temat w opracowaniu o dobrych praktykach dla powiadomień o plikach cookie. Wynika z niego, że banery zewnętrznych dostawców obciążają stronę zazwyczaj bardziej niż rozwiązania napisane samodzielnie, a powiadomienie dotyka wszystkich trzech wskaźników z grupy Core Web Vitals, czyli podstawowych wskaźników internetowych, każdego w inny sposób. O skali problemu decydują głównie dwie rzeczy, na które właściciel strony ma wpływ: miejsce banera na ekranie i sposób dołączenia jego skryptu.

Kwestie prawne, treść komunikatu i układ przycisków omawiamy w osobnym wpisie o tym, jak zaprojektować baner zgody na pliki cookie. Tutaj zajmujemy się wyłącznie czasem wczytywania i stabilnością strony. Żadna z opisanych niżej technik nie może jednak prowadzić do uruchamiania skryptów śledzących przed uzyskaniem zgody tam, gdzie zgoda jest wymagana.

Trzy wskaźniki, trzy różne mechanizmy

Każdy wskaźnik reaguje na baner z innego powodu. LCP, czyli czas wyrysowania największego elementu treści w widocznej części ekranu, cierpi wtedy, gdy skrypt banera wstrzymuje budowanie strony albo gdy sam baner okazuje się największym elementem. CLS, czyli miara nieoczekiwanych przesunięć układu, rośnie, gdy baner pojawia się w dokumencie po wyrysowaniu treści i spycha ją w inne miejsce. INP, czyli czas od interakcji do następnej klatki obrazu, pogarsza się w chwili kliknięcia przycisku w banerze, bo właśnie wtedy strona zaczyna wykonywać najwięcej pracy.

Kiedy okno zgody staje się elementem LCP

Okno zgody staje się elementem LCP wtedy, gdy zawarty w nim blok tekstu zajmuje w widocznej części ekranu więcej miejsca niż jakikolwiek inny tekst, obraz lub film na stronie. Według web.dev zdarza się to rzadko, bo powiadomienia są zwykle niewielkie, ale prawdopodobieństwo rośnie na urządzeniach mobilnych, gdzie baner zabiera większą część ekranu, zwłaszcza gdy zawiera długi akapit.

Z opisu wskaźnika LCP na web.dev wynika, że pod uwagę brane są obrazy, plakaty i pierwsze klatki filmów, elementy z obrazem tła oraz elementy blokowe zawierające tekst. Liczy się tylko ta część elementu, która mieści się w widocznym obszarze, a marginesy, odstępy wewnętrzne i obramowania są pomijane. Przeglądarki oparte na Chromium pomijają też elementy całkowicie przezroczyste oraz takie, które pokrywają cały widoczny obszar, bo uznają je za tło, a nie treść.

Płyną z tego dwa wnioski. Warstwa przyciemniająca całą stronę pod oknem zgody nie zostanie uznana za największy element. Natomiast akapit wyjaśniający, do czego służą pliki cookie, już tak, jeśli na ekranie telefonu zajmie więcej miejsca niż nagłówek strony czy zdjęcie produktu. Hipotetyczny przykład: strona kancelarii z Krakowa otwiera się krótkim nagłówkiem i dwoma zdaniami wstępu, a okno zgody zawiera kilkuzdaniowy opis celów przetwarzania. Na wąskim ekranie to właśnie ten opis może okazać się największym blokiem tekstu.

Co to oznacza dla wyniku

Jeżeli największym elementem jest tekst banera, to LCP jest równe chwili, w której baner pojawił się na ekranie. Przy banerze ładowanym z zewnętrznego serwera, doczytującym własne style i czcionki, ta chwila następuje później niż wyrysowanie treści samej strony. Dokumentacja wyjaśnia również, że usunięcie największego elementu z ekranu nie zmienia zapisanego już wyniku, chyba że później wyrysuje się coś większego, a pomiar kończy się w momencie pierwszej interakcji, czyli dotknięcia ekranu, przewinięcia lub naciśnięcia klawisza. Zamknięcie banera nie cofa więc opóźnienia, które zostało już zmierzone.

Rozwiązania są dwa. Pierwsze to skrócenie tekstu w pierwszej warstwie banera: zwięzły komunikat i odnośnik do szczegółów zajmują mniej miejsca niż pełny opis kategorii. Zakres informacji wymaganych w pierwszej warstwie jest kwestią prawną, dlatego skróty warto uzgodnić z prawnikiem. Drugie to przyspieszenie samego banera, o czym piszemy dalej. Pozostałe przyczyny wolnego wyrysowania opisujemy we wpisie o tym, co opóźnia LCP i jak to naprawić.

Jak baner przesuwa układ strony i podnosi CLS

Baner przesuwa układ wtedy, gdy zostaje wstawiony do dokumentu po wyrysowaniu treści i zajmuje w nim własne miejsce, zamiast zostać nałożony na stronę. Najczęstszy przypadek to pasek u góry ekranu: treść jest już widoczna, po chwili skrypt dodaje nad nią baner i wszystko zjeżdża w dół. Web.dev określa powiadomienia o plikach cookie jako bardzo częste źródło przesunięć układu.

Opracowanie o optymalizacji CLS dodaje ważną zależność: treść wstrzykiwana wyżej na ekranie powoduje większe przesunięcia niż wstrzykiwana niżej. Opisuje też dwa sposoby radzenia sobie z elementami pojawiającymi się z opóźnieniem: można zawczasu zarezerwować dla nich miejsce albo nałożyć je na treść tak, żeby nie brały udziału w układzie dokumentu.

Rezerwacja miejsca czy nakładka

Rezerwacja miejsca polega na tym, że w kodzie strony od początku znajduje się pusty pojemnik o ustalonej minimalnej wysokości, a baner wypełnia go po załadowaniu. Metoda ma słabe strony. Wysokość banera zależy od szerokości ekranu i długości tekstu, więc trudno ją przewidzieć. Jeśli baner wyświetla się tylko części odwiedzających, na przykład zależnie od kraju, zarezerwowane miejsce u pozostałych trzeba zwinąć, a to wywołuje takie samo przesunięcie jak wstawienie treści.

Dlatego web.dev radzi, by w takiej sytuacji sięgnąć po przyklejony pasek u dołu ekranu albo okno modalne. Nakładka poza układem dokumentu zasłania fragment strony, ale nie zmienia położenia żadnego elementu. Dół ekranu opracowanie uznaje za zazwyczaj najlepszy wybór, bo taki baner jest mało natarczywy i zwykle nie powoduje przesunięć. Okno modalne zajmujące część ekranu jest wskazane jako dobra alternatywa, natomiast duże okno zasłaniające treść wymaga ostrożności.

.baner-zgody {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;
  transform: translateY(100%);
  transition: transform 0.3s ease;
}

.baner-zgody.widoczny {
  transform: translateY(0);
}

Animacja wjazdu i czcionki banera

Sama animacja pojawiania się banera także może zmieniać układ. Z opisu CLS wynika, że animowanie właściwości takich jak top czy left może wywoływać przesunięcia, natomiast animacje oparte na właściwości transform nie wymagają ponownego przeliczania układu i nie są wliczane do CLS. W przykładzie powyżej baner wjeżdża właśnie w ten sposób.

Mniej oczywistym źródłem przeskoków są czcionki. Banery zewnętrznych dostawców często nie korzystają z czcionek wczytanych przez stronę, a ich style ładują się na końcu długiego łańcucha żądań. Późno doczytana czcionka zmienia wymiary tekstu, co widać zwłaszcza na wolnym łączu. Jeśli panel dostawcy pozwala wybrać krój pisma, bezpieczniej wskazać ten, którego strona i tak używa, albo czcionkę systemową. Więcej piszemy o tym przy okazji czcionek internetowych i ich wpływu na szybkość.

Dobra wiadomość dotyczy zamykania banera. Przesunięcia, które następują w ciągu 500 milisekund od działania odwiedzającego, są traktowane jako oczekiwane i nie wchodzą do wyniku. Kłopot pojawia się, gdy reakcja trwa dłużej, na przykład dlatego, że kliknięcie najpierw uruchamia ciężkie skrypty, a baner znika dopiero po nich. Pozostałe przyczyny omawiamy we wpisie o tym, skąd biorą się przeskoki układu strony.

Dlaczego kliknięcie w baner psuje INP

Kliknięcie w baner psuje INP, ponieważ wyrażenie zgody jest sygnałem do uruchomienia wszystkiego, co do tej pory czekało: analityki, znaczników reklamowych, pikseli sieci społecznościowych. Web.dev podaje wprost, że powiadomienia o plikach cookie często są przyczyną wysokiego INP, głównie przy kliknięciu przycisku akceptacji, bo jednoczesne dołączenie wielu skryptów zewnętrznych to dla przeglądarki ciężka praca.

Zgodnie z opisem INP każda interakcja składa się z trzech faz. Opóźnienie wejścia to czas, zanim przeglądarka zacznie obsługiwać kliknięcie. Czas przetwarzania to wykonanie kodu przypisanego do zdarzenia. Opóźnienie prezentacji to czas od zakończenia tego kodu do pokazania następnej klatki. Wskaźnik obserwuje kliknięcia, dotknięcia i naciśnięcia klawiszy przez całą wizytę, a wynikiem jest w praktyce najdłuższa z zaobserwowanych interakcji. Kliknięcie w baner jest zwykle pierwszą interakcją na stronie i łatwo staje się zarazem tą najwolniejszą.

Jak odciążyć przycisk akceptacji

Zalecenie z opracowania o optymalizacji INP jest proste: w obsłudze zdarzenia należy wykonać tylko to, co potrzebne do pokazania następnej klatki, a resztę odłożyć. W przypadku banera oznacza to, że po kliknięciu okno powinno najpierw zniknąć, a dopiero później, w osobnym zadaniu, strona może zapisać wybór i uruchamiać kolejne skrypty. Opisana tam technika polega na zaplanowaniu mniej pilnej pracy przez requestAnimationFrame połączone z setTimeout.

przyciskAkceptacji.addEventListener('click', function () {
  baner.hidden = true;

  requestAnimationFrame(function () {
    setTimeout(function () {
      zapiszWyborOdwiedzajacego();
      zaktualizujStanZgody();
      uruchomZnacznikiPoZgodzie();
    }, 0);
  });
});

Przy gotowym rozwiązaniu dostawcy właściciel strony nie pisze tego kodu sam, ale ma wpływ na to, ile pracy czeka na kliknięcie. Każdy znacznik uruchamiany po zgodzie to kolejny plik do pobrania, przeanalizowania i wykonania. Przegląd listy znaczników w menedżerze tagów i usunięcie tych, z których nikt już nie korzysta, bywa z naszej praktyki najskuteczniejszym sposobem na poprawę tego jednego kliknięcia. Szerzej opisujemy to we wpisach o tym, jak skrypty zewnętrzne spowalniają stronę, oraz o tym, jak skrócić czas reakcji na kliknięcie.

Jak osadzić skrypt banera, żeby nie opóźniał strony

Skrypt banera najlepiej umieścić bezpośrednio w kodzie HTML strony, z atrybutem async, i zadbać o wczesne połączenie z serwerem, z którego jest pobierany. To trzy zalecenia web.dev, które razem decydują o tym, jak szybko baner się pojawi i czy po drodze nie wstrzyma reszty strony.

Atrybut async sprawia, że przeglądarka pobiera plik w tle i nie przerywa analizowania kodu strony. Skrypt synchroniczny blokuje ten proces, co opóźnia wczytanie strony i LCP. Opracowanie zastrzega, że niektóre banery wymagają skryptu synchronicznego, bo w ten sposób blokują zapis plików cookie przez inne skrypty. Jeśli tak jest, pozostaje zadbać, by ten jeden plik pobierał się możliwie szybko.

Drugie zalecenie dotyczy miejsca osadzenia. Skrypt dołączany przez menedżer tagów albo przez inny skrypt startuje później, ponieważ przeglądarka dowiaduje się o nim dopiero po pobraniu i wykonaniu pośrednika. Jest też niewidoczny dla mechanizmu, który z wyprzedzeniem przegląda kod HTML w poszukiwaniu plików do pobrania. Znacznik wpisany wprost w dokument takich ograniczeń nie ma.

Trzecie zalecenie to podpowiedzi dla przeglądarki. Gdy baner pochodzi z obcej domeny, warto zawczasu nawiązać z nią połączenie przez preconnect albo przynajmniej ustalić jej adres przez dns-prefetch, osobno dla każdej domeny. Wstępne pobranie pliku przez preload bywa pomocne, ale działa najlepiej, gdy obejmuje najwyżej parę kluczowych zasobów na stronie. Działanie tych podpowiedzi wyjaśniamy we wpisie o preload, preconnect i fetchpriority.

<link rel="preconnect" href="https://cdn.dostawca-banera.example">
<script async src="https://cdn.dostawca-banera.example/baner.js"></script>

Web.dev wymienia też techniki bardziej zaawansowane: serwowanie skryptu banera z własnego serwera oraz sterowanie jego pobieraniem i przechowywaniem przez service worker, czyli skrypt pośredniczący działający w tle przeglądarki. Wymagają one pilnowania aktualizacji po stronie dostawcy, dlatego sprawdzają się głównie tam, gdzie stroną opiekuje się stały zespół techniczny.

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

Tryb uzyskiwania zgody Google a ładowanie znaczników

Tryb uzyskiwania zgody to mechanizm, przez który baner przekazuje znacznikom Google wybór odwiedzającego, a wybrany wariant wdrożenia decyduje o tym, kiedy te znaczniki w ogóle się wczytują. Ma to bezpośredni związek z szybkością: w jednym wariancie skrypty Google pracują od początku wizyty, w drugim pojawiają się dopiero po kliknięciu w baner.

Różnicę opisuje omówienie trybu uzyskiwania zgody w dokumentacji Google. W wariancie podstawowym znaczniki pozostają zablokowane, dopóki odwiedzający nie zareaguje na baner, i do tego czasu nic nie jest wysyłane. W wariancie zaawansowanym znaczniki wczytują się przy otwarciu strony z domyślnym stanem odmowy, a przy braku zgody wysyłają sygnały bez plików cookie. Wybór wariantu to decyzja prawna i biznesowa, którą warto podjąć z prawnikiem i osobą prowadzącą kampanie. Tu pokazujemy tylko jej skutki dla wczytywania.

Kolejność kodu i parametr wait_for_update

Niezależnie od wariantu liczy się kolejność. Według instrukcji konfigurowania trybu uzyskiwania zgody w witrynach polecenie ustawiające stan domyślny musi znaleźć się na każdej stronie przed poleceniami wysyłającymi dane pomiarowe, potem wczytuje się rozwiązanie do zbierania zgód, a po wyborze odwiedzającego następuje aktualizacja stanu. Przy złej kolejności ustawienia domyślne nie zadziałają.

Tu wraca atrybut async. Baner ładowany asynchronicznie może nie zdążyć przed znacznikami Google, dlatego dokumentacja przewiduje parametr wait_for_update, który określa w milisekundach, jak długo znaczniki mają czekać na aktualizację zgody. W przykładzie Google jest to 500 milisekund. Parametr godzi szybkie, nieblokujące ładowanie banera z poprawnym odczytem zapamiętanego wyboru u powracających osób.

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});

Dokumentacja zwraca też uwagę, że aktualizację zgody należy wysłać na tej stronie, na której odwiedzający dokonał wyboru, i z wyprzedzeniem przed jej opuszczeniem, bo przeglądarka może anulować żądania rozpoczęte podczas zamykania strony. Od poprawności tego elementu zależą dane w kampaniach, o czym piszemy przy śledzeniu konwersji w Google Ads.

Jak testować stronę z banerem i bez niego

Stronę trzeba zmierzyć w trzech stanach: przed odpowiedzią na baner, po akceptacji i po odmowie, bo w każdym z nich przeglądarka wykonuje inną pracę. Web.dev przypomina, że testy syntetyczne domyślnie pokazują tylko pierwszy stan, czyli osobę, która weszła po raz pierwszy i jeszcze niczego nie kliknęła.

Dotyczy to zwłaszcza PageSpeed Insights. Narzędzie uruchamia świeżą przeglądarkę bez plików cookie i nie pozwala tego zmienić, więc jego część laboratoryjna zawsze opisuje stronę z widocznym banerem. Z kolei dane od użytkowników w tym samym raporcie pochodzą z raportu Chrome UX i obejmują poprzednie 28 dni, a więc mieszają wszystkie stany. Stąd częste rozbieżności, które wyjaśniamy we wpisie o tym, dlaczego wynik testu różni się od danych od użytkowników.

Porównanie w narzędziach deweloperskich Chrome

Najwięcej pokazuje test we własnej przeglądarce. Lighthouse uruchamiany z narzędzi deweloperskich Chrome domyślnie nie czyści plików cookie, więc po wyrażeniu zgody mierzy stronę bez banera, a po zaznaczeniu opcji czyszczenia pamięci (Clear storage) znów jak przy pierwszej wizycie. Dwa przebiegi dają porównanie obu stanów.

Wpływ samego skryptu banera można wyodrębnić przez jego zablokowanie. Według dokumentacji Chrome DevTools wystarczy w panelu Network kliknąć żądanie prawym przyciskiem myszy i wybrać blokowanie albo otworzyć szufladę Request conditions i dodać wzorzec adresu z gwiazdką. Zablokowane żądania mają w kolumnie Status oznaczenie blocked:devtools. Różnica między pomiarem z blokadą i bez niej pokazuje koszt banera.

Kliknięcie przycisku akceptacji najlepiej obserwować w panelu Performance. Po otwarciu pokazuje on lokalne wartości LCP i CLS, a po interakcji także INP. Zakładka Interactions wymienia zarejestrowane interakcje z czasami i fazami, a Layout shifts przesunięcia wraz z elementami, których dotyczyły. Warto przy tym spowolnić procesor i sieć w ustawieniach panelu, bo na szybkim komputerze problem bywa niewidoczny.

1. Pomiar pierwszej wizyty

   Wyczyszczone dane witryny, baner widoczny. Do zanotowania: element LCP, wartość CLS i przesunięte elementy.

2. Pomiar kliknięcia

   Kliknięcie akceptacji przy otwartym panelu Performance i odczyt INP z podziałem na fazy. To samo dla odmowy.

3. Pomiar po zgodzie

   Ponowne wczytanie strony z zapamiętanym wyborem. Widać, ile kosztują skrypty uruchamiane po zgodzie.

4. Pomiar z zablokowanym banerem

   Punkt odniesienia: strona bez skryptu zgody.

Ostateczną miarą pozostają dane od prawdziwych odwiedzających. Web.dev zaznacza, że narzędzia analityczne oparte na plikach cookie nie zbierają danych od osób, które odmówiły, choć sam pomiar wydajności plików cookie nie wymaga. W Search Console wyniki grup adresów pokazuje raport Podstawowe wskaźniki internetowe.

Typowe pomyłki i kiedy potrzebna jest pomoc

Najczęstsza pomyłka to ocenianie banera wyłącznie po wyniku testu laboratoryjnego, który nie widzi ani kliknięcia, ani wizyty po zgodzie. Druga to próba poprawy wyniku przez opóźnienie banera o kilka sekund: test wypada lepiej, ale baner pojawia się później, częściej okazuje się elementem LCP i przesuwa treść, którą odwiedzający już czyta.

Częste jest też dołączanie banera przez menedżer tagów razem ze wszystkimi pozostałymi znacznikami, przez co startuje on na końcu kolejki. Spotykamy również dwa banery działające równocześnie, na przykład jeden z wtyczki sklepu i drugi od zewnętrznego dostawcy. Osobną kwestią jest forma: dokumentacja wyszukiwarki Google o reklamach pełnoekranowych i oknach wyłącza komunikaty wymagane prawem spod swoich zaleceń, ale radzi nakładać je na treść, a nie przekierowywać na osobną stronę, tak aby treść dało się zindeksować.

• Skrypt banera jest wpisany bezpośrednio w kod HTML, z atrybutem async, o ile dostawca na to pozwala.
• Dla domeny dostawcy ustawiono preconnect lub dns-prefetch.
• Baner jest nakładką u dołu ekranu albo oknem modalnym i nie zajmuje miejsca w układzie dokumentu.
• Animacja pojawiania się korzysta z właściwości transform.
• Tekst pierwszej warstwy jest zwięzły, a baner używa czcionki strony lub systemowej.
• Po kliknięciu baner znika od razu, a znaczniki uruchamiają się w osobnym zadaniu.
• Stan domyślny zgody stoi w kodzie przed znacznikami Google, a przy banerze asynchronicznym ustawiono wait_for_update.
• Pomiary wykonano w trzech stanach: przed wyborem, po akceptacji i po odmowie.

Pomoc specjalisty przydaje się wtedy, gdy wyniki w danych od użytkowników pozostają słabe mimo poprawnej konfiguracji albo gdy poprawki wymagają jednoczesnych zmian w szablonie, menedżerze tagów i ustawieniach dostawcy banera. Taką diagnozę wykonujemy w ramach audytu SEO, a wdrożenie poprawek prowadzimy jako SEO techniczne. Zmiany dotykające zbierania zgód każdorazowo warto potwierdzić z prawnikiem.

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