Core Web Vitals: co mierzą i jak je poprawić

Google zalicza do Core Web Vitals trzy metryki: LCP, INP i CLS. Każda opisuje inny element korzystania ze strony, dlatego dobry wynik jednej z nich nie mówi jeszcze, że cała witryna działa dobrze.

LCP, czyli Largest Contentful Paint, mierzy szybkość wyświetlenia największego elementu widocznego na ekranie. W praktyce może to być duże zdjęcie, grafika albo inny istotny fragment pierwszego widoku strony. Jeśli taki element pojawia się późno, użytkownik może mieć wrażenie, że witryna długo się ładuje, nawet gdy część interfejsu była dostępna wcześniej.

INP, czyli Interaction to Next Paint, opisuje reakcję strony na interakcje użytkownika. Chodzi o to, jak sprawnie witryna odpowiada po kliknięciu, stuknięciu lub innym działaniu. Ta metryka zastąpiła FID jako Core Web Vital 12 marca 2024 roku, więc przy ocenie responsywności strony patrzy się dziś na INP, a nie na FID.

CLS, czyli Cumulative Layout Shift, mierzy stabilność układu. Problem pojawia się wtedy, gdy elementy strony przesuwają się już podczas korzystania z niej. Przykładem może być treść przesunięta przez obraz, baner albo zmianę sposobu wyświetlania fontu. Dla użytkownika oznacza to mniej przewidywalny interfejs, w którym element może znaleźć się w innym miejscu niż chwilę wcześniej.

Te metryki trzeba rozpatrywać razem. LCP odpowiada na pytanie, kiedy główna treść staje się widoczna, INP pokazuje, jak strona reaguje, a CLS mówi, czy jej układ pozostaje stabilny. Dzięki temu nie sprowadzasz oceny wydajności do samego czasu ładowania.

Progi Core Web Vitals odnoszą się do 75. percentyla wizyt i są sprawdzane osobno dla telefonów oraz komputerów. To ważne, bo pojedynczy szybki test na jednym urządzeniu nie jest odpowiednikiem danych opisujących doświadczenia rzeczywistych użytkowników.

Percentyl ma tutaj praktyczne znaczenie. Nie chodzi o znalezienie jednego szczególnie szybkiego wejścia na stronę, ale o sprawdzenie, jak witryna zachowuje się w szerszym zbiorze rzeczywistych wizyt. Dzięki temu pojedynczy udany pomiar nie przesłania problemów, które występują u części odwiedzających.

Telefony i komputery trzeba rozdzielać. Ta sama witryna może zachowywać się inaczej w zależności od urządzenia, dlatego wspólny wynik nie oddawałby dobrze doświadczenia obu grup użytkowników. Jeśli problem występuje przede wszystkim na telefonach, właśnie tam szukam jego przyczyny, zamiast zakładać, że wynik z komputera opisuje całą stronę.

Nie ma przy tym potrzeby zakładać przyszłych zmian progów ani optymalizować witryny pod wartości, które nie są aktualnym standardem. Sensownym punktem odniesienia są obowiązujące definicje i progi LCP, INP oraz CLS.

Jednym z najczęstszych źródeł nieporozumień jest traktowanie każdego wyniku PageSpeed Insights jak tej samej kategorii danych. Tymczasem pomiar terenowy i laboratoryjny odpowiadają na inne pytania.

Dane terenowe opisują doświadczenia rzeczywistych użytkowników. Można je znaleźć między innymi w CrUX oraz w raporcie Core Web Vitals w Google Search Console. To właśnie na danych rzeczywistych użytkowników Google opiera ocenę Core Web Vitals.

Pomiar laboratoryjny powstaje w kontrolowanych warunkach. Tak działają Lighthouse oraz laboratoryjna część PageSpeed Insights. Taki test jest przydatny do diagnozy, bo pozwala obserwować zachowanie strony w określonych warunkach i sprawdzać skutki wprowadzonych zmian. Nie można go jednak utożsamiać z tym, czego faktycznie doświadczają wszyscy odwiedzający.

Wynik laboratoryjny może wskazać problem, ale to dane terenowe pokazują, czy problem występuje podczas prawdziwych wizyt. Z kolei sam raport oparty na rzeczywistych użytkownikach nie zawsze podpowie, który element strony należy zmienić. Oba rodzaje pomiaru uzupełniają się, zamiast ze sobą konkurować.

Jeżeli widzę słaby LCP w danych terenowych, test laboratoryjny pomaga mi sprawdzić, czy największy element jest zbyt ciężki, czy serwer odpowiada wolno albo czy jego wyświetlenie opóźniają zasoby CSS i JavaScript. Przy INP diagnoza prowadzi zwykle do JavaScriptu, wtyczek lub skryptów zewnętrznych. Przy CLS trzeba obserwować elementy, które zmieniają pozycję podczas ładowania strony.

Problemy z LCP często wiążą się z tym, co użytkownik widzi w pierwszym ekranie strony. Ciężkie zdjęcie może opóźnić pojawienie się największego elementu, podobnie jak wolny serwer, blokujące zasoby CSS lub JavaScript oraz fonty.

Dlatego przy słabym LCP nie zaczynam od przypadkowych zmian. Najpierw ustalam, który element jest mierzony jako największy i co opóźnia jego wyświetlenie. Jeśli jest nim obraz, sprawdzam jego format i sposób przygotowania. WebP lub AVIF mogą być częścią optymalizacji obrazów, także w WordPressie. Jeśli przyczyną jest serwer, sama zmiana grafiki nie rozwiąże problemu.

Dobrym przykładem jest moja własna strona marcinsiwonia.pl działająca na Next.js 16. We wrześniu 2026 roku LCP na telefonie wynosił 4,7 s. Przyczyną była plansza intro renderowana na serwerze. Po usunięciu tego problemu LCP spadł do 2,0 s.

Ten przypadek pokazuje, dlaczego najpierw trzeba znaleźć rzeczywistą przyczynę. Sama informacja o słabym LCP nie mówi jeszcze, czy trzeba zmniejszyć obraz, zmienić sposób renderowania elementu, przyspieszyć serwer czy ograniczyć zasoby blokujące wyświetlanie. Wynik jest początkiem diagnozy, a nie gotową receptą. Jeżeli korzystasz z WordPressa, szerzej opisuję ten obszar na stronie przyspieszanie stron WordPress.

Przy słabym INP trzeba przyjrzeć się temu, co dzieje się w przeglądarce w chwili interakcji. Typowe przyczyny to duża ilość JavaScriptu, wtyczki, skrypty zewnętrzne oraz długie zadania. Każdy z tych elementów może sprawić, że po działaniu użytkownika strona potrzebuje więcej czasu, aby pokazać kolejną zmianę interfejsu.

W WordPressie szczególnie istotna jest liczba i ciężar używanych dodatków. Ograniczenie wtyczek i rozbudowanych kreatorów to jeden ze sposobów zmniejszenia obciążenia strony, podobnie jak lekki motyw w miejsce rozwiązania dostarczającego dużo zbędnych zasobów. Nie chodzi jednak o mechaniczne usuwanie każdej wtyczki. Najpierw trzeba znaleźć elementy, które rzeczywiście dokładają JavaScript lub wydłużają pracę przeglądarki.

CLS wymaga innego spojrzenia. Tutaj problemem nie jest czas oczekiwania na reakcję, ale przesuwanie się elementów. Typowe źródła to obrazy bez określonych wymiarów, reklamy i banery wstawiane nad istniejącą treścią oraz fonty podmieniane już po rozpoczęciu wyświetlania strony.

Jeżeli przeglądarka zna wcześniej miejsce potrzebne na obraz, nie musi przesuwać sąsiedniej treści po jego załadowaniu. Podobna zasada dotyczy innych dynamicznie pojawiających się elementów. Przy fontach problem pojawia się wtedy, gdy po załadowaniu właściwego kroju zmienia się rozmiar lub układ tekstu, dlatego przy diagnozie CLS patrzę również na sposób ładowania typografii.

WordPress może osiągać dobre wyniki Core Web Vitals, ale droga do nich zależy od tego, co faktycznie spowalnia lub destabilizuje konkretną stronę. Typowe obszary pracy to cache, optymalizacja obrazów do WebP lub AVIF, ograniczenie wtyczek i kreatorów oraz lekki motyw.

Cache pomaga ograniczyć pracę potrzebną do dostarczenia strony, ale nie naprawi każdego rodzaju problemu. Jeśli LCP pogarsza ciężki obraz, trzeba zająć się obrazem. Jeżeli INP cierpi przez JavaScript z wielu dodatków, sam cache nie usunie pracy wykonywanej w przeglądarce. Gdy CLS wywołuje obraz bez wymiarów albo element wstawiany nad treścią, potrzebna jest poprawa układu.

Po zmianach stronę trzeba zmierzyć ponownie. Test laboratoryjny pomaga sprawdzić efekt konkretnej poprawki, a dane terenowe pokazują zachowanie witryny u rzeczywistych użytkowników. Dzięki temu można odróżnić zmianę, która poprawiła pojedynczy test, od zmiany widocznej podczas normalnego korzystania z serwisu.

Core Web Vitals są częścią sygnałów page experience, ale nie zastępują trafnej treści. Google podkreśla, że odpowiednia treść pozostaje ważniejsza, więc dobre wyniki techniczne są elementem jakości strony, a nie mechanizmem gwarantującym pozycję. Jeśli interesuje Cię wpływ sposobu renderowania strony na wyszukiwarkę, opisałem ten temat we wpisie Next.js a SEO.