W tym poradniku dowiesz się, czym są Core Web Vitals, jakie mają progi i jak je poprawić w 6 krokach. Core Web Vitals to trzy metryki Google, które mierzą u prawdziwych użytkowników ładowanie strony (LCP), reakcję na interakcję (INP) i stabilność układu (CLS). Kroki: raport w Search Console, PageSpeed Insights, poprawa LCP, INP i CLS, walidacja.
Poradnik jest dla właściciela strony i początkującego SEO-wca, który chce sam znaleźć przyczynę słabych wyników. Progi, nazwy raportów i dokumentacja Google w poradniku są aktualne na październik 2026.
Część przykładów pochodzi z audytu bynajmniej.pl z 14.10.2026 (crawl Screaming Frog na 441 wewnętrznych URL-ach i pomiar czasu odpowiedzi serwera). Wyników CrUX dla bynajmniej.pl w tym audycie nie mierzyłem, więc nie podaję ocen LCP, INP i CLS tego bloga.
Core Web Vitals w skrócie: trzy metryki i progi
Core Web Vitals to według dokumentacji Google Search Central zestaw metryk mierzących rzeczywiste doświadczenie użytkownika w trzech obszarach: szybkość ładowania, interaktywność i stabilność wizualna strony. Core Web Vitals są podzbiorem szerszej inicjatywy Web Vitals, który według web.dev dotyczy wszystkich stron internetowych.
Progi trzech metryk Core Web Vitals w raporcie Core Web Vitals w Google Search Console wyglądają tak:
| Metryka Core Web Vitals | Co mierzy | Dobry | Do poprawy | Słaby |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | czas wyrenderowania największego elementu w widoku, zwykle obrazka lub bloku tekstu | ≤ 2,5 s | ≤ 4 s | > 4 s |
| INP (Interaction to Next Paint) | czas od kliknięcia, dotknięcia lub naciśnięcia klawisza do narysowania kolejnej klatki | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | suma nieoczekiwanych przesunięć układu strony | ≤ 0,1 | ≤ 0,25 | > 0,25 |
Próg Core Web Vitals liczy się na 75. percentylu odsłon, osobno dla urządzeń mobilnych i komputerów. Strona przechodzi ocenę dopiero wtedy, gdy wszystkie trzy metryki mieszczą się w progu „dobry” dla 75% wizyt. Zasadę 75. percentyla opisuje przewodnik Web Vitals na web.dev.
Metryka INP zastąpiła FID (First Input Delay) jako Core Web Vital 12 marca 2024 roku i tego samego dnia FID zniknął z Google Search Console. Polskie poradniki o Core Web Vitals w części nadal opisują FID z progami 100 i 300 ms. Takie progi są nieaktualne od ponad dwóch lat.
Czy Core Web Vitals wpływają na pozycje w Google
Core Web Vitals wpływają na pozycje, ale nie decydują o nich. Dokumentacja Google o page experience (aktualizacja z 22.09.2026) mówi, że Core Web Vitals „są używane przez systemy rankingowe”, a dobre wyniki w raportach „nie gwarantują”, że strony będą na samej górze wyników. Ta sama dokumentacja dodaje, że Google zawsze pokazuje najtrafniejszą treść, nawet jeśli page experience strony jest słabe.
Systemy rankingowe Google według dokumentacji page experience oceniają treść głównie na poziomie pojedynczej strony, choć część ocen dotyczy całej witryny. Moim zdaniem Core Web Vitals warto poprawiać przede wszystkim dla użytkowników, a dopiero potem dla rankingu, bo przy dwóch równie trafnych tekstach wygrywa ten, który ładuje się bez czekania.
Jak poprawić Core Web Vitals w 6 krokach
Poprawa Core Web Vitals zaczyna się od danych polowych, a kończy na walidacji w Search Console:
- Otwórz raport Core Web Vitals w Google Search Console i znajdź grupy słabych URL-i.
- Sprawdź przykładowy URL w PageSpeed Insights i porównaj dane polowe z wynikiem Lighthouse.
- Popraw LCP: serwer, priorytet i waga obrazka LCP.
- Popraw INP: długie zadania JavaScript i rozmiar DOM.
- Popraw CLS: wymiary obrazków, miejsce na reklamy i fonty.
- Uruchom walidację poprawki w raporcie Core Web Vitals i odczekaj 28 dni.
Krok 1. Otwórz raport Core Web Vitals w Google Search Console
Raport Core Web Vitals w Google Search Console pokazuje dane polowe z Chrome User Experience Report (CrUX) za ostatnie 28 dni, osobno dla wersji mobilnej i komputerowej. Raport grupuje URL-e o podobnym doświadczeniu użytkownika i nadaje status całej grupie, a nie pojedynczym adresom. Opis działania raportu jest w pomocy Search Console.
Status grupy URL-i w raporcie Core Web Vitals wyznacza najgorsza metryka dla danego typu urządzenia. Grupa z dobrym LCP i CLS, ale słabym INP dostaje status „Słaby”. Raport obejmuje tylko zindeksowane URL-e, a grupa bez wystarczającej liczby danych dla LCP i CLS w ogóle się w nim nie pojawia, chyba że dane ma cały origin (protokół, host i port).
Pracę z raportem Core Web Vitals zaczynam od wersji mobilnej, bo na telefonach odsetek dobrych wyników jest niższy niż na komputerach. Szerzej o raportach Search Console piszę w poradniku Google Search Console: jak korzystać.
Krok 2. Porównaj dane polowe i laboratoryjne w PageSpeed Insights
PageSpeed Insights pokazuje dwa rodzaje danych. Dane polowe z CrUX pochodzą od prawdziwych użytkowników Chrome z ostatnich 28 dni. Dane laboratoryjne z Lighthouse to symulacja jednego wczytania strony na jednym urządzeniu przy stałych warunkach sieci, która według dokumentacji PageSpeed Insights służy do debugowania.
| Cecha | Dane polowe (CrUX) | Dane laboratoryjne (Lighthouse) |
|---|---|---|
| Źródło | prawdziwi użytkownicy Chrome | symulowane wczytanie strony |
| Okres | ostatnie 28 dni | jeden test w danej chwili |
| INP | mierzony | niemierzony, zastępczo TBT (Total Blocking Time) |
| Do czego | ocena Core Web Vitals i raport w GSC | szukanie przyczyny i test poprawki przed wdrożeniem |
| Brak danych | fallback do danych całego originu, potem brak danych | zawsze dostępne |
Lighthouse nie mierzy INP, bo w teście laboratoryjnym nikt nie klika w stronę. Według web.dev Lighthouse używa zamiast INP metryki Total Blocking Time. Z tego powodu wynik Lighthouse w PageSpeed Insights traktuję jako wskazówkę, gdzie szukać problemu, a dane polowe CrUX jako właściwą ocenę.
PageSpeed Insights bez wystarczającej liczby wizyt dla danego URL-a pokazuje dane polowe całego originu. Mała strona firmowa często nie ma danych polowych nawet dla originu i wtedy zostaje tylko Lighthouse.
Krok 3. Popraw LCP: serwer, priorytet i waga obrazka
LCP to najczęściej oblewana metryka Core Web Vitals. Według Web Almanac 2025 (dane CrUX z lipca 2025) dobre LCP ma 62% witryn na urządzeniach mobilnych, a obrazek jest elementem LCP na 76% stron mobilnych. Przewodnik Optimize LCP na web.dev dzieli czas LCP na cztery części i podaje orientacyjny udział każdej z nich:
| Część LCP | Co obejmuje | Zalecany udział w LCP |
|---|---|---|
| TTFB (Time to First Byte) | czas do pierwszego bajtu dokumentu HTML | ok. 40% |
| Opóźnienie wczytania zasobu | czas od TTFB do startu pobierania obrazka LCP | poniżej 10% |
| Czas wczytania zasobu | pobieranie obrazka LCP | ok. 40% |
| Opóźnienie renderowania elementu | czas od pobrania do wyświetlenia elementu LCP | poniżej 10% |
Poprawa LCP według przewodnika web.dev sprowadza się do czterech działań:
- Skróć TTFB. Według web.dev dobry TTFB to 0,8 s lub mniej, a powyżej 1,8 s osiągnięcie LCP w 2,5 s jest trudne albo niemożliwe. Według web.dev czas pobierania zasobów najskuteczniej skraca CDN, a TTFB moim zdaniem najczęściej poprawia cache stron i szybszy hosting.
- Dodaj
fetchpriority="high"do obrazka LCP, a zasób niewidoczny w HTML (np. tło z CSS) wczytaj przez<link rel="preload">. - Usuń
loading="lazy"z obrazka LCP. Przewodnik web.dev mówi wprost, żeby nigdy nie stosować lazy loadingu dla obrazka LCP, a według Web Almanac 2025 robi tak ok. 17% stron mobilnych. - Zmniejsz wagę obrazka LCP: format WebP lub AVIF, kompresja i rozmiar dopasowany do ekranu przez
srcset.
WordPress od wersji 6.3 sam dodaje fetchpriority="high" do obrazka, który uznaje za element LCP, i nie lazy-loaduje go. Według analizy zespołu WordPress Core odsetek stron lazy-loadujących obrazek LCP spadł po wersji 6.3 z 27–28% do 9–10% na motywach klasycznych i z 17–29% do 5–8% na motywach blokowych. Ta sama analiza podaje, że heurystyka WordPressa trafia w element LCP w ok. 50% przypadków, więc obrazek LCP warto sprawdzić ręcznie w PageSpeed Insights.
W audycie bynajmniej.pl (WordPress, motyw Twenty Twenty-Five) czas do pierwszego bajtu wyniósł ok. 190 ms (mediana 3 prób z Polski, pomiar laboratoryjny), a dokument HTML ma 116 KB. Crawl Screaming Frog znalazł za to 6 obrazków ponad 2 MB, m.in. pliki PNG wygenerowane w ChatGPT w 2025 roku po 2,5–3,7 MB, i 26 obrazków ponad 100 KB. Jeśli taki obrazek jest elementem LCP wpisu, kompresja daje więcej niż jakakolwiek zmiana na serwerze.
W tym samym crawlu bynajmniej.pl 10 URL-i odpowiadało dłużej niż 1000 ms i były to archiwa tagów i kategorii. Wolne odpowiedzi serwera szkodzą LCP, a przy okazji ograniczają tempo skanowania, o czym piszę w tekście o crawl budget.
Krok 4. Popraw INP: długie zadania JavaScript
INP mierzy opóźnienie interakcji użytkownika ze stroną w trakcie całej wizyty, a nie tylko pierwszej, jak dawny FID. Przewodnik Optimize INP na web.dev dzieli każdą interakcję na trzy fazy: opóźnienie wejścia (input delay), czas przetwarzania callbacków (processing duration) i opóźnienie prezentacji (presentation delay), czyli czas do narysowania kolejnej klatki.
- Znajdź wolne interakcje. Web.dev zaleca dane z narzędzia RUM (Real User Monitoring), a bez RUM dane CrUX w PageSpeed Insights.
- Podziel długie zadania. Według web.dev długie zadanie to każde zadanie dłuższe niż 50 ms, a do oddawania głównego wątku służy
scheduler.yield(). Na październik 2026scheduler.yield()działa w Chrome i Edge od wersji 129 i w Firefoksie od wersji 142, Safari go nie obsługuje, więc potrzebny jest fallback, np.setTimeout. - W callbacku zostaw tylko kod potrzebny do narysowania następnej klatki, a resztę pracy odłóż.
- Zmniejsz DOM i liczbę skryptów zewnętrznych (czaty, widżety, tagi reklamowe), bo duży DOM spowalnia renderowanie po każdej interakcji.
INP to według Web Almanac 2025 najłatwiejsza metryka na komputerach: dobry wynik ma 97% witryn desktopowych i 77% mobilnych. Blog bez ciężkiego JavaScriptu zwykle nie ma problemu z INP. Na bynajmniej.pl cała treść jest w HTML bez JavaScriptu, a kłopoty z INP pojawiają się raczej w sklepach z filtrami, konfiguratorach i stronach z wieloma skryptami reklamowymi.
Krok 5. Popraw CLS: zarezerwuj miejsce na elementy
CLS rośnie, gdy elementy strony przesuwają się po wczytaniu. Przewodnik Optimize CLS na web.dev wymienia pięć typowych przyczyn i sposoby ich usunięcia:
| Przyczyna przesunięć układu | Poprawka |
|---|---|
| obrazki i wideo bez wymiarów | atrybuty width i height albo CSS aspect-ratio |
| reklamy, embedy i iframe bez wymiarów | stałe miejsce na slot przez min-height |
| treść wstrzykiwana nad istniejącą treścią (banery, powiadomienia) | miejsce zarezerwowane wcześniej albo treść pod widokiem |
| fonty internetowe podmieniane po wczytaniu | font-display: optional i size-adjust dla fontu zastępczego |
animacje właściwości top i left | animacje przez transform |
Obrazki bez wymiarów są najczęstszym błędem CLS w skali sieci: według Web Almanac 2025 62% stron mobilnych ma co najmniej jeden obrazek bez jawnych wymiarów. Web.dev zaleca też, żeby strona mogła korzystać z pamięci podręcznej bfcache, bo powrót przyciskiem „Wstecz” z bfcache nie generuje ponownych przesunięć układu.
Krok 6. Zwaliduj poprawkę w raporcie Core Web Vitals
Walidację poprawki uruchamia się w raporcie Core Web Vitals w Google Search Console przyciskiem „Rozpocznij śledzenie” przy problemie. Według pomocy Search Console walidacja trwa 28 dni, bo tyle obejmuje okno danych CrUX, a ponowne uruchomienie walidacji zaczyna nowy 28-dniowy okres.
Przed uruchomieniem walidacji w Search Console sprawdzam poprawkę w Lighthouse na kilku URL-ach z grupy. Dane polowe z poprawką pojawią się dopiero po kilku tygodniach, a test laboratoryjny od razu pokaże, czy obrazek LCP dostał priorytet i czy zniknęły przesunięcia układu.
Jak wypadają Core Web Vitals w sieci (Web Almanac 2025)
Web Almanac 2025 od HTTP Archive to najnowszy rocznik raportu na październik 2026, oparty na danych CrUX z lipca 2025 i liczony dla witryn (originów), a nie pojedynczych stron:
| Wskaźnik (dobry wynik, % witryn) | Mobile | Desktop |
|---|---|---|
| Wszystkie trzy Core Web Vitals | 48% | 56% |
| LCP | 62% | 74% |
| INP | 77% | 97% |
| CLS | 81% | 72% |
| TTFB (nie jest Core Web Vital) | 44% | 55% |
Odsetek witryn mobilnych z dobrymi Core Web Vitals rośnie według Web Almanac co roku: 36% w 2023, 44% w 2024 i 48% w 2025. Na urządzeniach mobilnych najsłabiej wypada LCP, a CLS jest jedyną metryką, w której mobile wypada lepiej niż desktop.
Czego nie robić przy poprawianiu Core Web Vitals
Wynik 100/100 w Lighthouse to ulubiony zrzut ekranu do raportu dla klienta, tylko raport Core Web Vitals w Search Console tego zrzutu nigdy nie zobaczy. Raport Core Web Vitals opiera się na danych polowych CrUX, a Lighthouse według dokumentacji PageSpeed Insights służy do debugowania, więc tydzień walki o ostatnie 5 punktów w teście laboratoryjnym często nie zmienia statusu grupy URL-i.
- Nie włączaj lazy loadingu dla wszystkich obrazków bez wyjątku, bo lazy loading obrazka LCP wydłuża LCP.
- Nie poprawiaj FID. FID nie jest Core Web Vital od 12 marca 2024 roku.
- Nie oczekuj skoku pozycji po poprawie Core Web Vitals. Dokumentacja Google o page experience mówi, że trafność treści wygrywa ze słabym page experience.
- Nie wierz w „nowe metryki Core Web Vitals 2026” z blogów bez źródła. Na październik 2026 Google wymienia trzy stabilne metryki: LCP, INP i CLS.
Core Web Vitals są jednym z kroków szerszego przeglądu strony, który opisuję w poradniku jak zrobić audyt SEO.
FAQ: najczęstsze pytania o Core Web Vitals
Jak sprawdzić Core Web Vitals swojej strony?
Core Web Vitals całej witryny sprawdzisz w raporcie Core Web Vitals w Google Search Console, a pojedynczego URL-a w PageSpeed Insights. Oba narzędzia są bezpłatne i pokazują dane polowe CrUX z ostatnich 28 dni.
Czy Core Web Vitals wpływają na SEO?
Core Web Vitals wpływają na SEO, bo według dokumentacji Google Search Central są używane przez systemy rankingowe. Dobre Core Web Vitals nie gwarantują jednak wysokich pozycji, a trafność treści jest ważniejsza.
Co zastąpiło FID w Core Web Vitals?
FID w Core Web Vitals zastąpiła metryka INP (Interaction to Next Paint) 12 marca 2024 roku. Dobry INP to 200 ms lub mniej na 75. percentylu odsłon.
Dlaczego PageSpeed Insights pokazuje inny wynik niż Search Console?
Wynik punktowy w PageSpeed Insights pochodzi z testu laboratoryjnego Lighthouse, a raport Core Web Vitals w Search Console z danych polowych CrUX od prawdziwych użytkowników. Search Console dodatkowo ocenia grupy podobnych URL-i, a nie pojedynczy adres.
Ile trwa poprawa Core Web Vitals w Search Console?
Walidacja poprawki w raporcie Core Web Vitals w Google Search Console trwa 28 dni, bo tyle obejmuje okno danych CrUX. Ponowne uruchomienie walidacji zaczyna nowy 28-dniowy okres.
Co zrobić, gdy PageSpeed Insights nie ma danych polowych?
PageSpeed Insights bez danych polowych dla URL-a pokazuje dane całego originu, a bez danych originu tylko test Lighthouse. Przy małym ruchu zostaje test laboratoryjny Lighthouse i własny pomiar u użytkowników narzędziem RUM.
Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.
Dodaj komentarz