Klient przysłał mi kiedyś zrzut ekranu z Google Search Console z czerwonym paskiem i pytaniem: „czy to znaczy, że mam problem z CLS?”. Nie wiedział, co znaczy skrót, wiedział tylko, że jest czerwony. To dość typowa sytuacja — Google raportuje trzy wskaźniki, których nazwy nikomu nic nie mówią.

Rozkładam je więc na czynniki pierwsze, po ludzku. Core Web Vitals to trzy pomiary tego, jak Twoja strona zachowuje się z perspektywy człowieka, który właśnie ją otworzył: czy szybko coś widzi, czy strona reaguje na kliknięcia i czy nic mu pod palcem nie ucieka.

Skąd Google bierze te liczby

To jest część, którą warto zrozumieć najpierw, bo tłumaczy późniejsze zamieszanie. Istnieją dwa źródła danych. Pierwsze to dane laboratoryjne — pomiar wykonany na żądanie, na symulowanym urządzeniu, na przykład w narzędziu PageSpeed Insights. Drugie to dane od prawdziwych użytkowników Chrome, zbierane przez 28 dni.

Ocena w Search Console opiera się na tym drugim źródle. Dlatego po wprowadzeniu poprawek wynik laboratoryjny zmienia się od razu, a raport w Search Console dopiero po kilku tygodniach. Wielu właścicieli stron uznaje w tym momencie, że optymalizacja nie zadziałała, i to nieporozumienie kosztuje sporo nerwów.

LCP — kiedy widać główną treść

LCP mierzy, po ilu sekundach na ekranie pojawia się największy element widoczny bez przewijania: zwykle zdjęcie w nagłówku, duży napis albo film. To najbliższe temu, co człowiek nazwałby „strona się załadowała”. Google uznaje wynik do 2,5 sekundy za dobry, powyżej 4 sekund za słaby.

Najczęstszy winowajca jest banalny: ogromne zdjęcie w nagłówku, ładowane w oryginalnej rozdzielczości. Drugi to zdjęcie ustawione jako tło przez ustawienia sekcji — przeglądarka odkrywa je dopiero po wczytaniu stylów, więc zaczyna pobierać z opóźnieniem. Trzeci to wolna odpowiedź serwera, kiedy pierwsze pół sekundy schodzi na samo czekanie.

Co z tym robić: zmniejszyć i skompresować grafikę z nagłówka, dać jej priorytet ładowania i nie ukrywać jej w tle sekcji. W praktyce sam ten jeden element potrafi ściągnąć LCP z pięciu sekund do dwóch.

INP — czy strona reaguje na dotyk

INP zastąpił w 2024 roku wcześniejszy wskaźnik FID i mierzy opóźnienie między kliknięciem a widoczną reakcją strony. Klikasz w rozwijane menu i nic się nie dzieje przez pół sekundy — to jest właśnie wysoki INP. Dobry wynik to poniżej 200 milisekund.

Przyczyną prawie zawsze jest nadmiar skryptów, które w tle wykonują swoją pracę i blokują przeglądarkę. Typowy zestaw to kilka narzędzi analitycznych, czat, piksele reklamowe, wtyczka do zgód na ciasteczka i animacje przy przewijaniu. Każde z osobna niewinne, razem — telefon nie nadąża.

Poprawa polega na przeglądzie tego, co naprawdę jest potrzebne, na opóźnieniu ładowania skryptów niekrytycznych do momentu pierwszej interakcji i na rezygnacji z efektów, które nikomu nie służą. To najbardziej „rzeźbiarska” z tych trzech rzeczy, bo wymaga decyzji biznesowych, nie tylko technicznych.

CLS — czy treść ucieka spod palca

CLS mierzy, jak bardzo elementy przesuwają się w trakcie ładowania. Znasz to uczucie: czytasz zdanie, chcesz kliknąć w numer telefonu, a w tej sekundzie doładowuje się baner i klikasz w coś zupełnie innego. Dobry wynik to poniżej 0,1 — to liczba bez jednostki, im mniejsza, tym stabilniej.

Powodów jest zwykle trzy: zdjęcia bez podanych z góry wymiarów, przez co przeglądarka nie rezerwuje na nie miejsca; fonty ładowane z opóźnieniem, przy których tekst najpierw pokazuje się krojem zastępczym, a potem przeskakuje; oraz banery i komunikaty wskakujące nad treść, zamiast nakładać się na nią.

Naprawa jest tu najbardziej wdzięczna, bo to zwykle godzina pracy: uzupełnić wymiary obrazków, ustawić rezerwację miejsca na baner i sprawdzić sposób ładowania fontów. Z całej trójki ten wskaźnik najczęściej udaje się doprowadzić do zieleni w jeden wieczór.

Jak to zmierzyć u siebie

Wystarczą dwa bezpłatne narzędzia i kwadrans. Kolejność jest ważna, bo bez zapisanego punktu wyjścia nie ocenisz później, czy coś pomogło.

  1. Wejdź na PageSpeed Insights i wpisz adres strony. Patrz wyłącznie na zakładkę mobilną — tam Google ocenia najsurowiej i tam siedzi większość Twoich odwiedzających.
  2. Jeśli na górze pojawi się sekcja z danymi od prawdziwych użytkowników, zapisz wartości LCP, INP i CLS. Jeśli jej nie ma, oznacza to po prostu zbyt mały ruch, żeby Google zebrał dane.
  3. Zajrzyj do Google Search Console, do raportu Core Web Vitals, i zobacz, ilu podstron dotyczy problem. Często okazuje się, że jednego szablonu, na przykład wpisów bloga.
  4. Powtórz pomiar dwa tygodnie po wprowadzeniu zmian, a raport w Search Console sprawdź po miesiącu.

Warto trzymać się jednej zasady: poprawiaj jeden wskaźnik naraz i mierz po każdej zmianie. Robienie ośmiu rzeczy jednocześnie kończy się tym, że nie wiadomo, która pomogła, a która zepsuła wygląd na telefonie.

Czy to naprawdę wpływa na pozycje

Wpływa, ale mniej, niż sugerują nagłówki w branżowych serwisach. Core Web Vitals są jednym z wielu sygnałów i nie przebiją strony, która lepiej odpowiada na pytanie użytkownika. Nie obiecuję nikomu awansu w wynikach po samej optymalizacji szybkości.

Jest natomiast druga, pewniejsza korzyść: ludzie po prostu zostają. Strona, która pokazuje treść po dwóch sekundach zamiast po sześciu, ma zauważalnie mniej osób zamykających kartę, zanim cokolwiek zobaczą. Dlatego optymalizację szybkości traktuję jako pracę nad sprzedażą, a nie nad rankingiem — a poprawa wskaźników jest przy okazji.


Jeśli w Search Console świeci Ci się czerwony pasek i nie wiesz, co z nim zrobić — napisz, przetłumaczę to na konkretne zadania. Mierzę LCP, INP i CLS przed zmianami i po nich, poprawiam grafiki, skrypty i stabilność układu; na start potrzebuję adresu strony, dostępu do panelu i, jeśli masz, do Search Console.

Ewelina Grzelak, EWELA design
tel. +48 511 254 321
e-mail: biuro@eweladesign.pl
Zobacz pakiety i ceny

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *