Core Web Vitals – czym są LCP, INP i CLS i jak je mierzyć?

Core Web Vitals (podstawowe wskaźniki internetowe) to trzy metryki Google, które mierzą rzeczywiste doświadczenia użytkowników strony: szybkość ładowania głównej treści (LCP), responsywność na interakcje (INP) i stabilność układu (CLS). Od 2021 roku są brane pod uwagę przez systemy rankingowe Google, a w marcu 2024 roku INP zastąpił wcześniejszy wskaźnik FID. W tym artykule wyjaśniamy, co oznacza każdy wskaźnik, jakie wartości są dobre, jak je mierzyć i jak bardzo wpływają na pozycje.

Czym są Core Web Vitals?

Core Web Vitals to podzbiór wskaźników Web Vitals, który Google uznaje za najważniejszy dla każdej strony internetowej. Każdy z nich odpowiada na jedno pytanie o doświadczenie użytkownika:

• LCP (Largest Contentful Paint) – czy strona szybko pokazuje swoją główną treść?
• INP (Interaction to Next Paint) – czy strona szybko reaguje, gdy użytkownik klika, dotyka ekranu albo pisze?
• CLS (Cumulative Layout Shift) – czy elementy strony nie „skaczą” w trakcie ładowania?

Wskaźniki opisuje i rozwija zespół Chrome w dokumentacji web.dev. Zestaw może się zmieniać – najlepszym przykładem jest wymiana FID na INP – dlatego warto sprawdzać aktualną dokumentację, zamiast opierać się na starszych poradnikach.

Jakie wartości Core Web Vitals są dobre?

Dla każdego wskaźnika Google określa trzy przedziały: dobry, wymagający poprawy i słaby. Strona „zalicza” Core Web Vitals, gdy co najmniej 75% wizyt (75. percentyl) mieści się w przedziale dobrym dla wszystkich trzech metryk.

Co mierzy LCP i jak go poprawić?

LCP (Largest Contentful Paint) mierzy czas od rozpoczęcia ładowania strony do wyświetlenia największego widocznego elementu w oknie przeglądarki – zwykle zdjęcia głównego, banera, okładki wideo albo dużego bloku tekstu. Dobry wynik to maksymalnie 2,5 sekundy.

Najczęstsze przyczyny słabego LCP

• wolna odpowiedź serwera (wysoki TTFB) – słaby hosting, brak cache, ciężkie zapytania do bazy;
• duże, nieskompresowane zdjęcia w pierwszym ekranie;
• główny obraz ładowany z opóźnieniem (lazy loading na grafice w pierwszym ekranie, obraz dodawany przez JavaScript);
• CSS i JavaScript blokujące renderowanie;
• czcionki, na które strona czeka, zanim pokaże tekst.

Jak poprawić LCP

1. Skróć czas odpowiedzi serwera: cache strony, aktualna wersja PHP, wydajny hosting, CDN.
2. Zoptymalizuj główny obraz: właściwe wymiary, formaty WebP lub AVIF, kompresja. Więcej w poradniku jak optymalizować zdjęcia na stronie.
3. Nie stosuj lazy loadingu dla elementu LCP; dodaj mu atrybut fetchpriority=”high”.
4. Usuń nieużywany CSS i JavaScript, odrocz skrypty, które nie są potrzebne do wyświetlenia pierwszego ekranu.
5. Ładuj czcionki z font-display: swap i ogranicz ich liczbę.

Rola serwera jest tu często niedoceniana – o tym, jak hosting wpływa na czas ładowania, piszemy w artykule hosting a SEO: 8 rzeczy, które musisz wiedzieć.

Czym jest INP i dlaczego zastąpił FID?

INP (Interaction to Next Paint) mierzy, ile czasu mija od interakcji użytkownika – kliknięcia, dotknięcia ekranu, naciśnięcia klawisza – do momentu, gdy przeglądarka pokaże jej efekt. Bierze pod uwagę wszystkie interakcje podczas wizyty i raportuje jedną z najwolniejszych. Dobry wynik to maksymalnie 200 milisekund.

INP zastąpił FID (First Input Delay) jako oficjalny wskaźnik Core Web Vitals 12 marca 2024 roku. FID mierzył tylko opóźnienie pierwszej interakcji i tylko do momentu rozpoczęcia jej obsługi, więc większość stron miała dobre wyniki, mimo że w praktyce „zacinała się” przy kolejnych kliknięciach. INP jest znacznie bardziej wymagający i lepiej oddaje to, co czuje użytkownik – zwłaszcza w sklepach z filtrami, koszykiem w okienku czy rozbudowanym menu.

Najczęstsze przyczyny słabego INP

• długie zadania JavaScript blokujące główny wątek przeglądarki;
• duża liczba skryptów zewnętrznych: czaty, mapy cieplne, piksele reklamowe, widżety opinii;
• bardzo rozbudowany DOM (tysiące elementów), który przeglądarka musi przeliczać po każdej zmianie;
• ciężkie procedury obsługi zdarzeń, np. przeliczanie całej listy produktów po zaznaczeniu jednego filtra.

Jak poprawić INP

1. Zidentyfikuj najwolniejsze interakcje w danych terenowych (PageSpeed Insights, CrUX) i odtwórz je w panelu Performance w Chrome DevTools.
2. Dziel długie zadania JavaScript na mniejsze i oddawaj kontrolę przeglądarce między nimi.
3. Usuń lub odrocz skrypty zewnętrzne, które nie są niezbędne – szczególnie te ładowane przez Google Tag Managera bez kontroli.
4. Po interakcji najpierw pokaż szybką informację zwrotną (np. stan ładowania), a ciężkie obliczenia wykonaj później.
5. Uprość strukturę DOM i ogranicz liczbę elementów renderowanych jednocześnie.

Co mierzy CLS i jak uniknąć przesunięć układu?

CLS (Cumulative Layout Shift) mierzy wizualną stabilność strony, czyli to, jak bardzo elementy przesuwają się bez udziału użytkownika. Klasyczny przykład: chcesz kliknąć link, a w ostatniej chwili nad nim pojawia się baner i trafiasz w coś innego. Dobry wynik to maksymalnie 0,1.

Jak poprawić CLS

• podawaj wymiary (width i height) lub proporcje (aspect-ratio) dla zdjęć, filmów i ramek iframe;
• rezerwuj miejsce na reklamy, banery zgód i widżety, zanim się załadują;
• nie wstawiaj nowych treści nad już widocznymi elementami, chyba że w odpowiedzi na działanie użytkownika;
• wczytuj czcionki tak, by zamiana czcionki zastępczej na docelową nie zmieniała wyraźnie wymiarów tekstu;
• animuj elementy właściwością transform zamiast zmieniać ich położenie i rozmiar.

Jakie inne wskaźniki warto znać?

Poza trzema podstawowymi wskaźnikami istnieją metryki pomocnicze, które nie są częścią Core Web Vitals, ale pomagają znaleźć przyczynę problemu. Warto je znać, bo pojawiają się w raportach narzędzi.

• TTFB (Time to First Byte) – czas do otrzymania pierwszego bajtu odpowiedzi serwera; wysoki TTFB niemal zawsze psuje LCP.
• FCP (First Contentful Paint) – moment wyświetlenia pierwszego elementu treści.
• TBT (Total Blocking Time) – łączny czas blokowania głównego wątku w teście laboratoryjnym; dobry „zastępczy” wskaźnik dla INP, gdy nie masz danych od użytkowników.
• Speed Index – jak szybko wypełnia się widoczna część strony.

Uwaga na częsty błąd ze starszych poradników: TTFB, FCP czy TBT nie są „dodatkowymi Core Web Vitals” ani osobnymi czynnikami rankingowymi. Wskaźnik TTI (Time to Interactive) został natomiast usunięty z wyniku Lighthouse w wersji 10.

Jak mierzyć Core Web Vitals?

Core Web Vitals mierzy się na dwa sposoby: danymi terenowymi (od prawdziwych użytkowników) i danymi laboratoryjnymi (z testu w kontrolowanych warunkach). Google przy ocenie strony korzysta z danych terenowych z raportu Chrome User Experience Report (CrUX), a testy laboratoryjne służą do diagnozy i sprawdzania poprawek.

Google Search Console

Raport „Podstawowe wskaźniki internetowe” w Search Console grupuje podobne adresy i dzieli je na dobre, wymagające poprawy i słabe – osobno dla komórek i komputerów. Po kliknięciu problemu (np. „Problem z INP: dłuższy niż 200 ms”) zobaczysz przykładowe adresy. Raport pokazuje dane z ostatnich 28 dni, więc efekty poprawek widać z opóźnieniem. Strony o małym ruchu mogą nie mieć tu danych.

PageSpeed Insights

PageSpeed Insights łączy dwie perspektywy: na górze pokazuje dane terenowe z CrUX dla adresu i całej domeny (jeśli są dostępne), a niżej wynik testu Lighthouse z listą konkretnych rekomendacji. To najlepszy punkt startowy przy analizie pojedynczej podstrony.

Lighthouse

Lighthouse to audyt wbudowany w Chrome DevTools, dostępny też z wiersza poleceń. Wynik wydajności liczy na podstawie FCP, Speed Index, LCP, TBT i CLS. Ponieważ test nie zawiera prawdziwych interakcji, nie mierzy INP – zamiast niego pomocny jest TBT.

Chrome DevTools

Panel Performance w Chrome DevTools pokazuje na żywo LCP, INP i CLS podczas przeglądania strony oraz pozwala nagrać szczegółowy przebieg ładowania i interakcji. Od wersji Chrome 132 (styczeń 2025) przejął funkcje dawnej wtyczki Web Vitals, której wsparcie Google zakończyło.

Czy testy w narzędziach oddają rzeczywiste wyniki?

Testy laboratoryjne nie oddają w pełni doświadczeń Twoich klientów, bo wykonywane są na jednym urządzeniu i jednym łączu. Wynik zależy od wydajności procesora, pamięci RAM, obciążenia komputera i sieci. Lighthouse symuluje wolniejsze urządzenie mobilne, ale to wciąż symulacja.

Dlatego przy ocenie strony kieruj się przede wszystkim danymi terenowymi: raportem w Search Console, sekcją danych od użytkowników w PageSpeed Insights albo własnym pomiarem RUM. Strona, która na nowym laptopie działa błyskawicznie, u klienta z kilkuletnim telefonem może mieć słaby INP. Pamiętaj też, że Google indeksuje strony w wersji mobilnej – zadbaj o nią w pierwszej kolejności, korzystając ze wskazówek z artykułu o optymalizacji strony pod urządzenia mobilne.

Czy Core Web Vitals wpływają na pozycje w Google?

Tak, Core Web Vitals są brane pod uwagę przez systemy rankingowe Google, ale ich wpływ jest umiarkowany. Google w dokumentacji o doświadczeniu na stronie (page experience) podkreśla, że najważniejsza jest trafność i jakość treści, a dobre wskaźniki nie zagwarantują wysokiej pozycji same w sobie.

W praktyce Core Web Vitals działają podobnie jak HTTPS: brak spełnienia standardu rzadko jest główną przyczyną słabych pozycji, ale przy porównywalnej jakości treści może przechylić szalę. Dużo wyraźniej widać ich wpływ na zachowanie użytkowników – wolna, „skacząca” strona traci klientów, zanim zdążą cokolwiek kupić.

„Brak wdrożenia CWV natychmiast po aktualizacji nie spowoduje, że strony zaczną gwałtownie spadać w SERP-ach (jak miało to miejsce w przypadku Google Penguin Update). Po prostu z czasem użytkownicy będą wybierać serwisy zwracające uwagę na [podstawowe wskaźniki internetowe], ponieważ okaże się to znacznie bardziej komfortowym rozwiązaniem.” – Tomasz Wieliczko, CEO Xann Marketing

Jakie problemy z Core Web Vitals najczęściej mają sklepy i strony na WordPressie?

W sklepach internetowych i serwisach na WordPressie problemy z Core Web Vitals powtarzają się zaskakująco często i zwykle wynikają z motywu, wtyczek oraz skryptów marketingowych, a nie z samej treści. Poniżej zestawienie typowych przyczyn dla poszczególnych szablonów.

Na WordPressie szczególną uwagę zwróć na rozbudowane kreatory stron, które generują bardzo dużo kodu, oraz na wtyczki ładujące swoje skrypty i style na każdej podstronie, choć potrzebne są tylko na jednej (np. formularz kontaktowy). Często większy efekt niż kolejna wtyczka optymalizacyjna daje usunięcie kilku zbędnych dodatków.

Jakie błędy popełnia się przy optymalizacji Core Web Vitals?

Najczęstszym błędem jest optymalizowanie pod wynik punktowy w PageSpeed Insights zamiast pod dane od użytkowników. Inne pułapki, które widzimy w audytach:

• Lazy loading wszystkich obrazów – także tego w pierwszym ekranie, co opóźnia LCP zamiast go poprawiać.
• Agresywne odraczanie skryptów – strona wygląda na załadowaną, ale pierwsze kliknięcia nie działają lub działają z opóźnieniem, co pogarsza INP.
• Testowanie tylko strony głównej – a większość ruchu z Google trafia na kategorie, produkty i wpisy.
• Ignorowanie Google Tag Managera – kolejne tagi dodawane przez dział marketingu potrafią zniweczyć pracę programistów.
• Brak kontroli po wdrożeniach – nowa wersja szablonu czy wtyczki może z dnia na dzień pogorszyć wskaźniki.
• Ocena po jednym dniu – dane terenowe zbierane są z 28 dni, więc efekt poprawek widać stopniowo.

Od czego zacząć optymalizację Core Web Vitals?

Optymalizację zacznij od szablonów stron z największym ruchem i najgorszymi wynikami w danych terenowych, a nie od strony głównej czy wyniku punktowego w PageSpeed Insights. Sprawdzony plan działania:

1. Otwórz raport w Search Console i wypisz grupy adresów ze statusem „Słaby” i „Wymaga poprawy” – osobno dla mobile i desktop.
2. Przypisz je do szablonów: strona główna, kategoria, produkt, wpis blogowy, koszyk.
3. Dla każdego szablonu zbadaj przykładowy adres w PageSpeed Insights i znajdź główną przyczynę (serwer, obrazy, skrypty, przesunięcia).
4. Wdrażaj poprawki w kolejności: serwer i cache, obrazy, skrypty zewnętrzne, kod szablonu.
5. Po wdrożeniu poczekaj około 28 dni i w Search Console uruchom sprawdzanie poprawki.
6. Dodaj kontrolę wydajności do procesu wdrożeń, by nowe funkcje i skrypty marketingowe nie psuły wyników.

Core Web Vitals to jeden z punktów naszej checklisty SEO i audytu technicznego SEO. Jeśli chcesz, byśmy przeanalizowali wydajność Twojej strony razem z resztą czynników SEO, sprawdź usługę pozycjonowania stron.

Najczęstsze pytania

Dlaczego PageSpeed Insights pokazuje inny wynik niż Search Console?

Search Console pokazuje dane od prawdziwych użytkowników z ostatnich 28 dni dla grup adresów, a wynik punktowy w PageSpeed Insights pochodzi z jednorazowego testu laboratoryjnego. Różnice są normalne – przy ocenie strony ważniejsze są dane terenowe.

Czy wynik 100 punktów w PageSpeed Insights jest potrzebny?

Nie. Wynik punktowy to ocena testu laboratoryjnego, a nie wskaźnik używany przez Google w rankingu. Ważne jest, by LCP, INP i CLS mieściły się w dobrych przedziałach w danych od użytkowników.

Co zrobić, gdy Search Console nie pokazuje danych Core Web Vitals?

Oznacza to, że strona ma za mały ruch z przeglądarki Chrome, by trafić do raportu CrUX. W takiej sytuacji korzystaj z testów laboratoryjnych w PageSpeed Insights i Lighthouse lub wdroż własny pomiar wskaźników u użytkowników.

Czy wtyczki do cache w WordPressie wystarczą, by poprawić Core Web Vitals?

Często znacząco poprawiają LCP, bo skracają czas odpowiedzi serwera i optymalizują pliki. Nie rozwiążą jednak problemów z ciężkim motywem, nadmiarem skryptów zewnętrznych czy przesunięciami układu – te wymagają zmian w szablonie.

Czy Core Web Vitals mają znaczenie dla widoczności w AI Overviews?

Google nie podaje osobnych wymagań technicznych dla AI Overviews poza tym, że strona musi być zaindeksowana i spełniać podstawowe zasady wyszukiwarki. Szybka, stabilna strona pomaga jednak zatrzymać użytkownika, który trafi na nią z odpowiedzi AI. Więcej o tym, jak Google cytuje strony w podsumowaniach, piszemy w artykule o AI Overviews, a o wpływie techniki na widoczność w odpowiedziach AI – w poradniku o widoczności w AI.