Core Web Vitals 2026: aktualne progi i wpływ na ranking
INP zastąpił FID ponad dwa lata temu, a Google przez ten czas wprowadził kolejne zmiany. Sprawdź aktualne progi Core Web Vitals, co się liczy w rankingu i jak mierzyć te wskaźniki w 2026 roku.
Spis treści
W marcu 2024 Google oficjalnie zastąpiło FID przez INP jako trzeci podstawowy wskaźnik Core Web Vitals. W tym artykule znajdziesz aktualne informacje o tym, co mierzą CWV, jakie wartości Google uznaje za dobre i jak skutecznie poprawiać wyniki w 2026 roku.
Trzy filary Core Web Vitals
Core Web Vitals to trzy wskaźniki, które Google wybrał jako reprezentatywne dla doświadczenia użytkownika na stronie:
- LCP (Largest Contentful Paint) mierzy, kiedy pojawia się największy element widoczny w oknie przeglądarki
- INP (Interaction to Next Paint) mierzy opóźnienie między interakcją użytkownika a widoczną reakcją strony
- CLS (Cumulative Layout Shift) mierzy, jak bardzo elementy strony przesuwają się podczas ładowania
Wszystkie trzy wchodzą w skład sygnałów Page Experience i mają bezpośrednie przełożenie na ranking Google.
LCP: czas ładowania kluczowego elementu
Aktualne progi
| Wynik | Wartość |
|---|---|
| Dobry | poniżej 2,5 s |
| Wymaga poprawy | 2,5–4,0 s |
| Słaby | powyżej 4,0 s |
Co zwykle jest elementem LCP?
Najczęściej jest to główny obraz artykułu lub strony, duży baner, lub blok tekstu w sekcji hero. Google mierzy, kiedy ten element pojawi się w pełni w oknie przeglądarki.
Najczęstsze przyczyny wysokiego LCP:
- obrazy bez optymalizacji (za duże pliki, brak WebP/AVIF, brak lazy loading poza fold)
- blokujące renderowanie skrypty i arkusze CSS ładowane synchronicznie w
<head> - wolny TTFB serwera, który opóźnia cały łańcuch ładowania
- brak prefetchu zasobów krytycznych (
<link rel="preload">)
Praktyczny krok: sprawdź, który element jest sklasyfikowany jako LCP w raporcie PageSpeed Insights. Często jest to obraz, który można zprefetchować lub załadować za pomocą loading="eager" z fetchpriority="high".
INP: reaktywność strony na interakcje
INP zastąpił FID w marcu 2024. Różnica jest istotna: FID mierzył tylko opóźnienie do pierwszej interakcji, INP mierzy opóźnienie przez cały cykl życia strony.
Aktualne progi
| Wynik | Wartość |
|---|---|
| Dobry | poniżej 200 ms |
| Wymaga poprawy | 200–500 ms |
| Słaby | powyżej 500 ms |
Dlaczego INP jest trudniejszy do poprawy niż FID?
FID był stosunkowo prostym wskaźnikiem: jeśli JavaScript nie blokował wątku głównego podczas ładowania strony, wynik był dobry. INP śledzi każdą interakcję klikniecia, klawiatury, dotyku i bierze pod uwagę najgorszy percentyl z pomiaru.
Strony oparte na ciężkich frameworkach JavaScript (React, Next.js z dużą liczbą re-renderów, Vue z synchroniczną logiką) są szczególnie narażone na słabe INP.
Co poprawia INP:
- rozbijanie długich tasków JavaScript na mniejsze (technika “yielding to the main thread”)
- code splitting i lazy loading komponentów, które nie są potrzebne od razu
- unikanie synchronicznych operacji DOM w handlerach zdarzeń
- korzystanie z Web Workers dla obliczeń w tle
CLS: stabilność layoutu
Aktualne progi
| Wynik | Wartość |
|---|---|
| Dobry | poniżej 0,1 |
| Wymaga poprawy | 0,1–0,25 |
| Słaby | powyżej 0,25 |
Najczęstsze przyczyny wysokiego CLS
Banery reklamowe bez zarezerwowanego miejsca to klasyczny winowajca: przeglądarka ładuje stronę, po chwili pojawia się reklama i przesuwa cały content o 200 pikseli w dół.
Inne częste przyczyny:
- czcionki webowe ładowane asynchronicznie (tekst zmienia rozmiar po załadowaniu fontu)
- obrazy bez atrybutów
widthiheight(przeglądarka nie wie, ile miejsca zarezerwować) - dynamicznie wstrzykiwana treść powyżej fold (banery cookies, powiadomienia push, “sticky” elementy)
Jak mierzyć Core Web Vitals?
Google PageSpeed Insights
Najbardziej bezpośrednie narzędzie: wchodzisz na pagespeed.web.dev, podajesz URL i dostajesz dane zarówno z lab (symulowane ładowanie) jak i z field (prawdziwe dane użytkowników z Chrome UX Report).
Dane field są ważniejsze z perspektywy SEO, bo to właśnie na ich podstawie Google ocenia Twoją stronę.
Google Search Console: raport Core Web Vitals
W GSC znajdziesz raport Core Web Vitals, który pokazuje, ile URL-i Twojej strony jest ocenionych jako “Dobre”, “Wymaga poprawy” i “Słabe”. To najlepsze miejsce do priorytetyzowania pracy: zamiast poprawiać każdą podstronę z osobna, widać które szablony stron mają systematyczny problem.
Narzędzie RankVoyager
Audyt Core Web Vitals w RankVoyager pobiera dane z Google PageSpeed Insights API i pokazuje LCP, INP, CLS i FCP dla dowolnego URL bez konieczności rejestracji. Przydatne do szybkiej weryfikacji przed meetingiem z klientem lub po wdrożeniu zmian.
Core Web Vitals a ranking Google w 2026 roku
Google wielokrotnie potwierdzał, że Page Experience, w tym Core Web Vitals, to jeden z sygnałów rankingowych. Nie jest to jednak czynnik nadrzędny: strona z wybitną treścią i słabym LCP wciąż będzie rankować wyżej niż strona z idealnym LCP, ale bez wartościowego contentu.
Praktyczna zasada: Core Web Vitals jest “tiebreakerem”. Jeśli dwie strony mają podobną jakość treści i podobny profil linków, ta z lepszymi CWV ma przewagę. Dlatego optymalizacja CWV ważna jest szczególnie w niszach, gdzie konkurencja jest silna i gdzie strony o podobnej wartości merytorycznej walczą o te same pozycje.
Priorytetyzacja pracy
Zamiast próbować poprawić wszystko naraz, zacznij od LCP. To wskaźnik, który ma największy wpływ na odczuwalne wrażenie z ładowania strony i najczęściej jest najłatwiejszy do poprawy przez optymalizację obrazów i usunięcie blokujących zasobów.
Następnie zajmij się CLS: najczęściej wystarczy dodać width i height do obrazów oraz zarezerwować miejsce na reklamy.
INP zostawiam na koniec, bo jego poprawa wymaga głębszej analizy kodu JavaScript i często dotyka architektury aplikacji.
Zespół RankVoyager
Monitoring SEO i dostępności stron internetowych
Przetestuj RankVoyager za darmo
Dodaj swoją stronę i w kilka minut sprawdź, co działa, a co wymaga poprawy.