Jak poprawić Cumulative Layout Shift (CLS) w WordPressie, żeby strona przestała skakać

Znasz tę sytuację z telefonu: czytasz artykuł, chcesz kliknąć „Dalej”, a w ostatniej chwili nad przyciskiem wskakuje baner i palec ląduje w reklamie. To przesunięcie układu. Google mierzy je od 2020 roku wskaźnikiem CLS w ramach Core Web Vitals, a od maja 2026 ten sam wskaźnik jest jedną z trzech kontroli w kategorii Przeglądanie agentowe w Lighthouse. Powód jest inny niż przy ludziach: agent AI, który wypełnia za klienta formularz na Twojej stronie, klika po współrzędnych ze zrzutu ekranu i nie zauważa, że strona się dosunęła.

Na emedia.pl zmierzyliśmy to 4 września 2026. Strona główna i strona kontaktu miały CLS 0, strona usługi Google Ads 0,145, a wpis na blogu 0,50, pięć razy powyżej progu; w kolejnych pomiarach ten sam wpis dawał od 0,24 do 0,50, bo wynik zależy od tego, co zdąży się załadować przed zrzutem. W tym tekście tłumaczymy, jak czytać ten wskaźnik w PageSpeed Insights, skąd biorą się przesunięcia w WordPressie i co dokładnie zlecić programiście, żeby strona stała w miejscu.

Co to jest przesunięcie układu?

Strona ładuje się kawałkami. Najpierw pojawia się tekst, potem dojeżdżają obrazki, fonty z serwera Google, pasek zgody na cookies, osadzony film. Jeśli przeglądarka nie wie z góry, ile miejsca zajmie każdy z tych elementów, wstawia go w chwili, gdy nadejdzie, i przesuwa wszystko, co było niżej. Widoczny efekt to tekst, który „ucieka” spod oczu, i przycisk, który zmienia miejsce w sekundę po tym, jak go zobaczyłeś.

CLS, Cumulative Layout Shift, to liczba, którą przeglądarka wylicza z takich przesunięć. Nie ma jednostki. Każde przesunięcie dostaje wynik z dwóch składników: jak duża część ekranu się przesunęła i jak daleko. Przesunięcia zachodzące blisko siebie w czasie przeglądarka grupuje w okna i jako CLS strony podaje wynik największego okna. Google uznaje wynik 0,1 lub mniej za dobry, a powyżej 0,25 za słaby, i mierzy to dla 75 procent wizyt na stronie, nie dla jednej.

Jedno zastrzeżenie ma znaczenie przy naprawach: przesunięcia do 500 milisekund po działaniu użytkownika nie liczą się. Jeśli klient kliknie „Pokaż więcej” i strona się wydłuży, to nie jest błąd, bo klient tego chciał. Błędem jest przesunięcie, którego nikt nie wywołał.

Dlaczego agentom AI przeszkadza bardziej niż ludziom?

Człowiek, któremu przycisk uciekł spod palca, klnie i klika drugi raz. Agent AI działa inaczej. Dostaje polecenie w rodzaju „wyślij zapytanie o wycenę”, otwiera stronę, robi zrzut ekranu, na zrzucie znajduje przycisk i wysyła kliknięcie w konkretny punkt. Dokumentacja Chrome opisuje skutek przesunięcia wprost: nieoczekiwane zmiany układu mogą sprawić, że agent źle obliczy pozycję przycisku lub pola, co prowadzi do nieudanych interakcji. Agent nie ma odruchu „spróbuję jeszcze raz o centymetr niżej”. Trafia w baner, dostaje odpowiedź, której się nie spodziewał, i kończy zadanie z błędem albo z pomyloną akcją.

Do tego agent jest szybszy niż człowiek. Zrzut ekranu robi ułamek sekundy po tym, jak strona zgłosi gotowość, czyli często zanim dojadą obrazki i fonty. Człowiek, który przez sekundę czyta nagłówek, zdąży zobaczyć stronę po przesunięciu. Agent zdąży zobaczyć ją przed. Dlatego Google wpisał CLS do kategorii Przeglądanie agentowe obok drzewa dostępności i pliku llms.txt, z tym samym progiem 0,1 co w kategorii wydajności. Strona z CLS 0,145 oblewa tę kontrolę tak samo jak strona z 0,50.

Jak czytać CLS w PageSpeed Insights?

Wpisz adres strony na pagespeed.web.dev i poczekaj kilkadziesiąt sekund. Raport ma dwie części i obie pokazują CLS, ale z różnych źródeł.

Dane z terenu u góry to pomiary z przeglądarek prawdziwych użytkowników Chrome z ostatnich 28 dni. Google pokazuje wartość, poniżej której mieści się 75 procent wizyt, i to ta liczba decyduje o ocenie Core Web Vitals. Strony z małym ruchem nie mają danych z terenu i widzą tylko drugą część.

Dane laboratoryjne niżej to jeden pomiar Lighthouse wykonany przed chwilą na serwerze Google, na symulowanym telefonie. Właśnie tę wartość bierze kategoria Przeglądanie agentowe. Pomiar laboratoryjny obejmuje tylko ładowanie strony, bez przewijania i klikania, więc bywa niższy niż z terenu, gdzie liczą się też przesunięcia podczas czytania. Bywa też wyższy, jeśli w laboratorium wolniejsze łącze wydłuża ładowanie obrazków. Zmierz trzy razy i patrz na powtarzalny wynik.

Sam wynik mówi tylko, że coś się przesuwa. Odpowiedź na pytanie „co”, daje pozycja „Unikaj dużych zmian układu” w sekcji diagnostyki: lista elementów z wynikiem każdego przesunięcia i, gdy Lighthouse zdoła to ustalić, z przyczyną. Na wpisie emedia.pl raport wskazał dwa przesunięcia całego kontenera treści, 0,265 i 0,236, a na stronie usługi jedno przesunięcie akapitu o 0,145. To jest lista, którą wysyłasz programiście, razem z informacją, ile obrazów na stronie nie ma zapisanych wymiarów.

Pięć przyczyn i pięć napraw

Google w poradniku o optymalizacji CLS wymienia pięć źródeł przesunięć. Wszystkie sprowadzają się do jednego: przeglądarka dostaje element, dla którego nikt nie zarezerwował miejsca. Naprawa to zarezerwowanie miejsca z góry.

Kolejność napraw wynika z raportu, nie z tabeli. Jeśli diagnostyka wskazuje przesunięcie kontenera treści i na stronie jest kilkanaście obrazów bez wymiarów, zaczynasz od obrazów. Jeśli przesuwa się pierwszy akapit, patrzysz na to, co ładuje się nad nim: pasek, font, baner.

WordPress w praktyce: skąd 0,50 na wpisie

Pomiar emedia.pl z 4 września 2026 dobrze pokazuje, jak to wygląda w typowym serwisie na WordPressie. Strona główna i strona kontaktu: CLS 0, bo są zbudowane z bloków, w których edytor sam zapisuje wymiary obrazów. Strona usługi Google Ads: 0,145, przesunięcie akapitu, na stronie 10 obrazów bez zapisanej szerokości. Wpis na blogu: 0,50, dwa przesunięcia całego kontenera treści, 19 obrazów bez szerokości.

Skąd obrazy bez wymiarów, skoro edytor je zapisuje? Z trzech miejsc. Po pierwsze, z szablonu motywu: ikony, logo, obrazki wyróżniające wpisów i miniatury w sekcjach „podobne wpisy” wstawia motyw własnym kodem, a nie edytor, i tam atrybutów często brak. Po drugie, ze starszych wpisów, przenoszonych z poprzedniej wersji strony albo wklejanych z edytora klasycznego, gdzie obraz to sam adres pliku. Po trzecie, z wtyczek, które podmieniają kod obrazów pod leniwe ładowanie albo pod format WebP i przy okazji gubią wymiary.

Do tego dochodzą elementy, których w edytorze nie widać. Pasek zgody na cookies, jeśli wtyczka wstawia go u góry strony zamiast przykleić do dołu ekranu, wpycha całą treść w dół. Bloki dodawane skryptem po załadowaniu, jak spis treści czy ramka „przeczytaj także”, robią to samo, gdy stają nad treścią. Fonty Google ładowane z zewnętrznego serwera podmieniają się z opóźnieniem, a na wpisie z dwoma tysiącami słów każda zmiana szerokości liter przesuwa dół strony o kilkanaście wierszy.

Grzegorz Wysocki
CEO emedia

Komentarz autora: 0,50 na własnym wpisie zabolało, bo CLS sprawdzamy klientom w każdym audycie strony. U siebie sprawdzaliśmy stronę główną, która ma zero, i uznaliśmy temat za zamknięty. Wpisy na blogu przez ten czas dostały nowy układ, spis treści i bloki ze skryptu, a nikt nie zmierzył ich po zmianie. Wniosek na przyszłość jest jeden: mierzymy po każdej zmianie szablonu, na trzech typach stron, nie na jednej. Naprawę wpisów ustawiliśmy w kolejce po nazwach ikon w stopce, bo tamta poprawka podnosi wynik wszystkich stron naraz, a ta tylko bloga.

Jak zlecić naprawę programiście?

Prośba „popraw CLS” kończy się pytaniem zwrotnym. Prośba z raportem i tym spisem kończy się wyceną w godzinach:

1. Raport PageSpeed Insights dla trzech stron: głównej, jednej usługi i jednego wpisu, z wynikiem CLS z laboratorium i z terenu oraz listą z pozycji „Unikaj dużych zmian układu”.
2. Obrazy: wszystkie obrazy w szablonie motywu i we wtyczkach dostają atrybuty width i height; obrazy w treści sprawdzamy skryptem po bazie i uzupełniamy tam, gdzie brakuje.
3. Osadzenia: każdy film, mapa i formularz z zewnętrznego serwisu ma kontener o stałej wysokości albo proporcjach.
4. Elementy ze skryptu: pasek cookies, spis treści, bloki polecane i powiadomienia nie pojawiają się nad treścią po jej wyświetleniu; mają miejsce od początku albo są przyklejone poza treścią.
5. Fonty: pliki fontów ładowane wcześnie, font-display ustawiony na optional, font zastępczy o zbliżonej szerokości liter.
6. Animacje: efekty wjazdu i pojawiania się zrobione przez transform, nie przez zmianę pozycji i marginesów.
7. Pomiar po naprawie na tych samych trzech stronach, trzy razy każda, z zachowanymi raportami przed i po.

Realny czas dla serwisu na WordPressie z jednym motywem to zwykle 2 do 8 godzin na szablon, w zależności od liczby przyczyn. Największą część zajmują obrazy w starych wpisach, jeśli trzeba je poprawić ręcznie; skrypt po bazie skraca to do godziny.

Jak emedia może w tym pomóc?

Naprawy z listy powyżej wykonujemy w ramach usług Web development, a dla serwisów na WordPressie w ramach obsługi WordPressa: pomiar na trzech typach stron, lista elementów z raportu, uzupełnienie wymiarów w szablonie i w bazie, poprawki osadzeń, fontów i skryptów, potem ponowny pomiar. Oddajemy oba raporty, przed i po, żeby efekt było widać w tej samej tabeli, w której pojawił się problem.

Podsumowanie

CLS mierzy, o ile treść przesunęła się bez udziału użytkownika w trakcie ładowania. Dobry wynik to 0,1 lub mniej i taki sam próg obowiązuje w kategorii Przeglądanie agentowe, bo agent AI klika po współrzędnych ze zrzutu ekranu i nie poprawia się po chybieniu. Pięć przyczyn z poradnika Google to obrazy bez wymiarów, osadzenia bez miejsca, treść ze skryptu, fonty i animacje, a każda naprawa polega na zarezerwowaniu miejsca z góry. Na emedia.pl strony z bloków miały CLS 0, a wpis na blogu 0,50 przez 19 obrazów bez wymiarów i bloki ze skryptu. Pomiar w PageSpeed Insights trwa minutę, naprawa szablonu 2 do 8 godzin.

Przeczytaj także

• Jak pozycjonować firmę w AI, żeby ChatGPT i Gemini polecały ją klientom
• Jak przygotować stronę na agentów AI i dostać 3/3 w Lighthouse
• Jak poprawić dostępność strony w WordPressie, żeby agent AI znalazł każdy przycisk
• Jak zrobić plik llms.txt na stronie firmowej
• Co to jest WebMCP i co przygotować na stronie, zanim agenci AI zaczną z niej korzystać
• GEO: jak być widocznym w chatbotach AI

Najczęstsze pytania

Jak to powstaje. Tematy, pomiary i ostatnie słowo: Grzegorz Wysocki. Redakcja i porządkowanie źródeł: Claude (Anthropic). Diagram: rysunek własny, zrzut makiety HTML. Model obrazu nie brał udziału.

Na czym to stoi. web.dev, „Cumulative Layout Shift (CLS)” i „Optimize Cumulative Layout Shift”, stan na 4 września 2026; Chrome for Developers, dokumentacja kontroli stabilności układu w kategorii Agentic Browsing w Lighthouse, stan na 4 września 2026; kod źródłowy Lighthouse 13.4.1 (kontrola cumulative-layout-shift z wagą 1 w tej kategorii). Pomiary emedia.pl: 4 września 2026, Lighthouse 13.4.1, Chrome 151, tryb telefonu, kategorie Przeglądanie agentowe i Wydajność. Czego nie wiemy, o tym piszemy wprost: nie wiemy, jak często agenci AI odświeżają zrzut ekranu przed kliknięciem, więc opisujemy mechanizm, nie statystykę chybień.

Realizacja: artykuł zrealizowany przez człowieka we współpracy z systemami AI. Redakcję i publikację firmuje autor.

Opublikowano 05.09.2026

Więcej na ten temat: agenci AI Lighthouse dostępność Widoczność w AI