Czy banery cookies szkodzą Core Web Vitals? Skąd naprawdę bierze się koszt

Trzy sposoby, w jakie baner Cię kosztuje

Core Web Vitals to trzy liczby: Largest Contentful Paint, ile trwa narysowanie największego elementu na ekranie; Cumulative Layout Shift, jak bardzo strona przesuwa się podczas ładowania; Interaction to Next Paint, ile strona potrzebuje, by zareagować na kliknięcie. Baner zgody może zaszkodzić każdej z nich, ale przez trzy różne mechanizmy, a obiegowa mądrość („banery są wolne”) ukrywa, który dotyka Ciebie.

LCP: blokujący bundle

Pierwszy mechanizm to ten, o którym inżynierowie wydajności piszą najwięcej. Wiele menedżerów zgód dostarcza duży skrypt, ładowany synchronicznie w head, który musi się pobrać i wykonać, zanim przeglądarka będzie dalej parsować stronę. Analiza popularnych CMP przez DebugBear pokazuje przypadki, w których skrypt banera podnosi LCP z około 1,4 sekundy do 3,6 i wstrzykuje dziesiątki tysięcy węzłów DOM. Drugi, cichszy problem z LCP: jeśli baner jest największym elementem w viewporcie na ekranie telefonu, staje się elementem LCP, a jego własny czas renderowania jest Twoim wynikiem.

Rozwiązanie pierwszego jest architektoniczne: runtime musi być mały i nie może blokować parsowania. Rozwiązanie drugiego to projekt: baner będący paskiem lub kartą w rogu zamiast pełnoekranowego modala, przy pierwszej wizycie, na telefonie.

CLS: spóźniony baner

Drugi mechanizm to przesunięcie układu i prawie zawsze jest zawinione samodzielnie. Baner wstrzyknięty po pierwszym renderze, który spycha treść strony w dół, wytwarza przesunięcie równe własnej wysokości, co na telefonie to większość budżetu CLS wynoszącego 0,1. Banery wsuwające się nad treść niczego nie przesuwają; banery wstawiające się w przepływ dokumentu tak. Rozwiązanie to zarezerwowanie miejsca przed renderem albo nakładanie zamiast wstawiania.

INP: wybuch przy kliknięciu

Trzeci mechanizm jest najnowszy i najmniej omawiany. INP mierzy opóźnienie między interakcją a następną klatką. Kliknięciem, które najbardziej boli na stronie z zarządzaniem zgodą, jest Akceptuj wszystko: w tej chwili baner zwalnia naraz każdy zablokowany skrypt, a tuzin tagów walczy o główny wątek, podczas gdy strona próbuje przerysować zamykający się baner. Opracowanie SpeedCurve o menedżerach zgód wymienia to jako najczęstszą regresję INP, jaką widzą. Baner jej nie spowodował; zrobiły to tagi, ale baner je zaplanował.

Rozwiązaniem jest harmonogram. Zwolnione skrypty powinny działać w kolejności dokumentu, ustępując między sobą, poza ścieżką krytyczną interakcji, żeby baner zamknął się pierwszy, a trackery poszły za nim.

Jak zbudowany jest runtime CookieCrumbs

• 21 kB po gzipie, jeden plik. Ładowany asynchronicznie z długim czasem cache, z naszej własnej domeny. Instaluje interceptor synchronicznie w kilkuset bajtach logiki inline, a resztę pobiera potem, więc nic nie blokuje parsowania i nic nie działa, zanim interceptor istnieje.
• Żadnych własnych żądań do firm trzecich. Bez webfontu, bez zestawu ikon, bez analityki banera. Krój pisma pochodzi z systemu lub z Twojej strony.
• Miejsce zarezerwowane przed renderem. Układy pasek i wstążka dopełniają dokument o własną wysokość, dopóki są widoczne, przy tej krawędzi, przy której siedzą, więc nic się nie przesuwa. Zmierzony wkład w CLS: 0,00.
• Zwalnianie po kolei, z ustępowaniem. Po zgodzie zablokowane skrypty są odtwarzane w kolejności dokumentu z przerwą między nimi, więc kliknięcie kończy się, zanim trackery ruszą.
• Nie element LCP. Domyślne układy są tak zwymiarowane, że to Twoja treść, nie baner, jest największym renderem na telefonie.

Jak zmierzyć własny

1. Uruchom PageSpeed Insights na stronie z widocznym banerem (świeży profil, bez cookie zgody). Odczytaj dane terenowe, jeśli je masz; dane laboratoryjne wystarczą na start.
2. W diagnostyce LCP sprawdź, który element jest elementem LCP. Jeśli to baner, zmień układ.
3. W diagnostyce CLS poszukaj przesunięcia w chwili pojawienia się banera. Jeśli jest, baner wstawia się w przepływ dokumentu.
4. Nagraj ślad wydajności, kliknij Akceptuj wszystko i odczytaj długie zadania, które nastąpią. To Twój koszt INP i należy do tagów, które zwolniłeś.
5. Porównaj w panelu sieci rozmiar transferu skryptu banera i czy blokuje renderowanie. Poniżej 30 kB i asynchronicznie to cel.

Potem uruchom darmowy skan: powie Ci, ile trackerów zostanie zwolnionych przy tym kliknięciu, a to liczba, która obchodzi INP.

Źródła

1. DebugBear, „Cookie consent banners, page speed, and Core Web Vitals”
2. SpeedCurve, „Five ways cookie consent managers hurt web performance (and how to fix them)”
3. Termly, „How to optimize your cookie banner for Core Web Vitals”
4. Google, progi Core Web Vitals na web.dev (LCP 2,5 s, CLS 0,1, INP 200 ms)
5. CookieCrumbs, sekcja banera (21 kB, CLS 0,00)

Napisane przez zespół CookieCrumbs, opublikowane 5 września 2026 r. Fakty mają swoje daty; jeśli któryś się zdezaktualizował, daj nam znać, a poprawimy.