Core Web Vitals: czym są LCP, INP i CLS i jak je poprawić

Core Web Vitals to trzy wskaźniki Google, które mierzą, jak Twoja strona działa u prawdziwych użytkowników: LCP – jak szybko pojawia się główna treść, INP – jak szybko strona reaguje na kliknięcia, i CLS – czy układ nie skacze podczas wczytywania. Wynik jest dobry, gdy LCP nie przekracza 2,5 s, INP 200 ms, a CLS 0,1. Poprawisz je głównie lżejszymi obrazami, mniejszą liczbą skryptów i zarezerwowanym miejscem na elementy.

Wskaźniki mają wpływ na pozycje w Google, ale mniejszy, niż sugerują oferty „przyspieszania pod SEO”. Ważniejsze jest to, że wolna i skacząca strona traci klientów bez względu na to, jak wysoko się wyświetla. Poniżej znajdziesz progi, różnicę między danymi od użytkowników a testem laboratoryjnym, typowe przyczyny problemów na WordPressie i ocenę realnego wpływu na widoczność.

Czym są Core Web Vitals: LCP, INP i CLS w prostych słowach

Google nazywa je po polsku podstawowymi wskaźnikami internetowymi. Każdy opisuje inny moment wizyty:

• LCP (Largest Contentful Paint), czyli największe wyrenderowanie treści – czas, po którym na ekranie pojawia się największy element widoczny bez przewijania: zwykle zdjęcie w nagłówku, slider albo duży blok tekstu. To odpowiedź na pytanie klienta, czy strona już się wczytała.
• INP (Interaction to Next Paint), czyli interakcja do kolejnego wyrenderowania – jak szybko strona reaguje na kliknięcia, dotknięcia ekranu i naciśnięcia klawiszy. Liczy się najdłuższa zaobserwowana interakcja z pominięciem wartości odstających. Przewijania i najeżdżania kursorem INP nie mierzy.
• CLS (Cumulative Layout Shift), czyli skumulowane przesunięcie układu – czy elementy przesuwają się podczas wczytywania. Klasyczny przykład: chcesz kliknąć „Zadzwoń”, a w ostatniej chwili pojawia się baner i trafiasz w coś innego.

INP jest najmłodszy w tym zestawie – w 2024 roku zastąpił wskaźnik FID, który mierzył tylko opóźnienie pierwszej interakcji. INP obejmuje wszystkie interakcje podczas wizyty, od kliknięcia aż do pokazania efektu na ekranie, więc lepiej pokazuje, jak strona działa przez cały czas, a nie tylko w pierwszej sekundzie.

Progi LCP, INP i CLS: dobre, wymagające poprawy i słabe

Google stosuje te same granice w Search Console, PageSpeed Insights i swojej dokumentacji. W opisie raportu w Search Console wyglądają tak:

Wskaźnik	Dobrej jakości	Wymagana poprawa	Słabej jakości
LCP – wczytanie głównej treści	do 2,5 s	do 4 s	powyżej 4 s
INP – reakcja na interakcje	do 200 ms	do 500 ms	powyżej 500 ms
CLS – stabilność układu	do 0,1	do 0,25	powyżej 0,25

Ważne są dwa szczegóły. Po pierwsze, liczy się 75. percentyl, czyli wartość, którą osiąga co najmniej 75% wizyt. Przykład: jeśli 80 na 100 wizyt ma LCP poniżej 2,5 s, a pozostałe 20 trwa po 5 s, strona przechodzi próg. Jeśli szybkich wizyt jest tylko 70, już nie. Po drugie, podstawowe wskaźniki internetowe ocenia się osobno na telefonach i komputerach, a status grupy adresów wyznacza najsłabszy z trzech wyników. Świetne LCP nie uratuje więc strony, która ma słaby CLS.

Ocenę przechodzi strona, której wszystkie trzy wskaźniki mieszczą się w zielonym zakresie. Według raportu Web Almanac 2024 organizacji HTTP Archive na telefonach udawało się to 40% witryn na WordPressie, wobec 28% rok wcześniej. Dla porównania w Wiksie odsetek ten wzrósł w tym czasie z 40% do 57%. Jeśli Twoja strona przechodzi ocenę, masz przewagę nad sporą częścią konkurencji.

Dane z terenu a dane laboratoryjne – dlaczego PageSpeed Insights pokazuje dwa wyniki

To najczęstsze źródło nieporozumień. W PageSpeed Insights widzisz dwa różne zestawy danych:

• Dane z terenu – pomiary z raportu CrUX (Chrome User Experience Report), czyli od prawdziwych użytkowników Chrome, którzy zgodzili się na przesyłanie statystyk. Obejmują ostatnie 28 dni i 75. percentyl wizyt. Te same dane zasilają raport w Search Console.
• Dane laboratoryjne – jednorazowy test Lighthouse w symulowanych warunkach, na określonym urządzeniu i łączu. Wynik od 0 do 100 i lista diagnoz pomagają znaleźć przyczyny problemów, ale nie decydują o tym, czy strona przechodzi ocenę.

INP da się zmierzyć tylko na prawdziwych interakcjach, dlatego w laboratorium zastępuje go całkowity czas blokowania (Total Blocking Time, TBT), czyli wskaźnik pokazujący, jak długo skrypty blokują przeglądarkę. Zielony test laboratoryjny przy słabym INP z terenu nie jest więc sprzecznością: test nie wypełnia Twojego formularza i nie otwiera menu tak jak klienci. Zestawienie narzędzi do obu rodzajów pomiarów znajdziesz w przewodniku web.dev.

Cecha	Dane z terenu (CrUX)	Dane laboratoryjne (Lighthouse)
Skąd pochodzą	Od prawdziwych użytkowników Chrome	Z symulowanego testu
Okres	Ostatnie 28 dni	Jeden pomiar, tu i teraz
INP	Mierzony	Zastępowany przez TBT
Do czego służą	Ocena, czy strona mieści się w progach	Szukanie przyczyn i szybkie sprawdzanie poprawek
Gdzie je zobaczysz	Search Console, górna część PageSpeed Insights	Dolna część PageSpeed Insights, Lighthouse w Chrome

Mała strona może w ogóle nie mieć danych z terenu, bo CrUX potrzebuje odpowiedniej liczby wizyt. Raport w Search Console obejmuje ponadto tylko zindeksowane adresy, więc jeśli brakuje w nim ważnych podstron, sprawdź najpierw, czy Twoja strona jest poprawnie zindeksowana w Google.

Jak sprawdzić Core Web Vitals swojej strony krok po kroku

1. Otwórz raport Core Web Vitals w Search Console. Sprawdź osobno telefony i komputery oraz to, ile adresów jest w każdej kategorii.
2. Znajdź problem i grupę stron. Raport pokaże, który wskaźnik przekracza próg i jakich grup podobnych adresów dotyczy.
3. Przetestuj przykładowy adres w PageSpeed Insights. Najpierw spójrz na dane z terenu, potem na diagnozy z testu laboratoryjnego. Podpowiedzą, który element jest elementem LCP i co przesuwa układ.
4. Popraw szablon, a nie pojedynczą stronę. Grupy w raporcie to zwykle strony o tym samym układzie, np. wszystkie wpisy na blogu albo karty produktów. Jedna poprawka w szablonie naprawia wiele adresów naraz.
5. Sprawdź efekt w teście laboratoryjnym. Lighthouse pokaże zmianę od razu, dane z terenu – dopiero po kilku tygodniach.
6. Uruchom weryfikację. W szczegółach problemu kliknij „Rozpocznij śledzenie”. Search Console obserwuje adresy przez 28 dni i jeśli problem się nie powtórzy, uzna go za naprawiony.

Jak korzystać z pozostałych raportów, wyjaśniamy w przewodniku po Google Search Console dla właściciela firmy.

Najczęstsze przyczyny słabych wyników na WordPressie i jak je naprawić

WordPress sam w sobie nie jest wolny. Problemy biorą się zwykle z motywu, wtyczek, hostingu i dodatków doklejanych przez lata.

Słabe LCP: ciężki nagłówek i wolny serwer

Według poradnika web.dev o optymalizacji LCP na ten czas składają się cztery etapy: odpowiedź serwera (TTFB), opóźnienie startu pobierania głównego zasobu, samo pobieranie i wyrenderowanie elementu. Na WordPressie najczęściej szwankuje:

• Odpowiedź serwera. Słaby hosting, brak pamięci podręcznej stron (cache) i łańcuchy przekierowań wydłużają TTFB, zanim przeglądarka dostanie choćby fragment treści. Pomagają cache stron, CDN i wydajniejszy serwer – o wyborze piszemy w tekście o hostingu dla WordPressa.
• Slider lub tło CSS w nagłówku. Obraz wstawiany skryptem slidera albo ustawiony jako tło w CSS przeglądarka odkrywa później niż zwykły znacznik img w kodzie HTML. Statyczne zdjęcie zamiast slidera to często szybka i odczuwalna poprawa.
• Leniwe ładowanie głównego obrazu. Web.dev wprost odradza lazy loading elementu LCP. Od wersji 6.3 WordPress sam dodaje atrybut fetchpriority z wartością high do obrazu, który najpewniej będzie elementem LCP, i rzadziej oznacza obrazy na górze strony do leniwego ładowania. Według zespołu WordPressa sam ten atrybut poprawia LCP zwykle o 5–10%. Jeśli nagłówek budujesz kreatorem stron, sprawdź w kodzie, czy główny obraz nie ma atrybutu loading z wartością lazy.
• Za duże pliki. Zdjęcie prosto z aparatu, szerokie na kilka tysięcy pikseli, to częsty widok w nagłówkach. Przeskaluj je do rzeczywistego rozmiaru i zapisz w formacie WebP lub AVIF.
• Blokujące CSS i JavaScript. Duże arkusze stylów i synchroniczne skrypty w sekcji head opóźniają wyświetlenie strony. Pomaga usunięcie nieużywanego CSS i odroczenie skryptów, które nie są potrzebne na starcie.

Słabe INP: za dużo JavaScriptu

Na INP składają się trzy fazy: opóźnienie reakcji na działanie użytkownika, przetwarzanie zdarzenia i wyświetlenie efektu. Wszystkie wydłużają długie zadania w głównym wątku przeglądarki oraz bardzo rozbudowany kod strony (duży DOM). Na stronach firmowych źródłem są zwykle:

• ciężkie kreatory stron i motywy, które generują tysiące zagnieżdżonych elementów,
• wtyczki ładujące swoje skrypty na każdej podstronie, choć potrzebne są na jednej, np. formularze, galerie czy slidery,
• skrypty zewnętrzne: czat, piksele reklamowe, mapy, nagrywanie sesji, kilka narzędzi analitycznych naraz.

Co pomaga: usunięcie nieużywanych wtyczek, ładowanie skryptów tylko tam, gdzie są potrzebne, opóźnienie mniej ważnych dodatków do pierwszej interakcji (taką opcję mają popularne wtyczki do cache) i porządek w Menedżerze tagów Google. Programista może też podzielić długie zadania na krótsze, żeby przeglądarka częściej mogła reagować na kliknięcia.

Słaby CLS: elementy bez zarezerwowanego miejsca

Przesunięcia układu powodują najczęściej obrazy i filmy bez podanych wymiarów, reklamy, osadzone mapy i filmy z YouTube bez określonej wysokości, treści wstrzykiwane z opóźnieniem (np. pasek z promocją nad nagłówkiem), czcionki internetowe, które po wczytaniu zmieniają szerokość tekstu, oraz animacje zmieniające położenie elementów.

Rozwiązania są proste: podaj szerokość i wysokość obrazów oraz ramek albo zarezerwuj miejsce w CSS, np. właściwością aspect-ratio. Baner zgody na cookies wyświetlaj jako nakładkę, która nie przesuwa treści. Dla czcionek web.dev poleca ustawienie font-display: optional i dobranie podobnej czcionki zastępczej, a w animacjach – korzystanie z właściwości transform.

Jaki jest realny wpływ wskaźników na pozycje w Google

Google pisze w dokumentacji o podstawowych wskaźnikach internetowych, że jego główne systemy rankingowe nagradzają dobre wyniki tych wskaźników – razem z innymi aspektami jakości strony. Jednocześnie od lat podkreśla, że ważniejsza jest trafność: wyszukiwarka pokaże najlepszą odpowiedź na pytanie nawet wtedy, gdy strona działa przeciętnie, a jakość działania strony ma większe znaczenie, gdy wiele wyników jest podobnie przydatnych. Dobre wyniki w raportach nie gwarantują więc wysokich pozycji.

W praktyce oznacza to trzy rzeczy:

• Przejście z kategorii „słabej jakości” do „dobrej jakości” ma sens, bo usuwa realny problem klientów i może pomóc w wyrównanej rywalizacji z konkurencją.
• Walka o 100/100 w teście laboratoryjnym zwykle się nie opłaca, jeśli wskaźniki z terenu są już zielone.
• Jeśli konkurencja ma lepsze treści i więcej opinii, sama szybkość tego nie zmieni.

Większy bywa wpływ na sprzedaż niż na pozycje. W teście A/B opisanym przez web.dev Vodafone poprawił LCP o 31%, co przełożyło się na 8% więcej sprzedaży. To przypadek dużej marki, ale dobrze pokazuje kierunek: szybsza strona to mniej porzuconych wizyt, także tych, za które płacisz w kampaniach reklamowych.

Jeśli chcesz, żeby ktoś przejrzał szablony, wtyczki i skrypty Twojej strony i zaplanował poprawki w kolejności od najbardziej opłacalnych, możesz to zlecić w ramach optymalizacji strony.

Najczęściej zadawane pytania

Czy potrzebuję wyniku 100/100 w PageSpeed Insights?

Nie. Wynik od 0 do 100 pochodzi z testu laboratoryjnego Lighthouse i nie jest oceną podstawowych wskaźników internetowych. Liczy się to, czy dane od prawdziwych użytkowników mieszczą się w progach: LCP do 2,5 s, INP do 200 ms i CLS do 0,1. Strona z wynikiem 70 w teście może przechodzić ocenę z terenu, a strona z wynikiem 95 może mieć problem z INP, którego test nie wychwyci.

Dlaczego raport w Search Console nie pokazuje danych?

Najczęściej dlatego, że strona ma za mało wizyt od użytkowników Chrome, by CrUX zebrał wiarygodne dane. Przy niewielkim ruchu Search Console łączy podobne strony w szersze grupy, a gdy i to nie wystarcza, pokazuje komunikat „Brak dostępnych danych”. Raport obejmuje też tylko zindeksowane adresy. Wtedy korzystaj z testów laboratoryjnych w PageSpeed Insights i poprawiaj przede wszystkim najważniejsze szablony.

Po jakim czasie poprawki będą widoczne?

W teście laboratoryjnym od razu. Dane z terenu obejmują ostatnie 28 dni, więc pełny efekt zobaczysz po około czterech tygodniach, a stopniową poprawę wcześniej. Tyle samo trwa weryfikacja po kliknięciu „Rozpocznij śledzenie” w Search Console. Na zmiany w pozycjach nie licz z dnia na dzień – szybkość strony to tylko jeden z wielu sygnałów.

Czy zmiana hostingu poprawi Core Web Vitals?

Może poprawić LCP, jeśli problemem jest wolna odpowiedź serwera, czyli długi TTFB. Nie pomoże natomiast na INP i CLS, bo te wskaźniki zależą od tego, co dzieje się w przeglądarce: ilości JavaScriptu, rozmiaru kodu strony i rezerwowania miejsca na elementy. Zanim zmienisz serwer, sprawdź w diagnozach PageSpeed Insights, czy to właśnie czas odpowiedzi serwera jest wąskim gardłem.

Czym INP różni się od FID?

FID mierzył tylko opóźnienie pierwszej interakcji, czyli czas, zanim przeglądarka w ogóle zaczęła obsługiwać kliknięcie. INP, który zastąpił go w 2024 roku, obserwuje wszystkie kliknięcia, dotknięcia i naciśnięcia klawiszy podczas wizyty – od działania użytkownika aż do pokazania efektu na ekranie – i raportuje najdłuższe z nich, z pominięciem wartości odstających. Jest więc znacznie bardziej wymagający.

Źródła

1. Podstawowe wskaźniki internetowe i wyniki wyszukiwania Google (Google Search Central)
2. Raport dotyczący Core Web Vitals – Pomoc Search Console
3. Podstawowe wskaźniki internetowe (web.dev)
4. Narzędzia do pomiaru podstawowych wskaźników internetowych (web.dev)
5. Optymalizacja LCP (web.dev)
6. Optymalizacja CLS (web.dev)
7. Optymalizacja INP (web.dev)
8. Interakcja do kolejnego wyrenderowania – INP (web.dev)
9. Image performance enhancements in WordPress 6.3 (Make WordPress Core)
10. Speculative Loading in 6.8 (Make WordPress Core)
11. Web Almanac 2024: CMS (HTTP Archive)
12. Vodafone: A 31% improvement in LCP increased sales by 8% (web.dev)