Core Web Vitals, po polsku podstawowe wskaźniki internetowe, to trzy metryki Google, które mierzą doświadczenie realnych użytkowników: LCP (ładowanie, dobry wynik do 2,5 s), INP (reakcja na kliknięcia, do 200 ms) i CLS (stabilność układu, do 0,1). Strona zalicza ocenę, gdy 75% odsłon z ostatnich 28 dni mieści się w dobrych progach wszystkich trzech metryk:
| Metryka | Co mierzy | Dobry | Do poprawy | Słaby |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | czas do wyświetlenia największego obrazu albo bloku tekstu | do 2,5 s | 2,5-4 s | powyżej 4 s |
| INP (Interaction to Next Paint) | czas od kliknięcia, dotknięcia albo klawisza do reakcji na ekranie | do 200 ms | 200-500 ms | powyżej 500 ms |
| CLS (Cumulative Layout Shift) | nieoczekiwane przesunięcia elementów strony | do 0,1 | 0,1-0,25 | powyżej 0,25 |
Progi są takie same dla telefonów i komputerów. Google ocenia oba typy urządzeń osobno, więc strona może zaliczać ocenę na komputerach i nie zaliczać jej na telefonach.
Jak Google liczy ocenę Core Web Vitals?
Wartości z tabeli pochodzą z Chrome User Experience Report (CrUX), czyli zbioru pomiarów, które przeglądarka Chrome wysyła z wizyt realnych użytkowników. Google bierze z niego ostatnie 28 dni i wartość 75. percentyla, czyli taką, którą 3 na 4 odsłony osiągnęły albo poprawiły. Strona zalicza ocenę tylko wtedy, gdy 75. percentyl każdej z trzech metryk mieści się w dobrym progu. Jedna metryka w gorszym przedziale wystarcza, żeby ocena była niezaliczona, nawet przy bardzo szybkim LCP.
Pomiar z wizyty trafia do CrUX, gdy spełnia 3 warunki:
- użytkownik korzysta z Chrome na komputerze albo na Androidzie i ma włączone wysyłanie statystyk oraz synchronizację historii; Chrome na iPhonie, Edge i aplikacje z wbudowaną przeglądarką danych nie wysyłają,
- strona jest publicznie dostępna, czyli odpowiada kodem 200 i nie ma znacznika noindex,
- strona albo cały serwis ma wystarczająco dużo takich wizyt, a Google nie ujawnia progu.
Serwis z niewielkim ruchem często nie ma danych ani dla pojedynczego adresu, ani dla całej domeny. PageSpeed Insights pokazuje wtedy przy wrażeniach użytkowników komunikat „Brak danych”, a raport w Search Console zostaje pusty. Gdy dane ma domena, a brakuje ich dla konkretnego adresu, Google według deklaracji Johna Muellera korzysta z danych grupy podobnych stron, na przykład wszystkich stron kategorii w sklepie.
Search Console pokazuje to samo grupowanie. Raport „Podstawowe wskaźniki internetowe” ocenia grupy podobnych adresów, osobno dla telefonów i komputerów, a status grupy wyznacza jej najgorsza metryka.
Co dokładnie mierzą LCP, INP i CLS?
LCP (Largest Contentful Paint) to czas od rozpoczęcia ładowania do wyświetlenia największego elementu w widocznej części ekranu. Tym elementem bywa obraz, klatka wideo, tło ładowane z pliku albo blok tekstu. Na 76% stron mobilnych jest nim obraz (Web Almanac 2025, dane HTTP Archive i CrUX z lipca 2025 roku), więc LCP mierzy w praktyce, jak szybko pojawia się główne zdjęcie strony.
INP (Interaction to Next Paint) to czas od kliknięcia, dotknięcia ekranu albo naciśnięcia klawisza do chwili, w której strona pokazuje reakcję. Chrome mierzy wszystkie takie interakcje podczas całej wizyty i zapisuje najwolniejszą, a przy dłuższych wizytach pomija jedną najwolniejszą na każde 50 interakcji. Przewijanie i najechanie kursorem do INP się nie liczą. Od 12 marca 2024 roku INP zastępuje FID (First Input Delay), który mierzył tylko opóźnienie pierwszej interakcji, więc opisy z progiem „FID poniżej 100 ms” są od tego dnia nieaktualne.
CLS (Cumulative Layout Shift) sumuje nieoczekiwane przesunięcia elementów, na przykład akapit zepchnięty w dół przez doładowany baner. Wynik pojedynczego przesunięcia to iloczyn dwóch wartości, czyli części ekranu objętej przesunięciem i odległości, o jaką element się przesunął. CLS bierze największą serię przesunięć z całej wizyty. Przesunięcia w ciągu 500 ms po kliknięciu użytkownika się nie liczą, bo użytkownik ich oczekuje.
Zestaw trzech metryk nie zmienił się od 2024 roku. Chrome poprawia szczegóły ich definicji w kolejnych wersjach przeglądarki, a Google deklaruje, że zmiany samych metryk ogłasza z wyprzedzeniem i wprowadza najwyżej raz w roku.
Czy Core Web Vitals wpływają na pozycje w Google?
Tak, w niewielkim stopniu. Google deklaruje, że jego systemy rankingowe korzystają z Core Web Vitals, i jednocześnie, że dobre wyniki nie przesądzają o wysokiej pozycji. John Mueller z Google opisał je jako czynnik ważniejszy niż rozstrzygnięcie remisu, który nie zastępuje trafności treści, a później jako czynnik, który nie należy do dużych. Najtrafniejsza strona wygrywa także przy słabych Core Web Vitals.
Skalę efektu pokazał pomiar Sistrix po wdrożeniu aktualizacji page experience w 2021 roku. Widoczność domen spełniających wszystkie progi wzrosła o 3,7%, średnia wszystkich domen o 2,7%, a domeny z co najmniej jedną metryką poza progiem zostały na tym samym poziomie. Wynik pokazuje korelację z okresu, gdy w zestawie był jeszcze FID, i autor badania sam zastrzega, że nie dowodzi on przyczyny.
Google deklaruje też, że pozostałe elementy page experience, takie jak HTTPS czy brak natrętnych okienek, nie podnoszą pozycji bezpośrednio. Serwis bez danych w CrUX nie ma oceny Core Web Vitals, więc szybsza strona zmienia w nim doświadczenie użytkowników, ale nie sygnał, którego Google nie zbiera.
Poprawa Core Web Vitals ma sens z myślą o SEO, gdy raport w Search Console pokazuje grupy adresów w stanie „Słaby” albo „Wymaga poprawy”, a strony konkurentów w wynikach są podobnie trafne. Nie ma sensu jako sposób na awans strony, która przegrywa treścią albo linkami.
Dlaczego wynik PageSpeed Insights to nie ocena Core Web Vitals?
PageSpeed Insights pokazuje w jednym raporcie dwa różne pomiary. Górna część, o wrażeniach użytkowników, to dane z CrUX i ocena Core Web Vitals. Dolna część to jeden test laboratoryjny Lighthouse na emulowanym telefonie i z niego pochodzi wynik wydajności od 0 do 100.
Wynik od 0 do 100 różni się od oceny Core Web Vitals z 3 powodów:
- Wynik powstaje z 5 pomiarów: FCP, LCP, TBT, CLS i Speed Index. Do Core Web Vitals należą tylko LCP i CLS, które odpowiadają za połowę wyniku.
- Test laboratoryjny nie mierzy INP, bo nikt w nim nie klika. Zastępuje go TBT (Total Blocking Time), czyli czas, przez który skrypty blokują przeglądarkę podczas ładowania.
- Test obejmuje samo ładowanie strony, więc nie widzi przesunięć CLS, które pojawiają się później, na przykład przy przewijaniu i doładowywaniu treści.
Strona może więc mieć wynik powyżej 90 i żadnej oceny Core Web Vitals, gdy brakuje jej danych od użytkowników. Bywa też odwrotnie, bo test na emulowanym telefonie ze spowolnionym łączem wypada gorzej niż wizyty realnych użytkowników na szybszych urządzeniach.
Ocenę całego serwisu pokazuje raport „Podstawowe wskaźniki internetowe” w Google Search Console, a ocenę jednego adresu górna część raportu PageSpeed Insights. Gdy obu brakuje danych, zostaje test laboratoryjny, który wskazuje przyczyny problemów z LCP i CLS bez oceny.
Od czego zacząć poprawę Core Web Vitals?
Na telefonach najczęściej zawodzi LCP. Według Web Almanac 2025 dobre LCP na telefonach ma 62% serwisów, dobre INP 77%, a dobre CLS 81%. Na komputerach słabiej wypada CLS (72% dobrych wyników wobec 74% dla LCP). Komplet trzech dobrych metryk ma 48% serwisów na telefonach i 56% na komputerach.
Kolejność pracy wyznacza raport w Search Console. Najpierw idą metryki i urządzenia ze statusem „Słaby”, potem ze statusem „Wymaga poprawy”.
Zespół Chrome wskazuje po 3 najskuteczniejsze zmiany dla każdej metryki:
- LCP: główny obraz wykrywalny w kodzie HTML i ładowany z wysokim priorytetem, szybka odpowiedź serwera (CDN), natychmiastowe przejścia między stronami (pamięć bfcache, wstępne renderowanie),
- INP: dzielenie długich zadań JavaScript, usuwanie zbędnych skryptów, mniejsze zmiany wyglądu strony po kliknięciu,
- CLS: wymiary (width i height) dla obrazów, reklam i osadzonych elementów, zgodność strony z pamięcią bfcache, animacje bez właściwości zmieniających układ strony.
Atrybut fetchpriority=”high” przy obrazie LCP ma tylko 17% stron mobilnych z takim obrazem (Web Almanac 2025), więc brak priorytetu dla głównego zdjęcia to częsta luka.
Efekt poprawki widać w ocenie z opóźnieniem, bo dane obejmują 28 dni wstecz. W Search Console po wdrożeniu poprawki da się uruchomić jej sprawdzanie, które trwa 28 dni.
Gdy raport pokazuje słabe grupy adresów, a przyczyna nie jest oczywista, kolejnym krokiem jest diagnoza konkretnego serwisu: szablonów stron, zasobów i skryptów, które odpowiadają za wynik. Taką analizę obejmuje audyt SEO.
Potrzebujesz wsparcia w SEO lub AI Search?
Przeanalizuję sytuację Twojej strony i wskażę, które działania realnie zwiększą jej widoczność.