Core Web Vitals: LCP, INP i CLS — co mierzą i jak poprawiać właściwy problem?

Core Web Vitals nie jest jednym wynikiem szybkości. To trzy wskaźniki opisujące różne części doświadczenia: kiedy pojawia się główna treść, jak szybko strona reaguje na interakcję i czy układ nie przesuwa się podczas korzystania. Zielony wynik jednego nie równoważy czerwonego drugiego.

Krótka odpowiedź: LCP mierzy czas pojawienia się największego istotnego elementu treści i powinien wynosić najwyżej 2,5 s. INP ocenia opóźnienie interakcji w trakcie wizyty i powinien wynosić najwyżej 200 ms. CLS mierzy nieoczekiwane przesunięcia układu i powinien być nie większy niż 0,1. Ocena dotyczy 75. percentyla rzeczywistych wizyt, osobno dla urządzeń mobilnych i komputerów. Najpierw ustal słaby wskaźnik oraz odpowiadający mu element lub interakcję, dopiero potem optymalizuj.

Dlaczego są trzy wskaźniki?

Strona może szybko wyświetlić nagłówek, ale przez kilka sekund nie reagować na kliknięcie. Może też działać płynnie, a przy ładowaniu reklamy przesunąć przycisk pod palcem. Jeden pomiar nie opisuje tych problemów naraz.

Aktualny zestaw stabilnych Core Web Vitals obejmuje:

Progi należy sprawdzić ponownie przed publikacją lub audytem długoterminowym, ponieważ metryki mogą ewoluować.

LCP: kiedy widać główną treść?

Largest Contentful Paint mierzy czas renderowania największego kwalifikującego się obrazu, fragmentu tekstu albo innego elementu treści widocznego w obszarze ekranu. Na stronie firmowej elementem LCP często jest zdjęcie hero, duży nagłówek lub baner.

LCP składa się z kilku etapów:

• czasu do pierwszego bajtu dokumentu;
• opóźnienia odkrycia zasobu;
• czasu pobierania obrazu lub fontu;
• opóźnienia renderowania po pobraniu.

Dlatego samo skompresowanie obrazu może nie wystarczyć. Jeśli plik zostaje odkryty dopiero przez skrypt, serwer długo generuje HTML albo arkusz CSS blokuje renderowanie, trzeba poprawić właściwy etap.

Typowe przyczyny słabego LCP

• wolna odpowiedź serwera;
• duży obraz bez wariantów responsywnych;
• lazy loading obrazu widocznego od razu;
• zasób LCP dodawany dopiero przez JavaScript;
• blokujący CSS lub font;
• niepotrzebne przekierowania;
• brak cache dla powtarzalnych wizyt.

Najpierw w narzędziach deweloperskich wskaż konkretny element LCP. Optymalizacja „wszystkich obrazów” bez tej wiedzy może ominąć najważniejszy zasób.

INP: jak szybko strona odpowiada na działanie?

Interaction to Next Paint obserwuje interakcje kliknięcia, dotknięcia i klawiatury w trakcie wizyty. Mierzy czas od działania użytkownika do następnego odmalowania, z uwzględnieniem oczekiwania, wykonania procedur i prezentacji kolejnej klatki.

INP nie jest czasem ładowania strony. Może pogorszyć się dopiero po otwarciu menu, filtra, formularza albo widżetu. W przeciwieństwie do dawnego FID bierze pod uwagę interakcje w całym cyklu życia strony, a nie tylko pierwsze wejście.

Typowe przyczyny słabego INP

• długie zadania JavaScript blokujące główny wątek;
• wiele skryptów analitycznych i marketingowych;
• ciężka obsługa kliknięcia;
• jednoczesne renderowanie dużej części interfejsu;
• kosztowne przeliczanie stylów i układu;
• zbyt dużo pracy wykonywanej synchronicznie;
• skrypty zewnętrzne, nad którymi strona ma ograniczoną kontrolę.

Naprawa polega na znalezieniu konkretnej wolnej interakcji, podziale długich zadań, ograniczeniu pracy i szybszym pokazaniu informacji zwrotnej. Sam cache HTML zwykle nie naprawi blokowania w przeglądarce.

CLS: czy elementy pozostają na miejscu?

Cumulative Layout Shift ocenia nieoczekiwane przesunięcia widocznych elementów. Przykład: użytkownik chce kliknąć „Kontakt”, ale nad przyciskiem ładuje się obraz i przesuwa go w dół.

CLS nie jest wyrażony w sekundach. Wartość wynika z wielkości oraz odległości przesuniętych obszarów w ramach okien sesji. Przesunięcia oczekiwane bezpośrednio po interakcji użytkownika są traktowane inaczej niż samoczynne skoki układu.

Typowe przyczyny słabego CLS

• obrazy i filmy bez zarezerwowanych wymiarów;
• osadzone mapy lub iframe'y bez stałej przestrzeni;
• banery zgód i komunikaty wstawiane nad treścią;
• reklamy bez określonego miejsca;
• zamiana fontu zmieniająca wymiary tekstu;
• treści dołączane asynchronicznie nad aktualnym widokiem;
• animowanie właściwości wpływających na układ.

Najprostszą ochroną jest rezerwowanie miejsca za pomocą wymiarów lub aspect-ratio. Nie oznacza to sztywnej szerokości na każdym ekranie — proporcje mogą pozostać responsywne.

Co oznacza 75. percentyl?

Dobry wynik powinien obejmować co najmniej 75% wizyt w analizowanej grupie. Nie chodzi o średnią ani o najlepszy test wykonany na szybkim laptopie. Segmentacja mobile i desktop zapobiega ukrywaniu problemów użytkowników telefonów za dobrymi wynikami komputerów.

Przykładowo LCP 2,4 s w 75. percentylu oznacza, że trzy czwarte uwzględnionych wizyt osiągnęło wynik nie gorszy niż 2,4 s. Pozostała część mogła mieć doświadczenie wolniejsze.

Dane terenowe i laboratoryjne

Dane terenowe pochodzą z realnych wizyt. Uwzględniają różne telefony, sieci, lokalizacje i zachowania. To one najlepiej opisują doświadczenie odbiorców, ale wymagają ruchu i są historyczne.

Dane laboratoryjne powstają w kontrolowanym teście. Są świetne do diagnozy i porównania przed wdrożeniem oraz po nim, lecz pojedyncza symulacja nie zastępuje użytkowników.

INP szczególnie pokazuje tę różnicę. Lighthouse bez rzeczywistego użytkownika nie może zmierzyć pełnego INP; wykorzystuje laboratoryjne wskaźniki pomocnicze, takie jak Total Blocking Time.

Czy Core Web Vitals wpływają na SEO?

Google wykorzystuje Core Web Vitals w swoich systemach oceny doświadczenia strony, ale dobry wynik nie gwarantuje wysokiej pozycji. Trafność treści i wiele innych sygnałów pozostają istotne. Nie należy usuwać wartościowego tekstu albo funkcji tylko po to, by zdobyć kilka punktów w narzędziu.

Traktuj wskaźniki przede wszystkim jako wspólny język jakości. Wolna lub skacząca strona utrudnia kontakt z firmą niezależnie od algorytmu.

Proces optymalizacji bez zgadywania

1. Zbierz dane terenowe dla wzorców stron, nie tylko strony głównej.
2. Rozdziel urządzenia mobilne i komputery.
3. Wskaż najsłabszy z trzech wskaźników.
4. Znajdź element LCP, wolną interakcję albo źródło przesunięcia.
5. Zmierz etapy składające się na problem.
6. Wprowadź jedną grupę zmian na stagingu.
7. Porównaj serię testów laboratoryjnych.
8. Wdróż i obserwuj własny monitoring użytkowników.
9. Poczekaj na odświeżenie okna danych terenowych.

Nie optymalizuj wyłącznie jednego URL-a, jeśli witryna ma artykuły, ofertę i formularz z innymi szablonami.

Najczęstsze błędy

• utożsamianie wyniku Lighthouse z Core Web Vitals wszystkich użytkowników;
• pogoń za wynikiem 100 zamiast usunięcia realnej przeszkody;
• lazy loading obrazu LCP;
• usuwanie wszystkich skryptów bez oceny ich funkcji biznesowej;
• testowanie tylko szybkiego komputera;
• ocena na podstawie jednego uruchomienia;
• brak monitoringu po aktualizacji motywu i wtyczek;
• oczekiwanie, że dane z 28 dni zmienią się natychmiast.

Podsumowanie

LCP, INP i CLS odpowiadają na trzy osobne pytania: kiedy pojawia się główna treść, kiedy strona odpowiada i czy interfejs pozostaje stabilny. Dobra optymalizacja zaczyna się od danych rzeczywistych, a kończy na wskazaniu konkretnego elementu lub interakcji. Dzięki temu zmiana poprawia doświadczenie użytkownika, a nie tylko kolor wskaźnika w raporcie.