Core Web Vitals nie zaliczone: problemy CLS na TutKit.com i jak je rozwiązaliśmy

Przez blisko trzy miesiące zmagaliśmy się z problemami z CLS na naszym portalu TutKit.com. Poświęciliśmy wiele czasu i energii, aby zidentyfikować i rozwiązać problemy z Cumulative Layout Shifts. W tym raporcie z naszych doświadczeń chcę pokazać ci, jak do tego podeszliśmy.

Wprowadzenie: dlaczego CLS stanowi problem

Cumulative Layout Shift (CLS) to jedna z trzech kluczowych metryk Core Web Vitals Google. Metryki te mają decydujące znaczenie dla oceny przyjazności stron internetowych dla użytkownika i wpływają na ranking w wynikach wyszukiwania. CLS mierzy stabilność wizualną strony i pokazuje, jak często podczas jej ładowania występują nieoczekiwane przesunięcia layoutu.

Co konkretnie oznacza CLS?

Gdy elementy na stronie internetowej nagle zmieniają swoją pozycję podczas ładowania, może to być frustrujące dla użytkowników. Być może znasz to zjawisko, gdy treść strony przeskakuje, ponieważ nagle pojawia się reklama. Zdarza się też, że przycisk, który właśnie chcesz kliknąć, nagle zmienia pozycję i zamiast niego aktywujesz inny link. Takie nieoczekiwane przesunięcia layoutu są uciążliwe i negatywnie wpływają na doświadczenie użytkownika. Aby uniknąć tych problemów i właściwie zoptymalizować stronę, ważne jest, aby mieć wartość CLS na oku i celowo ją poprawiać.

Wartość CLS oblicza się na podstawie rozmiaru przesuniętego elementu oraz dystansu, jaki pokonuje on w obrębie viewportu. Google uznaje wartości CLS poniżej 0,1 za dobre, między 0,1 a 0,25 za wymagające poprawy, a wszystko powyżej za złe.

Oto nasz wykres z Search Console. Na żółto zaznaczone są wartości między 0,1 a 0,25, a na czerwono strony, których wartości wykraczają poza ten zakres.

Klasycznymi przyczynami wysokich wartości CLS na większości stron internetowych są zbyt duże obrazy w przestarzałych formatach graficznych (JPG/PNG) i/lub bez stałych wymiarów. Jeśli obrazy nie mają zdefiniowanej wysokości i szerokości, mogą powodować przesunięcia layoutu. Dzieje się tak, ponieważ przeglądarka podczas ładowania obrazu rezerwuje miejsce na podstawie jego proporcji (szerokość/wysokość). Również dynamiczne treści, takie jak reklamy, pop-upy czy elementy osadzone, które pojawiają się dopiero w trakcie ładowania, powodują kumulatywny skok layoutu. Powolne renderowanie fontów także może wpływać na layout, gdy najpierw ładowany jest font systemowy, a później zastępuje go webfont. Może to prowadzić do przesunięcia tekstu, np. akapit wydłuża się z sześciu do siedmiu wierszy, a treść znajdująca się poniżej przesuwa się w dół. Ponieważ każdy krój pisma ma własny rozmiar znaków, zmiana fontu może prowadzić do zmian łamania wierszy i nieoczekiwanych zmian layoutu.

Chociaż na TutKit.com mieliśmy znakomite wyniki PageSpeed, od połowy grudnia 2024 po prostu nie zaliczaliśmy Core Web Vitals dla większości stron. Wyglądało to wręcz absurdalnie: mobilny wynik PageSpeed na poziomie 95 czy 97, a Core Web Vitals niezaliczone. Problemem był CLS. Ponieważ CLS uwzględnia nie tylko pierwszy viewport, lecz także interakcje w obrębie strony, przyczynę trudno było zidentyfikować. W tym raporcie dzielimy się z tobą naszymi doświadczeniami, jak rozpoznaliśmy problemy i skutecznie je rozwiązaliśmy.

Analiza przyczyn: dlaczego CLS wystąpił u nas?

W minionych tygodniach kilku ekspertów SEO, których obserwuję na LinkedIn, informowało o nagłych ostrzeżeniach dotyczących CLS, wykazywanych w Google Search Console od grudnia 2024 i stycznia 2025. Może to mieć związek z Core Update z grudnia 2024, które Google wdrożył w połowie grudnia. Strony internetowe, które wcześniej miały zielone wartości CLS, nagle zostały sklasyfikowane jako problematyczne, tak jak właśnie nasza.

Możliwą przyczyną jest zmiana w systemie oceny sygnałów użytkowników Google. Istnieją przesłanki, że interakcje w obrębie stron są silniej uwzględniane w ocenie. W efekcie wartości Core Web Vitals mogą się pogorszyć nawet bez zmian technicznych. To, co wcześniej było w porządku, teraz powodowało problemy. A u nas, ze względu na mnogość różnych typów stron, sekcji i funkcji, obszarów wywołujących problemy z CLS było nieco więcej:

• Google AdSense: opóźnione ładowanie reklam prowadziło do przesunięć.
• Spisy treści: dynamiczne doładowywanie przez JavaScript powodowało skoki layoutu.
• Obrazy bez atrybutów width/height: nagle pojawiające się obrazy zmieniały strukturę strony.
• Webfonty: późniejsze ładowanie fontów prowadziło do nieoczekiwanych zmian łamania tekstu.
• Moduły FAQ: domyślnie otwarte pytania powodowały nieprzewidywalne przesunięcia layoutu.
• Slidery & taby akordeonowe: treści były renderowane z opóźnieniem i ulegały przesunięciu.
• Google Reviews: treści doładowywane z zewnątrz wpływały na strukturę strony.

Problemy te nie były łatwe do wykrycia, ponieważ testy laboratoryjne, takie jak Lighthouse i PageSpeed Insights, nie wykazywały podejrzanych wartości CLS.

Trudna droga do wykrycia ukrytych przesunięć layoutu

Dlaczego problemy z CLS były tak trudne do zidentyfikowania?

1. Lighthouse i PageSpeed Insights pokazywały optymalne wartości, ponieważ mierzą tylko pierwsze ładowanie strony i nie symulują rzeczywistych scenariuszy użytkowania. Testują stronę w środowisku laboratoryjnym ze stabilną siecią i idealnymi warunkami ładowania. W efekcie wiele przesunięć layoutu, które występują podczas rzeczywistych interakcji, pozostaje niewykrytych.
2. Google Search Console wykazywała CLS jako problem, ponieważ analizuje rzeczywiste dane użytkowników (Field Data). Dane te pochodzą od prawdziwych użytkowników korzystających z różnych urządzeń, sieci i wzorców użytkowania, dzięki czemu ujawniły się problemy, które nie występowały w testach laboratoryjnych.
3. CrUX API i BigQuery nie oferowały danych w czasie rzeczywistym, lecz zagregowane wartości z ostatnich 28 dni. Oznacza to, że poprawki stają się widoczne dopiero z opóźnieniem, a natychmiastowa ewaluacja nie była możliwa.

W Search Console wskazane zostały typy adresów URL z problemami CLS, co było pierwszą dobrą wskazówką co do przyczyn niezaliczenia Core Web Vitals, mimo że przy zwykłym sprawdzaniu przez PageSpeed Insights czy Lighthouse nie dało się stwierdzić zbyt wysokich wartości CLS. Musieliśmy znaleźć własną metodę, aby uwidocznić błędy CLS.

Analiza za pomocą Chrome DevTools → zakładka Performance

Cała witryna, z każdym typem strony, była przeładowywana sekcja po sekcji i badana pod kątem przesunięć layoutu. Nie używaliśmy do tego Lighthouse ani PageSpeed, lecz zakładki Performance w Chrome DevTools.

Szczególnie problematyczne elementy były oznaczane i wielokrotnie testowane z różnymi ustawieniami throttlingu. Dzięki sztucznemu ograniczeniu prędkości internetu do Slow 4G mogliśmy lepiej symulować opóźnienia w ładowaniu poszczególnych elementów i odtwarzać przesunięcia layoutu. Tutaj na obrazku widzimy layout shift, który stał się widoczny przy throttlingu sieci i CPU:

Protokołowaliśmy wszystkie problemy z CLS i dzięki temu mogliśmy zidentyfikować problematyczne elementy witryny. W naszych testach uwzględniliśmy nie tylko typy stron problematyczne według Search Console, lecz wszystkie typy stron ze wszystkimi sekcjami podstron, aby rozwiązać temat także w sposób trwały, na wypadek gdyby w przyszłości wymagania wobec operatorów stron zostały jeszcze zaostrzone.

Wszystkie proste i szybkie testy można przeprowadzać za pomocą DevTools → Performance i przeładowywania strony klawiszem F5 w różnych miejscach, albo poprzez mocniejszy i bardziej intensywny test z użyciem nagrywania wydajności (Performance-Recording).

Niektóre przesunięcia layoutu są niemal niemożliwe do zauważenia podczas zwykłych testów. Może się zdarzyć, że typ strony A nie zawiera żadnych przesunięć layoutu i typ strony B również nie wykazuje żadnych przesunięć. Dopiero przełączanie się między obiema stronami podczas nawigacji wprzód i wstecz ujawniło problem CLS, którego nie dało się zidentyfikować przy izolowanym sprawdzaniu poszczególnych stron.

Dlatego zawsze testuj kompletne ścieżki użytkownika, a nie tylko izolowane strony, aby zidentyfikować ukryte przesunięcia layoutu. Analiza rzeczywistego zachowania użytkowników często ujawnia błędy, które umykają standardowym testom. W ten sposób można wcześnie rozpoznać potencjalne problemy i utrzymać stabilną wydajność.

Testy z różnymi rozdzielczościami ekranu:

Domyślnie Lighthouse i PageSpeed Insights testują ze stałym rozmiarem ekranu. W Google Search Console na podstawie wskazanych problematycznych typów adresów URL stwierdziliśmy, że niektóre problemy z CLS występowały tylko u określonych grup użytkowników, np. odwiedzających ze Szwecji korzystających z określonych urządzeń mobilnych.

Dodatkowo przeprowadziliśmy testy mobilne z różnymi rozdzielczościami, aby zidentyfikować specyficzne problemy występujące w rzeczywistych scenariuszach użytkowania. W tym celu wyeksportowaliśmy dane z Google Analytics i wykonaliśmy testy dla 200 różnych rozdzielczości mobilnych, aby wykryć problemy, które ujawniały się tylko przy określonej rozdzielczości. Aby dać wyobrażenie, jak szeroki jest zakres rozdzielczości, z jakimi użytkownicy poruszają się po stronie: plik eksportu z Google Analytics wykazał dla okresu czterech tygodni 4083 różne rozdzielczości dla desktopu, tabletu i urządzeń mobilnych. Posortowaliśmy je według liczby użytkowników. Nawet na 200. miejscu wśród rozdzielczości mieliśmy jeszcze 88 użytkowników, którzy w tym czterotygodniowym okresie odwiedzali nas z rozdzielczością 412×778.

Google niedawno dodał narzędzie, które pozwala dostosować throttling twojego komputera PC lub notebooka do różnych urządzeń mobilnych.

To systematyczne podejście pomogło nam zidentyfikować dokładne miejsca problemów i wdrożyć ukierunkowane poprawki. Ważne jest zrozumienie, że określone problemy z CLS powstają tylko w specyficznych warunkach, ale mogą podważyć ocenę całej strony.

Nasze rozwiązania zidentyfikowanych problemów z CLS

Po ustaleniu przyczyn przesunięć layoutu wdrożyliśmy ukierunkowane działania, aby je usunąć:

Określenie wymiarów obrazów

Problem: obrazy bez zdefiniowanej szerokości i wysokości prowadziły do nieoczekiwanych zmian layoutu.

Tutaj widzisz na przykład mobilny wynik PageSpeed z wydajnością 92 bez zauważalnych problemów z CLS. Dzięki naszym testom w DevTools w zakładce Performance zidentyfikowaliśmy jednak problem w rzeczywistym zachowaniu użytkowników. Wartość CLS wynosiła 0,22 … zdecydowanie za wysoko.

Rozwiązanie: w części obrazów wciąż brakowało atrybutów width i height. Stworzyliśmy zapytanie obejmujące wszystkie obrazy portalu i automatycznie dodaliśmy te atrybuty do kodu. Frontend wie teraz już podczas ładowania, jaki rozmiar ma obraz, i z góry rezerwuje w layoucie potrzebne miejsce odpowiadające właściwym proporcjom obrazu. Dzięki temu przy ładowaniu obrazu nie występuje żaden skok. Miły efekt uboczny: poprawił się dzięki temu również mobilny wynik PageSpeed.

Oto ten sam adres URL po zmergowaniu naszej poprawki CLS, w identycznym teście z PageSpeed Insights i DevTools:

Optymalizacja webfontów

Problem: późne ładowanie fontów prowadziło do zmian łamania tekstu i przesunięć layoutu. U nas występował w szczególności problem polegający na tym, że najpierw ładowany był systemowy font domyślny (tutaj: Arial), a dopiero potem font Noto jako webfont. W naszym portalu używamy webfontu Noto. Google zlecił zaprojektowanie tego fontu tak, aby obsługiwał wszystkie istniejące systemy pisma, od znaków łacińskich przez cyrylicę i pismo arabskie aż po bardziej egzotyczne zestawy znaków, jak khmerski czy tamilski. Właśnie to czyni ten krój pisma idealnym dla wielojęzycznej platformy takiej jak TutKit.com, na której udostępniane są treści dla najróżniejszych grup odbiorców. Dużą zaletą Noto jest jego szerokie wsparcie językowe – ale dokładnie to stało się też wyzwaniem technicznym. Ponieważ Noto obejmuje tak wiele systemów pisma, rodzina fontów jest ogromnie obszerna.

Domyślnie często ładowanych jest więcej znaków, niż faktycznie potrzeba. Szczególnie u użytkowników mobilnych może to prowadzić do dłuższych czasów ładowania, co negatywnie wpływa na user experience i SEO.

Rozwiązanie: sprawdziliśmy, które grubości fontu od 100 do 900 są ładowane, i porównaliśmy to z rzeczywistymi potrzebami interfejsu użytkownika, dzięki czemu mogliśmy zredukować liczbę różnych grubości. Z drugiej strony pliki fontów zostały ograniczone do faktycznie niezbędnych znaków. Ładowane były już tylko dwa pliki fontów o łącznym rozmiarze 105 kB.

Dla poszczególnych języków przestaliśmy też stosować całe pliki fontów, a jedynie subsety fontów. Po otwarciu naszego przełącznika języków ładowane są nowe języki ze znakami specjalnymi z języków nordyckich i słowiańskich; ładowane są zestawy znaków dla greki, cyrylicy, japońskiego i koreańskiego. Subsety, z dwoma wyjątkami, mają wyjątkowo małe rozmiary plików.

Dzięki temu mogliśmy skrócić czas ładowania i zapewnić, że teksty od samego początku są wyświetlane poprawnie, bez widocznej zamiany fontu systemowego na webfont.

Pozostałe poprawki w ramach naprawiania CLS

Ponadto zajęliśmy się też bezpośrednio pozostałymi problemami z CLS, które zidentyfikowaliśmy. Wśród nich na przykład:

Optymalizacja Google AdSense

Problem: opóźnione ładowanie reklam prowadziło do przesunięć layoutu.
Rozwiązanie: dostosowanie ustawień AdSense tak, aby używać statycznych placeholderów, które rezerwują potrzebne miejsce już podczas ładowania strony.

Przestawienie spisów treści z JavaScript na PHP

Problem: dynamiczne doładowywanie przez JavaScript powodowało skoki layoutu.
Rozwiązanie: renderowanie spisów treści w artykułach blogowych po stronie serwera w PHP, aby zapewnić ich dostępność natychmiast przy ładowaniu strony i wykluczyć późniejsze przesunięcia.

Dostosowanie modułów FAQ

Problem: domyślnie otwarte pytania powodowały nieprzewidywalne przesunięcia layoutu.
Rozwiązanie: usunięcie funkcji domyślnego otwierania pytań, aby uniknąć nieoczekiwanych zmian layoutu.

Optymalizacja elementów typu slider i accordion

Problem: treści były renderowane dopiero z opóźnieniem, co prowadziło do przesunięć layoutu.
Rozwiązanie: wstępne ładowanie elementów i określenie stałych wysokości dla sliderów, aby zagwarantować stabilny layout podczas ładowania.

Poprawa sposobu osadzenia Google Reviews

Problem: treści doładowywane z zewnątrz wpływały na strukturę strony i prowadziły do przesunięć layoutu.
Rozwiązanie: zastosowanie lazy loadingu ze stałymi placeholderami, aby zapewnić rezerwację potrzebnego miejsca już podczas ładowania strony.

Ponieważ nie dokumentowałem każdej poprawki osobnymi obrazami, oto wyciąg z JIRA, naszego narzędzia do zarządzania projektami, w którym wyświetlone są przefiltrowane zadania związane z CLS.

Początkowo tworzyliśmy jeszcze osobny ticket dla każdej nieprawidłowości i po zmergowaniu uruchamialiśmy walidację w Search Console. Ale to nie wystarczyło, bo z jednej strony walidacja kończyła się niepowodzeniem, a z drugiej w kolejnym kroku identyfikowane były następne problemy, więc ostatecznie zebraliśmy problemy CLS w trzech ticketach (List of CLS problems), aż wszystkie zostały naprawione. Problemów okazało się więcej, niż się spodziewaliśmy. Już sama liczba ticketów i rozpiętość ich numerów pokazuje, jak długo i intensywnie zajmowały nas problemy z CLS. Podczas gdy portal informacyjny Heise mógł rozwiązać swoje problemy z CLS jedną jedyną linijką kodu – spowodowane przez baner zgody na cookies – u nas było to kilka linijek kodu więcej, które musieliśmy przerobić.

Po wdrożeniu ostatnich działań stwierdziliśmy, że poprawa nie była od razu widoczna w Google Search Console. Czas procesu walidacji określono na maksymalnie 28 dni. Wynika to z faktu, że Search Console opiera się na rzeczywistych danych użytkowników, agregowanych w okresie 28 dni. Dlatego może minąć do czterech tygodni, zanim skutki zmian zostaną w pełni odzwierciedlone. W naszym przypadku pierwsze poprawy były widoczne po dziewięciu dniach.

Czy odrobiłeś swoją pracę domową?

Jeden z ekspertów SEO, który opowiadał na LinkedIn o swoich problemach z CLS, wyraził uznanie dla wszystkich zespołów, które spełniają Core Web Vitals w swoich projektach: Podziwiam wszystkie zespoły, które spełniają Core Web Vitals! Bo mnie samemu się to nie udaje…

To uznanie jest uzasadnione, ponieważ spełnienie Core Web Vitals w przypadku rozbudowanych witryn wymaga silnego skupienia na technice, PageSpeed i user experience. Kiedy opisuję tutaj, jak rozwiązaliśmy u siebie problemy z CLS, ze względu na liczbę znalezionych miejsc mogłoby powstać wrażenie, że u nas i tak już niektóre aspekty techniczne szwankowały. Ale tak wcale nie było. Wraz z wdrożeniem naszej wielojęzyczności stanęliśmy przed wieloma nowymi wyzwaniami i dlatego poświęciliśmy wiele miesięcy na refactoring CSS i JS, redukcję zapytań do bazy danych oraz dalsze usprawnienia PageSpeed, takie jak optymalizacja TTFB. Dziś PageSpeed Insights pokazuje dla naszej strony głównej mobilny wynik PageSpeed na poziomie 95. W raporcie pozostało tylko kilka zaleceń wskazujących na dalszy potencjał poprawy.

A tutaj podstrona, która jeszcze niedawno również miała problemy z CLS. Zwróć uwagę na nieliczne zalecenia, które wyświetla nam PageSpeed Insights. Drugi punkt dotyczący elementów graficznych nie odnosi się nawet do głównego obrazu strony, lecz do dwóch strzałek pełniących funkcję elementów nawigacyjnych. (Dobrze, że napisałem ten artykuł. Od razu założyłem ticket, abyśmy uzupełnili także te atrybuty i frontend jeszcze szybciej wiedział, jaki rozmiar jest dla nich przewidziany.)

Mimo tego i tak już czystego fundamentu TutKit.com pojawiły się problemy z CLS. A naszym szczęściem było to, że pracę domową w zakresie standardów optymalizacji PageSpeed odrobiliśmy w większości już w roku 2024. U eksperta SEO z LinkedIn, który szczerze przyznał się do własnych problemów z Core Web Vitals, sprawa wygląda inaczej. Sprawdziłem jego stronę. Już same pliki fontów ładowane przy wejściu na stronę są ogromne. W porównaniu z TutKit.com ładowana jest tu wielokrotność plików i rozmiarów, mimo że strona główna jest mniejsza od naszej. Zobacz tutaj:

Rzeczywiście z naszego doświadczenia wynika, że problemy z PageSpeed i CLS często idą w parze z nieoptymalną polityką fontów.

Gdy strona jest testowana w PageSpeed Insights, wyniki są katastrofalne. Lista zaleceń Google jest odpowiednio długa (na obrazku po prawej):

Na tej stronie z technicznego, wydajnościowego punktu widzenia rzeczywiście sporo szwankuje. W testach, które wyrywkowo przeprowadziłem według naszego systemu weryfikacji, problemy z CLS występowały w kilku miejscach podstron. A na koniec wyskoczył baner, który powoduje dodatkowy layout shift.

Nawet jeśli deweloperzy zajmą się problemami z CLS w izolacji, nie unikną konieczności wdrożenia także tutaj standardów nowoczesnych stron internetowych, tzn. rozwiązania problemów z fontami, postawienia na nowoczesne formaty obrazów, takie jak Avif, refaktoryzacji plików CSS i JS, konsekwentnego ładowania niżej położonych obrazów przez lazy loading itd. Bo bez tych optymalizacji wydajności o charakterze fundamentalnym szybka poprawka CLS nie wystarczy albo nie będzie trwała.

Ile zaleceń wciąż otrzymujesz od PageSpeed Insights? Czy odrobiłeś już swoją pracę domową?

Dygresja: PageSpeed 100, a mimo to Core Web Vitals niezaliczone

Każdy w Niemczech zna Karrierebibel z dobrymi poradami dotyczącymi aplikowania o pracę i życia zawodowego. W zeszłym roku przeprowadzono tam relaunch, który, moim zdaniem, miał też skłonić do wprowadzenia optymalizacji technicznych. I rzeczywiście znajduję wybitnie dobre wyniki PageSpeed: strona główna osiąga 99 dla urządzeń mobilnych i 100 dla komputerów. Szacunek.

Z perspektywy designu do dziś nie mogę się jednak przekonać do ich firmowego kroju pisma: Arial. To zupełnie nie to. Od razu przypomina mi urzędową korespondencję. Ale Karrierebibel ma dzięki temu przewagę techniczną. Nie są ładowane żadne pliki fontów. Strona po prostu deklaruje w kodzie źródłowym, że fontem jest Arial. Ponieważ jest on i tak preinstalowany w każdym systemie w Niemczech, strona nie traci czasu na ładowanie plików fontów. W ten sposób witryna od razu omija jedną z przyczyn problemów z PageSpeed: ładowanie fontów.

Ale: PageSpeed i CLS należy zawsze rozpatrywać całościowo, dlatego ważne jest, aby systematycznie uwzględniać także różne rozdzielczości. CrUX-Board dla desktopu pokazuje mnóstwo problemów z CLS w widokach desktopowych.

Gdy zlecam test podstrony w PageSpeed Insights, dla komputerów otrzymuję PageSpeed 100, ale Core Web Vitals nie zostają zaliczone. To także jest możliwe, jak możesz stwierdzić na tym przykładzie.

Używaj więc różnych narzędzi weryfikacyjnych, aby znaleźć błędy, które obecnie sprawiają, że nie spełniasz ważnych metryk. Bo nie zaliczając Core Web Vitals, tracisz również ważny sygnał rankingowy dla Google. Być może istnieje związek między niespełnianiem określonych sygnałów rankingowych i metryk pomiarowych a spadkiem widoczności online w Google. Na obrazku widać, jak w ciągu roku widoczność spadła z poziomu ponad 64 do przedziału trzydziestu kilku. Przy czym przyczyn z pewnością nie należy szukać wyłącznie w Core Web Vitals. Ale zawsze lepiej mieć swoją pracę domową odrobioną w całości. Na zewnętrzne uwarunkowania nie mamy wpływu. Ale na to, co dzieje się na własnej stronie, już tak.

Podsumowanie: nasze wnioski

Rozpatrywanie CLS w izolacji jest możliwe, jeśli wcześniej przeprowadzono już optymalizacje pod kątem wysokiego PageSpeed. Mimo to wpływ pozostaje ogromny, gdy z powodu problemów z CLS Core Web Vitals nie zostają zaliczone.

Skala skutków, jakie może mieć niezaliczenie Core Web Vitals, staje się jasna, gdy przyjrzymy się następującej zależności. Na CrUX-Board dla naszego portalu wyraźnie widać, jak od października 2024 przy użyciu mobilnym kumulowały się narastające problemy z CLS. Obraz pokazuje wyłącznie wartości CLS dla urządzeń typu Phone.

Tutaj przedstawiony jest podział na Phone, Desktop i Tablet, pokazujący, jak rozkłada się użytkowanie TutKit.com:

Nie jest tak, że pozyskaliśmy więcej użytkowników desktopowych. Nie, po prostu straciliśmy część naszych użytkowników mobilnych. Dziennie była to pięciocyfrowa liczba kliknięć. Szczerze mówiąc, to naprawdę boli. Teraz w końcu rozwiązaliśmy problemy z CWV i Search Console pokazuje dla adresów URL wyłącznie dobre wartości:

Dlatego jesteśmy bardzo ciekawi, czy kliknięcia teraz się odbudują i czy odnotujemy w Search Console przyrost użytkowania mobilnego. Za kilka miesięcy opublikuję aktualizację tego wpisu.

Ostatnie zmiany pokazują, że optymalizacja CLS pozostaje wymagającym zadaniem. Nasze najważniejsze wnioski to:

• Uwzględniaj problemy z CLS wcześnie, już na etapie developmentu
• Dane laboratoryjne nie wystarczą – decydujące są rzeczywiste dane użytkowników
• CLS ma ogromny wpływ na Core Web Vitals jako sygnał rankingowy, a tym samym na widoczność w Google

W dłuższej perspektywie systematyczne podejście pomaga trwale minimalizować problemy z CLS i zapewnić optymalne doświadczenie użytkownika, bo to również należy do SEO.

Jeśli masz problemy z CLS w szczególności lub z wydajnością w ogóle, śmiało odezwij się do nas. Wypracowaliśmy w tym zakresie głębokie zrozumienie tematu i z pewnością możemy ci pomóc.