Skumulowana zmiana układu (CLS)

TL;DR — Cumulative Layout Shift (CLS) mierzy, ile elementów na stronie porusza się samoistnie podczas czytania lub klikania — obraz, który ładuje się późno i przesuwa tekst w dół, przycisk, który przeskakuje w momencie kliknięcia. Wynik jest liczony od 0 w górę, a 0,1 lub mniej jest dobry. Większość problemów wynika z elementów, które nie zarezerwowały swojego miejsca przed załadowaniem.

Czym jest CLS

Odczułeś to nawet, jeśli nigdy nie słyszałeś tego terminu. Czytasz artykuł, reklama lub obraz kończy ładowanie się nad miejscem, na które patrzysz, i nagle cała strona przeskakuje w dół. Albo chcesz kliknąć „Anuluj”, a pojawia się baner, więc klikasz „Potwierdź”. To nieoczekiwane przesunięcie to przesunięcie układu, a Cumulative Layout Shift to sposób Google na określenie, jak bardzo jest to problematyczne.

To jedna z trzech Core Web Vitals — trzech wskaźników doświadczenia strony, które śledzi Google, obok Largest Contentful Paint (jak szybko ładuje się główna treść) i Interaction to Next Paint (jak szybko strona reaguje na kliknięcie). CLS dotyczy stabilności wizualnej: czy strona pozostaje nieruchoma?

Jak działa wynik (w przybliżeniu)

CLS to wynik, nie czas. CLS 0,05 nie oznacza 50 milisekund czegokolwiek — to liczba bezwymiarowa. Im większy fragment ekranu się przesuwa i im dalej się przesuwa, tym wyższy (gorszy) wynik.

Cele są proste:

• 0,1 lub mniej — dobrze.
• 0,1 do 0,25 — wymaga poprawy.
• Powyżej 0,25 — słabo.

Jeden miły szczegół: przesunięcia, które występują tuż po tym, jak ty coś zrobisz — klikniesz przycisk, otworzysz menu — nie liczą się przeciwko stronie, ponieważ to ty je spowodowałeś i ich oczekujesz. Liczy się tylko nieoczekiwane przesunięcie.

Dlaczego to się dzieje (i naprawa)

Prawie każde przesunięcie układu sprowadza się do tego samego: coś się załadowało i zajęło miejsce, którego strona nie zarezerwowała. Główne przyczyny:

• Obrazy i filmy bez rozmiarów. Przeglądarka nie wie, jak wysoki jest obraz, dopóki nie dotrze, więc tekst pod nim jest przesuwany w dół, gdy to nastąpi. Naprawa: zawsze podawaj obrazom width i height (lub CSS aspect-ratio), aby przeglądarka zarezerwowała miejsce.
• Reklamy, osadzone elementy i iframe. Ten sam problem — zarezerwuj dla nich miejsce.
• Czcionki internetowe. Gdy niestandardowa czcionka zastępuje zapasową, tekst może się przelać.
• Wyskakujące elementy. Banery cookie, pola „może Ci się spodobać”, wszystko, co jest wstrzykiwane nad treścią, którą już oglądasz.

Zasada mentalna: jeśli coś ma się pojawić później, zostaw odpowiednią dziurę dla tego, aby nic innego nie musiało się przesuwać, gdy się pojawi.

Chcesz poznać rzeczywisty wzór, zasadę „okna sesji”, dlaczego wyniki CLS w laboratorium i w terenie się różnią oraz pełną listę przyczyn i napraw? Przełącz się na zakładkę Zaawansowane.

TL;DR — CLS to Core Web Vital dla stabilności wizualnej. Każde przesunięcie jest oceniane jako impact fraction × distance fraction; sam wskaźnik to największe okno sesji przesunięć (≤ 1 s między przesunięciami, okno ≤ 5 s) — a nie suma całkowita, co było przed czerwcem 2021. Dobry wynik to ≤ 0,1, wymaga poprawy ≤ 0,25, słaby > 0,25, na 75. percentylu danych terenowych. Liczą się tylko przesunięcia widoczne w viewporcie; przesunięcia w ciągu 500 ms od dyskretnego wejścia są wykluczone (przewijanie nie jest). Przyczyny to obrazy/filmy/reklamy/iframe/osadzone elementy bez rozmiarów, czcionki internetowe i treści wstrzykiwane nad istniejącą treścią; naprawy to rezerwowanie miejsca, font-display/size-adjust i animacja tylko z transform. Pułapka do uniknięcia: Lighthouse (laboratorium) zwykle odczytuje blisko 0, ponieważ nie wchodzi w interakcję ze stroną ani nie uruchamia pełnego cyklu życia — dane terenowe (CrUX) to to, co Google faktycznie mierzy.

Co mierzy CLS

Ujęcie Google: “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” (tłumaczenie) „Skumulowane przesunięcie układu (CLS) to stabilny wskaźnik Core Web Vitals. To ważny, skoncentrowany na użytkowniku wskaźnik pomiaru stabilności wizualnej, ponieważ pomaga określić, jak często użytkownicy doświadczają nieoczekiwanych przesunięć układu.” Kluczowe słowo to nieoczekiwane — treść, która przesuwa się sama, a nie dlatego, że użytkownik coś zrobił.

Znajduje się w trio Core Web Vitals obok Largest Contentful Paint (ładowanie) i Interaction to Next Paint (responsywność). Podczas gdy LCP i INP są mierzone w milisekundach, CLS jest wyjątkiem: bezwymiarowy wynik proporcji. To często wprowadza ludzi w błąd. CLS wynoszące 0,05 to nie 50 ms. Nie ma w ogóle jednostki czasu.

Wzór: wpływ × odległość

Dla każdego przesunięcia Google definiuje to jako:

layout shift score = impact fraction × distance fraction

• Frakcja wpływu mierzy, jak niestabilne elementy wpływają na obszar widoku między dwiema klatkami — łączny widoczny obszar zajmowany przez przesuwające się elementy (przed i po), jako udział w rzutni.
• Frakcja odległości to największa pozioma lub pionowa odległość, o jaką niestabilny element przesunął się w klatce, podzielona przez większy wymiar obszaru widoku — szerokość albo wysokość.

Obie te wielkości mają znaczenie niezależnie. Mały element, który przemieszcza się po większości ekranu, i duży element, który ledwo się przesuwa, mogą uzyskać bardzo różne wyniki. Przykład z web.dev: frakcja wpływu 0.75 i frakcja odległości 0.25 dają wynik przesunięcia układu 0.1875.

Okna sesji: część, którą wszyscy rozumieją źle

Oto najczęściej błędnie przedstawiany fakt dotyczący CLS i ten, który najbardziej chcę, abyś zapamiętał. CLS nie jest sumą wszystkich przesunięć w ciągu życia strony. Kiedyś tak było — to się zmieniło w czerwcu 2021.

Dziś CLS mierzy największą serię wyników nieoczekiwanych przesunięć układu występujących w całym cyklu życia strony. Seria to okno sesji: co najmniej jedno przesunięcie występujące szybko po poprzednim, z odstępem krótszym niż 1 sekunda i maksymalnym czasem całego okna wynoszącym 5 sekund. CLS to wynik największego takiego okna — nie suma, nie średnia.

Dlaczego ta zmiana? Stara definicja sumowania wszystkiego po cichu karała długo żyjące strony. Aplikacja jednostronicowa lub kanał z nieskończonym przewijaniem gromadziły więcej CLS tylko przez istnienie przez dłuższy czas, nawet jeśli każde pojedyncze przesunięcie było małe i dobrze rozłożone w czasie. Zespół Chrome Speed Metrics przeszedł na maksymalne okno sesji, aby przestać karać czas trwania, i wybrał maksimum zamiast średniej, aby uniknąć wypaczonego wyniku, w którym naprawienie małego, pobocznego przesunięcia mogłoby pogorszyć Twój wynik. Gdy zmiana została wdrożona, żadna domena nie uzyskała gorszego wyniku, większość nie odnotowała zmian, a część stron z wolnym interfejsem i nieskończonym przewijaniem poprawiła się. Jeśli czytasz starszy post, który nadal mówi „suma wszystkich przesunięć”, jest nieaktualny.

Co się liczy — a co nie

Trzy wykluczenia decydują o tym, co faktycznie trafia do Twojego wyniku:

• Poniżej linii zagięcia się nie liczy. Liczone są tylko przesunięcia treści widocznej w bieżącym oknie przeglądarki. Przesunięcie na dole długiej strony, do której użytkownik nigdy nie przewinie, nie ma wpływu. W praktyce oznacza to, że naprawianie przesunięć w widocznym obszarze jest prawie zawsze bardziej opłacalne niż ściganie przesunięć daleko w dół strony.
• Przesunięcia inicjowane przez użytkownika mają 500 ms taryfy ulgowej. “Przesunięcia układu, które występują w ciągu 500 milisekund od wprowadzenia danych przez użytkownika, będą miały ustawioną flagę hadRecentInput, więc mogą być wykluczone z obliczeń.” Stanowisko Google: przesunięcia “które występują w odpowiedzi na interakcje użytkownika… są zazwyczaj w porządku, o ile przesunięcie występuje wystarczająco blisko interakcji, aby związek był jasny dla użytkownika.” Otwórz akordeon, rozwiń menu — taki ruch jest oczekiwany, więc jest wybaczony.
• Ale przewijanie nie jest darmową przepustką. Wykluczenie 500 ms dotyczy tylko dyskretnych zdarzeń — dotknięcia, kliknięcia, naciśnięcia klawisza. Ciągłe gesty (przewijanie, powiększanie palcami) nie uruchamiają okna wykluczenia. Jeśli treść przesuwa się podczas przewijania, to nadal się liczy. To rozróżnienie jest błędne w wielu publikacjach; zrób to dobrze.

Progi i skąd pochodzi wynik

“Aby zapewnić dobrą jakość obsługi, strony powinny dążyć do wyniku CLS na poziomie 0,1 lub mniej,” mierzonego na “75. percentylu ładowań stron, podzielonym na urządzenia mobilne i stacjonarne.” Pełne przedziały:

• Dobrze: ≤ 0,1
• Wymaga poprawy: 0,1 – 0,25
• Słabo: > 0,25

Linia 0,1 nie jest przypadkowa. Badania użytkowników Google wykazały, że “poziomy przesunięcia od 0,15 i wyższe były konsekwentnie postrzegane jako uciążliwe, podczas gdy przesunięcia 0,1 i niższe były zauważalne, ale nie nadmiernie uciążliwe.” Zdecydowano się na 0,1 zamiast czegoś bardziej rygorystycznego częściowo dlatego, że osadzone elementy zewnętrzne (reklamy, media społecznościowe) tak często powodują przesunięcia, że ostrzejszy próg byłby niepraktyczny dla prawdziwej sieci.

Część “75. percentyl danych terenowych” jest kluczowa, co prowadzi nas do największej pułapki pomiarowej.

Laboratorium a pole: dlaczego liczby się różnią

To tutaj większość ludzi się przejeżdża. Lighthouse i inne narzędzia laboratoryjne często podają CLS bliskie 0,0, podczas gdy dane terenowe — i Google — pokazują coś znacznie gorszego. Różnica nie wynika z nieuczciwości narzędzi; to kwestia zakresu. Uruchomienie laboratoryjne to pojedyncze, krótkie, skryptowane ładowanie strony: nie przewija, nie klika i nie zostaje, więc rejestruje tylko przesunięcia przy początkowym ładowaniu. Dane terenowe (CrUX) agregują prawdziwe wizyty wielu użytkowników, urządzeń i nawigacji w ruchomym oknie, a CLS jest definiowane w całym cyklu życia strony — otwieranie menu, leniwe ładowanie treści podczas przewijania, późne wypełnianie reklam, niezależnie od tego, jak długo trwania sesja. Krótkie uruchomienie laboratoryjne strukturalnie nie może zobaczyć większości tego.

Zatem praktyczna zasada jest taka: używaj danych laboratoryjnych do debugowania konkretnego przesunięcia, a danych terenowych do poznania swojego prawdziwego wyniku. Google rankinguje na podstawie terenowych danych z raportu Chrome User Experience Report (CrUX), widocznych w PageSpeed Insights i Search Console. Jeśli Lighthouse pokazuje 0,0, ale PageSpeed Insights pokazuje 0,18, traktuj liczbę terenową jako tę, która odzwierciedla rzeczywistych użytkowników — następnie odtwórz przesunięcie w laboratorium, wchodząc w interakcję ze stroną tak, jak zrobiłby to prawdziwy odwiedzający. Dwie kolejne luki w zakresie warto wiedzieć: większość narzędzi, w tym Lighthouse, nie propaguje przesunięć układu iframe do wyniku dokumentu nadrzędnego, nawet jeśli CrUX może je odzwierciedlać, a RUM oparty na interfejsie Layout Instability API dziedziczy tę samą ślepą plamkę iframe — więc własne monitorowanie rzeczywistych użytkowników może nie wyjaśniać wyniku CrUX, który wygląda gorzej niż to, co pokazuje atrybucja pierwszej strony.

Najczęstsze przyczyny

W przybliżonej kolejności, jak często je widuję:

1. Obrazy i wideo bez wymiarów. Brak zarezerwowanej wysokości oznacza, że wszystko poniżej przeskakuje, gdy multimedia się ładują.
2. Reklamy, elementy osadzone i iframe’y bez zarezerwowanego miejsca. Sieci reklamowe serwują dynamiczne rozmiary; elementy osadzone nie ogłaszają swojej wysokości przed załadowaniem.
3. Dynamicznie wstrzykiwana treść nad istniejącą treścią. Banery cookie, paski powiadomień, widgety “powiązane”, późno ładujące się promocje — wszystko, co wypycha w dół to, co już jest na ekranie.
4. Czcionki internetowe (FOIT/FOUT). Gdy niestandardowa czcionka zastępuje czcionkę zapasową, tekst przeskakuje, jeśli ich metryki się różnią.
5. Animacje na właściwościach wyzwalających układ. Animowanie top, left, margin, box-shadow lub box-sizing zmusza przeglądarkę do ponownego układania strony w każdej klatce.

Rozwiązania

Każde rozwiązanie odpowiada swojej przyczynie:

• Obrazy/wideo — zarezerwuj miejsce. Ustaw atrybuty width i height, aby przeglądarka obliczyła proporcje i utrzymała ramkę; połącz z img { height: auto; width: 100%; } dla zachowania responsywnego lub użyj właściwości CSS aspect-ratio. To pojedyncze rozwiązanie o największym wpływie na CLS na większości stron.
• Reklamy/elementy osadzone/iframe’y — też zarezerwuj miejsce. Użyj min-height lub aspect-ratio na kontenerze; w przypadku slotów reklamowych wytyczne Google Publisher Tag są jednoznaczne: “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” (tłumaczenie) „Ustawienie stałej wysokości i szerokości bezpośrednio na div slotu reklamowego to najskuteczniejszy sposób, aby to osiągnąć.” Dla slotów o wielu rozmiarach zarezerwuj miejsce dla największego skonfigurowanego rozmiaru. Przesuń późno ładujące się treści niżej, aby ewentualne resztkowe przesunięcia były poniżej linii zagięcia.
• Dynamiczna treść — nie wstawiaj do przepływu. Zarezerwuj placeholder, który odpowiada końcowemu rozmiarowi, lub nałóż treść zamiast ją wstrzykiwać. Szkielety ładujące pomagają tylko jeśli dokładnie odpowiadają końcowym wymiarom — szkielet nawet o kilka pikseli krótszy niż rzeczywista treść nadal powoduje przesunięcie. Preferuj ładowanie wyzwalane przez użytkownika (“Załaduj więcej”) zamiast niespodziewanych wstawek.
• Czcionki — dopasuj metryki. font-display: optional to jedyna wartość o praktycznie zerowym ryzyku CLS; swap minimalizuje niewidoczny tekst, ale może powodować przesunięcie przy zamianie. Jeszcze lepiej, użyj CSS-owych nadpisań metryk — size-adjust, ascent-override, descent-override, line-gap-override — aby dopasować czcionkę zapasową do czcionki internetowej, dzięki czemu zamiana będzie płynna. Wstępnie ładuj krytyczne czcionki.
• Animacje — tylko transform. Animuj za pomocą transform (translate, scale, rotate) zamiast top/left/margin. Animacje oparte na transform są kompozytowane i nie wyzwalają układu, więc niczego nie przesuwają.

Jak CLS wpływa na rankingi (zachowaj proporcje)

CLS to jeden z elementów sygnału page experience Google. Google twierdzi, że Core Web Vitals są czymś, czego używają jego systemy rankingowe — ale obecna dokumentacja Search nie publikuje dokładnej wagi CLS, zasady tiebreakera ani gwarancji rankingowej, więc traktuj każdy konkretny mechanizm (w tym “to tiebreaker”) jako robocze przybliżenie, a nie udokumentowany fakt. Moja stała rada we wszystkim, co piszę na temat Core Web Vitals: wejdź w pasmo “dobry” i idź dalej. Większość stron nie zobaczy znaczącego wzrostu rankingów ani biznesu ze schodzenia z 0,08 do 0,02, a pojedynczy wynik rzadko sam w sobie wyjaśnia przychody czy konwersje. CLS to stawka podstawowa — chcesz przekroczyć poprzeczkę, ale nie powinno to stać się centralnym punktem twojego programu SEO kosztem LCP, INP, czy, szczerze mówiąc, twojej rzeczywistej treści.

Dwie praktyczne uwagi, które oszczędzają wiele zamieszania:

• CrUX opóźnia się o ~28 dni. To ruchome okno 28-dniowe, więc poprawka, którą wdrożysz dzisiaj, nie w pełni odzwierciedli się w PageSpeed Insights ani Search Console przez tygodnie. Nie panikuj, gdy liczba nie zmieni się następnego ranka.
• Przypisany element często nie jest pierwotną przyczyną. Interfejs API Layout Shift Attribution mówi Ci, który element się przesunął, ale jak zauważa web.dev, “it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” (tłumaczenie) „Możliwe, że te elementy są tylko pośrednio związane z „pierwotną przyczyną” niestabilności układu.” Tekst, który podskoczył, jest zwykle ofiarą obrazu bez rozmiaru powyżej niego, który ładuje się późno — napraw przyczynę, nie objaw. Pracuj nad tym jako pętla od znacznika czasu do wyzwalacza: zanotuj czas rozpoczęcia przesunięcia, a następnie sprawdź, co jeszcze zmieniło się w tym samym oknie — zakończenie żądania sieciowego, pojawienie się obrazu lub czcionki, zmianę rozmiaru lub zmianę klasy/stylu — i traktuj przypisany węzeł jako trop, a nie dowód, dopóki nie dopasujesz go do tego wyzwalacza.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• CLS = stabilność wizualna, podstawowa metryka internetowa dla nieoczekiwanego ruchu widocznych treści. Jest obok Largest Contentful Paint i Interaction to Next Paint.
• To wynik bezwymiarowy, nie czas. 0,05 to stosunek, nie 50 ms.
• Wzór na przesunięcie: impact fraction × distance fraction — ile części viewportu się przesunęło, razy jak daleko, względem największego wymiaru viewportu.
• Metryka to największe okno sesji (≤ 1 s między przesunięciami, ≤ 5 s całkowite okno) — nie suma całego życia. To zmieniło się w czerwcu 2021, aby przestać karać długo żyjące/strony SPA; wybrano maksimum zamiast średniej.
• Progi (75. percentyl, dane terenowe): Dobry ≤ 0,1 · Wymaga poprawy ≤ 0,25 · Słaby > 0,25.
• Wykluczenia: przesunięcia poniżej linii widoczności nie są liczone; przesunięcia w ciągu 500 ms od dyskretnego wejścia (dotknięcie/kliknięcie/klawisz) są wykluczone — przewijanie nie jest zwolnione.
• Przyczyny: obrazy/wideo/reklamy/iframy/osadzone treści bez rozmiaru; wstrzykiwana treść nad istniejącą; czcionki internetowe; animowanie właściwości wyzwalających układ.
• Poprawki: ustaw width/height lub aspect-ratio; zarezerwuj miejsce na dynamiczne treści (szkielety muszą mieć dokładne wymiary); font-display + size-adjust; animuj tylko za pomocą transform.
• Laboratorium ≠ pole. Lighthouse często pokazuje blisko 0, ponieważ nie wchodzi w interakcję ze stroną ani nie uruchamia pełnego cyklu życia; dane terenowe (CrUX/PageSpeed Insights) są tym, na czym Google opiera ranking. Przesunięcia iframe zwykle nie przenoszą się na wynik rodzica w laboratorium ani w narzędziach RUM.
• Ranking: jedno wejście, które Google mówi, że jego systemy rankingowe używają w ramach doświadczenia strony — brak udokumentowanej wagi lub reguły tiebreakera, więc osiągnij „dobry” i idź dalej, zamiast gonić za konkretnym mechanizmem. CrUX opóźnia się o ~28 dni; przypisany element często nie jest pierwotną przyczyną.

Oficjalna dokumentacja

Dokumentacja źródłowa od Google / zespołu Chrome.

Podstawowe dokumenty CLS

• Skumulowana zmiana układu (CLS) — kanoniczna definicja, wzór wpływ × odległość, okna sesji, progi i wykluczenie hadRecentInput (Milica Mihajlija i Philip Walton).
• Optymalizacja skumulowanej zmiany układu — oficjalny przewodnik przyczyn i poprawek: obrazy, reklamy/osadzone treści, wstrzykiwana treść, czcionki, animacje.
• Debugowanie przesunięć układu — znajdowanie przesunięć w Chrome DevTools, nakładka Layout Shift Regions i interfejs API LayoutShiftAttribution (Katie Hempenius i Barry Pollard).

Tło i pomiar

• Ewolucja skumulowanej zmiany układu w narzędziach internetowych — dlaczego w czerwcu 2021 r. metryka zmieniła się z sumy wszystkich przesunięć na największe okno sesji (Annie Sullivan i Hongbo Song, zespół Chrome Speed Metrics).
• Jak zdefiniowano progi metryk Core Web Vitals — badania użytkowników i dane dotyczące osiągalności stojące za przedziałami 0,1 / 0,25.
• Pierwsze kroki w pomiarze Web Vitals — dane laboratoryjne a dane terenowe oraz dlaczego CLS w laboratorium może być sztucznie niskie.
• Dobre praktyki dotyczące czcionek — font-display, nadpisania metryk i wstępne ładowanie w kontekście CLS związanego z czcionkami.

Reklamy i wyszukiwarka

• Minimalizowanie przesunięcia układu — wskazówki Google Publisher Tag dotyczące rezerwowania miejsca na reklamy.
• Core Web Vitals a wyniki wyszukiwania Google — jak CWV (w tym CLS) wpływają na wyniki wyszukiwania.

Cytaty ze źródła

Oświadczenia na piśmie od Google / zespołu Chrome. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Google — czym jest CLS

• “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” (tłumaczenie) „Skumulowana zmiana układu (CLS) to stabilna metryka Core Web Vitals skoncentrowana na użytkowniku; mierzy stabilność wizualną, określając, jak często użytkownicy doświadczają nieoczekiwanych przesunięć”. Przejdź do cytatu
• “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (tłumaczenie) „CLS mierzy największą serię wyników nieoczekiwanych przesunięć układu występujących w całym cyklu życia strony”. Przejdź do cytatu

Google — wzór

• “layout shift score = impact fraction * distance fraction” (tłumaczenie) „wynik przesunięcia układu = frakcja wpływu × frakcja odległości”. Przejdź do cytatu
• “The impact fraction measures how unstable elements impact the viewport area between two frames.” (tłumaczenie) „Frakcja wpływu mierzy, jak niestabilne elementy oddziałują na obszar widoku między dwiema klatkami”. Przejdź do cytatu
• “The distance fraction is the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).” (tłumaczenie) „Frakcja odległości to największa pozioma lub pionowa odległość przesunięcia niestabilnego elementu w klatce podzielona przez większy wymiar obszaru widoku”. Przejdź do cytatu

Google — okno sesji

• “A burst of layout shifts, known as a session window, is when one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” (tłumaczenie) „Seria przesunięć układu, zwana oknem sesji, występuje wtedy, gdy co najmniej jedno przesunięcie następuje szybko po poprzednim, z odstępem krótszym niż 1 sekunda i maksymalnym czasem okna wynoszącym 5 sekund”. Przejdź do cytatu

Google — progi i dane wejściowe użytkownika

• “To provide a good user experience, sites should strive to have a CLS score of 0.1 or less… a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (tłumaczenie) „Aby zapewnić dobrą wygodę użytkownika, witryny powinny dążyć do wyniku CLS na poziomie 0,1 lub mniej… dobrym progiem do pomiaru jest 75. percentyl ładowań stron, z podziałem na urządzenia mobilne i komputery stacjonarne.” Przejdź do cytatu
• “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” (tłumaczenie) „Przesunięcia układu, które występują w ciągu 500 milisekund od wprowadzenia danych przez użytkownika, będą miały ustawioną flagę hadRecentInput, więc można je wykluczyć z obliczeń.” Przejdź do cytatu
• “Layout shifts that occur in response to user interactions (such as clicking or tapping a link, pressing a button, or typing in a search box) are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.” (tłumaczenie) „Przesunięcia układu występujące w odpowiedzi na interakcje użytkownika (takie jak kliknięcie lub dotknięcie linku, naciśnięcie przycisku czy wpisanie tekstu w polu wyszukiwania) są zazwyczaj w porządku, o ile przesunięcie nastąpi wystarczająco blisko interakcji, aby związek był dla użytkownika jasny.” Przejdź do cytatu

Google — jak wybrano progi

• “levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive.” (tłumaczenie) „poziomy przesunięcia od 0,15 w górę były konsekwentnie postrzegane jako uciążliwe, podczas gdy przesunięcia o 0,1 i mniejsze były zauważalne, ale nie nadmiernie uciążliwe.” Przejdź do cytatu

Google — rezerwowanie miejsca na sloty reklamowe

• “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” (tłumaczenie) „Ustawienie stałej wysokości i szerokości bezpośrednio na div slotu reklamowego to najskuteczniejszy sposób na osiągnięcie tego celu.” Przejdź do cytatu

Google — przypisany element a pierwotna przyczyna

• “elements listed as sources are the elements that shifted during the layout shift. However, it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” (tłumaczenie) „elementy wymienione jako źródła to elementy, które przesunęły się podczas zmiany układu. Możliwe jest jednak, że elementy te są tylko pośrednio powiązane z „pierwotną przyczyną” niestabilności układu.” Przejdź do cytatu

Lista kontrolna: przyczyny CLS → poprawki

Pracuj od góry w dół; pierwsze dwie pozycje naprawiają większość rzeczywistych przypadków CLS.

• Każdy <img> i <video> ma width + height (lub CSS aspect-ratio), z img { height: auto; width: 100%; } dla układów responsywnych.
• Miejsca na reklamy, iframe’y i osadzone treści rezerwują przestrzeń przez min-height / aspect-ratio; miejsca na reklamy o wielu rozmiarach rezerwują dla największego skonfigurowanego rozmiaru.
• Treści ładowane późno znajdują się poniżej linii zagięcia, gdzie to możliwe, aby ewentualne przesunięcia się nie liczyły.
• Wstrzykiwane treści (banery cookie, promocje, widgety “powiązane”) są nakładane lub wstępnie rezerwowane — nie wstawiane nad istniejącymi treściami.
• Placeholdery szkieletowe odpowiadają dokładnym wymiarom końcowej treści (nawet kilka pikseli różnicy powoduje przesunięcie).
• Czcionki internetowe używają font-display: optional, gdzie to akceptowalne, lub swap plus size-adjust / ascent-override, aby dopasować metryki czcionek zastępczych; krytyczne czcionki są wstępnie ładowane.
• Animacje używają wyłącznie transform — nigdy top, left, margin, box-shadow ani box-sizing.
• Sprawdziłeś wynik w danych polowych (PageSpeed Insights / Search Console / CrUX), nie tylko w Lighthouse.
• Odtworzyłeś przesunięcia, wchodząc w interakcję ze stroną — przewijając, otwierając menu, wyzwalając leniwe ładowanie — nie tylko przy początkowym załadowaniu.
• Przesunięcia reklam/iframe’ów zweryfikowane w danych polowych (narzędzia laboratoryjne często nie przenoszą ich do wyniku nadrzędnego).

Ściąga CLS

Liczby

Definicja w jednym zdaniu

• layout shift score = impact fraction × distance fraction — po polsku: wynik przesunięcia układu = frakcja wpływu × frakcja odległości (dla jednego przesunięcia).
• CLS = największe okno sesji przesunięć — ≤ 1 s między przesunięciami, ≤ 5 s całkowite okno. Nie suma całego życia (to było przed czerwcem 2021).
• To wynik bezwymiarowy, nie czas.

Co jest wykluczone

• Przesunięcia poniżej linii zagięcia (poza bieżącym viewportem).
• Przesunięcia w ciągu 500 ms od pojedynczego wejścia (dotknięcie/kliknięcie/naciśnięcie klawisza) — hadRecentInput.
• Nie wykluczone: przesunięcia podczas przewijania lub szczypania (ciągłe gesty).

Przyczyny → poprawki

Pułapki pomiarowe

• Lighthouse (laboratorium) często pokazuje ~0 — nie wchodzi w interakcję ze stroną ani nie uruchamia pełnego cyklu życia. CrUX / PageSpeed Insights (dane polowe) to to, na podstawie czego Google rankinguje.
• CrUX opóźnia się o ~28 dni — poprawki widoczne są dopiero po tygodniach.
• Przesunięcia iframe’ów zwykle nie przenoszą się do wyniku nadrzędnego w narzędziach laboratoryjnych.
• Przypisany element to ten, który się przesunął, niekoniecznie pierwotna przyczyna.

Narzędzia do pomiaru i debugowania CLS

Dane polowe (to, na podstawie czego Google rankinguje)

• PageSpeed Insights — polowe CLS z CrUX na poziomie strony i originu, plus uruchomienie Lighthouse w laboratorium obok. Najszybszy sposób, aby samemu zobaczyć różnicę laboratorium vs pole.
• Search Console — raport Core Web Vitals — polowe CLS dla grup URL w całej witrynie, pogrupowane według statusu.
• CrUX (Chrome User Experience Report) — bazowy zbiór danych polowych; eksploruj historię przez dashboardy CrUX / BigQuery.

Dane laboratoryjne (do debugowania)

• Chrome DevTools — panel Performance — nagraj ślad, a następnie odczytaj ścieżkę Layout Shifts; kliknięcie przesunięcia podświetla elementy, które się przesunęły, i pokazuje wynik przesunięcia. Live Metrics pokazuje CLS aktualizowane w czasie rzeczywistym podczas interakcji.
• Nakładka Layout Shift Regions — DevTools → Ustawienia → Więcej narzędzi → Renderowanie → Layout Shift Regions. Po przeładowaniu przesuwające się obszary migają, więc możesz je zobaczyć.
• Lighthouse — szybkie laboratoryjne CLS, ale pamiętaj, że rejestruje tylko przesunięcia przy początkowym ładowaniu.
• WebPageTest — laboratoryjne CLS z filmem i śladem.

RUM (własne dane terenowe)

• Biblioteka JavaScript web-vitals — onCLS() raportuje CLS rzeczywistych użytkowników z Twoich własnych odwiedzin (~2 KB); najdokładniejszy obraz tego, co ludzie faktycznie doświadczają.
• PerformanceObserver (layout-shift) — surowe API, które biblioteka opakowuje, plus LayoutShiftAttribution sources dla elementów, które się przesunęły.

Jak same narzędzia są oceniane

Żywy przykład metryki opisanej na tej stronie — znane usługi pomiaru szybkości i monitorowania uszeregowane według własnego mobilnego CLS rzeczywistych użytkowników (dane terenowe Chrome UX Report):

Którą poprawkę CLS zastosować najpierw?

Błędy CLS, które ukrywają prawdziwy problem

Traktowanie czystego przebiegu Lighthouse jako dowodu

Lighthouse może zakończyć działanie, zanim pojawi się baner zgody, reklama lub przesunięcie wywołane interakcją. Użyj przebiegu laboratoryjnego do debugowania, ale sprawdź CrUX lub własne monitorowanie rzeczywistych użytkowników, zanim ogłosisz problem rozwiązany.

Naprawianie tylko elementu, który DevTools wskazał jako przesunięty

Przesunięty element jest często ofiarą. Późno ładujący się element nad nim może być przyczyną. Odtwórz ślad i sprawdź, co weszło lub zmieniło rozmiar bezpośrednio przed ruchem.

Rezerwowanie miejsca z odgadniętą stałą wysokością

Stały placeholder może spowodować drugie przesunięcie, gdy responsywna treść jest wyższa lub niższa. Użyj wymiarów wewnętrznych lub aspect-ratio, gdy proporcje treści są znane.

Animowanie właściwości układu

Zmiana top, left lub marginesów może przesuwać otaczającą treść. Animuj za pomocą transform, gdy efekt nie musi zmieniać przepływu dokumentu.

Diagnozuj problem CLS według objawów

Terenowe CLS jest słabe, ale wynik laboratoryjny jest bliski zera

Prawdopodobna przyczyna: przesunięcie występuje po interakcji, podczas dłuższej sesji lub tylko dla podzbioru użytkowników. Poprawka: odtwórz prawdziwą podróż podczas nagrywania panelu Performance, a następnie dodaj atrybucję web-vitals w monitorowaniu rzeczywistych użytkowników. Potwierdzenie: problematyczna interakcja i przesunięty element pojawiają się w śladzie lub rekordzie RUM.

Tekst skacze, gdy pojawia się niestandardowa czcionka

Prawdopodobna przyczyna: czcionka zastępcza i czcionka internetowa mają różne metryki. Poprawka: wstępnie ładuj tylko krytyczną czcionkę, jeśli to właściwe, i dopasuj czcionkę zastępczą za pomocą nadpisań metryk czcionki. Potwierdzenie: odtwórz z wyłączoną pamięcią podręczną i sprawdź, czy ścieżka Layout Shifts nie rejestruje już zamiany.

Baner lub reklama popycha stronę w dół

Prawdopodobna przyczyna: slot nie ma zarezerwowanych wymiarów przed nadejściem treści. Poprawka: przydziel stabilny kontener lub umieść komunikat w miejscu, które nie wypiera widocznej treści. Potwierdzenie: ogranicz przepustowość i obserwuj, czy slot zachowuje swój obszar.

CLS poprawia się w testach, ale nie w PageSpeed Insights

Prawdopodobna przyczyna: CrUX to ruchomy zbiór danych terenowych, a nie natychmiastowa kontrola wdrożenia. Poprawka: najpierw zweryfikuj zmianę w laboratorium i RUM, a następnie poczekaj, aż okno terenowe się obróci. Potwierdzenie: Twoja własna dystrybucja terenowa po wydaniu poprawia się, zanim publiczna agregacja CrUX pójdzie w ślad.

Przechwytywanie przesunięć układu w przeglądarce

Wklej to do konsoli DevTools przed odtworzeniem problemu. Ignoruje przesunięcia związane z niedawnym wprowadzeniem danych przez użytkownika i wypisuje wynik oraz elementy, które przeglądarka przypisała.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.hadRecentInput) continue;
    console.table({
      value: entry.value,
      time: Math.round(entry.startTime),
      elements: entry.sources?.map((source) => source.node),
    });
  }
});

observer.observe({ type: 'layout-shift', buffered: true });

Przypisany węzeł to wskazówka, a nie automatyczny dowód przyczyny. Porównaj jego znacznik czasu z żądaniami sieciowymi, ładowaniem czcionek i wstawieniami DOM w tym samym śladzie.

Udowodnij, że poprawka CLS zadziałała

Test zarezerwowanego miejsca

Test do przeprowadzenia: wyłącz pamięć podręczną, ogranicz przepustowość łącza, przeładuj stronę i zapisz ścieżkę Layout Shifts w panelu Performance. Oczekiwany wynik: multimedia lub osadzony element zachowują ten sam rozmiar przed załadowaniem i po nim. Interpretacja błędu: jego kontener nadal zależy od późno ładowanej treści pod względem wymiarów. Okno monitorowania: natychmiastowe w śladzie. Wyzwalacz wycofania: nowy placeholder powoduje przycinanie, nadmiar pustego miejsca lub nowe przesunięcie w punkcie granicznym responsywnego układu.

Test zamiany czcionek

Test do przeprowadzenia: przeładuj stronę z wyłączoną pamięcią podręczną, obserwując tekst i ścieżkę Layout Shifts. Oczekiwany wynik: przejście z czcionki zastępczej na czcionkę internetową nie powoduje mierzalnego przesunięcia. Interpretacja błędu: metryki czcionki zastępczej nadal się różnią lub krytyczna czcionka dociera zbyt późno. Okno monitorowania: natychmiastowe w powtarzanych testach laboratoryjnych. Wyzwalacz wycofania: zmiana ukrywa tekst na dłużej lub sprawia, że końcowa typografia jest znacząco błędna.

Potwierdzenie w terenie

Test do przeprowadzenia: porównaj dane onCLS() po wdrożeniu dla zmienionego szablonu z jego bazą przed wdrożeniem, a następnie obserwuj CrUX. Oczekiwany wynik: p75 dla rzeczywistych użytkowników poprawia się bez gorszego ogona w kluczowych ścieżkach. Interpretacja błędu: pozostaje inne późne lub interakcyjne źródło. Okno monitorowania: RUM w miarę napływu ruchu; CrUX w swoim 28-dniowym oknie kroczącym. Wyzwalacz wycofania: CLS lub błędy interakcji użytkownika pogarszają się konsekwentnie po wdrożeniu.

Metryki CLS, które warto śledzić

CLS dla rzeczywistych użytkowników na poziomie p75

Metryka: 75. percentyl CLS dla każdego ważnego szablonu i klasy urządzeń. Co mówi: czy większość wizyt osiąga cel stabilności wizualnej. Jak ją pobrać: CrUX, PageSpeed Insights lub RUM z web-vitals. Punkt odniesienia / realistyczny zakres: dobry wynik to 0,1 lub mniej; 0,1–0,25 wymaga poprawy; powyżej 0,25 jest słaby. Częstotliwość: monitoruj wdrożenia w RUM i przeglądaj kroczący trend terenowy co miesiąc.

Wskaźnik słabych wizyt

Metryka: udział rzeczywistych wizyt z CLS powyżej 0,25. Co mówi: czy akceptowalne p75 ukrywa szkodliwy ogon. Jak ją pobrać: pogrupuj zdarzenia onCLS() według szablonu i ścieżki. Punkt odniesienia / realistyczny zakres: ustal bazę witryny i zmniejszaj słaby przedział; mieszanka ruchu sprawia, że uniwersalny cel jest mylący. Częstotliwość: co tydzień dla szablonów o dużym ruchu i po wdrożeniach układu.

Atrybucja przesunięć według przyczyny

Metryka: wpisy przesunięć układu pogrupowane według elementu lub komponentu. Co mówi: która powtarzająca się implementacja odpowiada za najwięcej niestabilności. Jak ją pobrać: wersja atrybucyjna web-vitals lub PerformanceObserver. Punkt odniesienia / realistyczny zakres: brak uniwersalnego zakresu; porównuj komponenty według całkowitego wpływu i dotkniętych wizyt. Częstotliwość: przeglądaj przy każdym wdrożeniu szablonu lub komponentu.

Zasoby warte Twojego czasu

Oficjalnie, szczegółowo

• Skumulowana zmiana układu (CLS) — kanoniczne źródło.
• Optymalizacja skumulowanej zmiany układu — oficjalny przewodnik naprawy.
• Debugowanie przesunięć układu — przepływ pracy w DevTools.
• Ewolucja skumulowanej zmiany układu w narzędziach internetowych — zmiana okna sesji z czerwca 2021 r., wyjaśniona przez zespół, który ją wprowadził.

Od praktyków

• Jak naprawić problemy ze skumulowaną zmianą układu (CLS) — Barry Pollard, Smashing Magazine. Zagłębia się w deskryptory czcionek i problem „element, który się przesunął, nie jest przyczyną źródłową”.
• Skumulowana zmiana układu w praktyce — Nic Jansma (Cloudflare; W3C Web Performance WG). Najlepszy opis niuansów pomiarowych: luki w atrybucji iframe, próbka atrybucji 5 elementów i rozbieżności między narzędziami.
• Pomiar i optymalizacja skumulowanej zmiany układu — DebugBear.
• Prawie kompletny przewodnik po skumulowanej zmianie układu — Jess Peck. Dokładne omówienie przypadków brzegowych, w tym przesunięć podczas nawigacji SPA i niuansów wykluczenia ciągłego gestu.
• Przyczyny przesunięć układu — dokumentacja Chrome DevTools na temat panelu informacji o przyczynach CLS — przydatne uzupełnienie przewodnika debugowania na web.dev.
• Jak naprawić skumulowaną zmianę układu (CLS) — Kinsta. Praktyczny przewodnik skoncentrowany na CMS, obejmujący przyczyny specyficzne dla WordPressa (obrazy w galeriach, późno ładowane widżety, banery cookie).
• Interfejs API niestabilności układu — specyfikacja WICG. Podstawowe API przeglądarki, na którym zbudowany jest CLS; przydatne, jeśli tworzysz własny RUM lub potrzebujesz dokładnej semantyki hadRecentInput.

Gdzie to się wpisuje w moją własną pracę

• CLS pojawia się jako metryka „podstawowa” w moich materiałach o Core Web Vitals — śledź ją, wejdź do dobrego przedziału i trzymaj ją w proporcji do LCP, INP i swojej treści. Google nie publikuje dokładnej wagi CLS ani reguły rozstrzygania remisów, więc to jeden z czynników do obserwowania, a nie gra o wszystko.

Statystyki, które warto cytować

• Próg 0,1 ma podstawy w badaniach percepcji. Badania użytkowników Google wykazały, że przesunięcia 0,15 i wyższe były konsekwentnie postrzegane jako uciążliwe, podczas gdy 0,1 i niższe były zauważalne, ale nie nadmiernie. Źródło
• CLS to najłatwiejsza do zaliczenia metryka Core Web Vitals. W moich audytach korporacyjnych wzorzec jest spójny: zdecydowana większość witryn przekracza próg CLS (często ~80%+), a mimo to tylko nieco ponad połowa zalicza wszystkie trzy metryki jednocześnie — CLS rzadko jest tym, co Cię blokuje.
• Zmiana z czerwca 2021 pomogła, nigdy nie zaszkodziła. Gdy CLS przeszedł na największe okno sesji, żaden origin nie otrzymał gorszego wyniku, większość nie odnotowała zmian, a część stron z nieskończonym przewijaniem i wolnym interfejsem poprawiła się. Źródło
• Media bez określonych wymiarów są nadal wszechobecne. Crawle branżowe (Web Almanac) konsekwentnie znajdują dużą część stron z obrazami bez jawnych wymiarów — to najczęstsza przyczyna CLS i najłatwiejsza do naprawienia.
• 72% witryn na świecie osiąga obecnie dobry CLS (dane Web Almanac / HTTP Archive 2025), co czyni CLS najłatwiejszą do zaliczenia metryką Core Web Vitals — a mimo to 62% stron mobilnych nadal wysyła co najmniej jeden obraz bez jawnych wymiarów, co jest najczęstszą przyczyną. Źródło: HTTP Archive / Web Almanac
• Wpływ na biznes: Rakuten 24 odnotował 53,37% wzrost przychodu na odwiedzającego dla użytkowników z niskim CLS w porównaniu z wysokim CLS — to często cytowane studium przypadku, a nie dowód, że konkretna wartość CLS powoduje określony wynik biznesowy na innych stronach. Źródło: studia przypadków corewebvitals.io

Filmy

• Google Search Central / Chrome dla deweloperów (YouTube) — przewodniki po Core Web Vitals i debugowaniu przesunięć układu, w tym demonstracje DevTools dotyczące ścieżki przesunięć układu i nakładki regionów przesunięcia. Kanał

Sprawdź się: Cumulative Layout Shift

Pięć szybkich pytań na temat mierzenia i naprawiania niestabilności wizualnej. Wybierz odpowiedź na każde pytanie, a następnie sprawdź.

Dziennik zmian