INP zastąpiło FID w rankingu Core Web Vitals w marcu 2024 i wywróciło niejedną stronę, która wcześniej miała komplet zielonych pasów. W 2026 roku Core Web Vitals to nadal jeden z sygnałów page experience, które Google bierze pod uwagę - a przede wszystkim metryki, które bezpośrednio przekładają się na to, ilu odwiedzających zostaje na stronie zamiast wrócić do wyników wyszukiwania.
W skrócie: Core Web Vitals to trzy mierzalne metryki - LCP (szybkość załadowania głównego elementu), INP (responsywność na interakcje) i CLS (stabilność layoutu) - które Google traktuje jako sygnał jakości strony i które realnie wpływają na współczynnik odrzuceń. Największe, najtańsze usprawnienia to: preload i kompresja hero image dla LCP, ograniczenie ciężkiego JS uruchamianego na kliknięciach dla INP oraz rezerwowanie miejsca na obrazy i reklamy dla CLS. Mierz zarówno w PageSpeed Insights (dane laboratoryjne), jak i w Search Console/CrUX (dane od realnych użytkowników) - to druga liczba decyduje o pozycji.
Dlaczego Core Web Vitals to coś więcej niż techniczny detal
Core Web Vitals wchodzą w skład szerszego zestawu sygnałów page experience, które Google wykorzystuje przy ocenie jakości strony - obok mobilności, bezpiecznego połączenia i braku nachalnych interstitiali. To nie jest pojedynczy, dominujący czynnik rankingowy, ale w konkurencyjnych niszach (e-commerce, usługi lokalne, porównywarki) bywa językiem, który przechyla szalę między dwiema podobnie zoptymalizowanymi stronami pod względem treści i linków.
Znacznie ważniejszy jest efekt uboczny: strona, która ładuje się szybko i nie „skacze” pod palcem, ma niższy współczynnik odrzuceń i wyższą konwersję - niezależnie od tego, czy Google to premiuje wprost. Dlatego optymalizację CWV warto traktować jako projekt UX i biznesowy, a dopiero w drugiej kolejności jako zadanie SEO.
LCP: dlaczego największy element ładuje się wolno
LCP (Largest Contentful Paint) mierzy czas, w którym przeglądarka renderuje największy widoczny element - najczęściej hero image, nagłówek albo baner. Cel: poniżej 2,5 sekundy. Najczęstsze winowajcy to nieskompresowany obraz bez atrybutów width/height, wolny czas odpowiedzi serwera (TTFB) i CSS blokujący renderowanie.
- Dodaj atrybuty width/height (albo aspect-ratio w CSS) do hero image i zastosuj preload w <head>.
- Konwertuj obrazy do WebP lub AVIF - realna oszczędność wagi rzędu 30-60% przy tej samej jakości wizualnej.
- Podepnij hosting pod CDN (np. darmowy plan Cloudflare) - skraca dystans do użytkownika.
- Odłóż niekrytyczny CSS (defer/async), a krytyczne fonty ładuj z preload i font-display: swap.
INP: dlaczego strona wydaje się „ociężała” mimo szybkiego ładowania
INP (Interaction to Next Paint) zastąpiło FID, ponieważ mierzy responsywność całej sesji użytkownika, a nie tylko pierwszego kliknięcia. Liczy się czas między interakcją (klik, tap, wpisanie tekstu) a momentem, w którym przeglądarka faktycznie odświeży ekran - cel to poniżej 200 ms. Najczęstszy zabójca INP to ciężki JavaScript uruchamiany synchronicznie w handlerze onClick: skrypty analityczne, czaty, widgety reklamowe blokujące główny wątek.
Rozwiązanie praktyczne: debounce dla powtarzalnych zdarzeń, przenoszenie niekrytycznych operacji do requestIdleCallback, dzielenie długich zadań na mniejsze fragmenty (long task splitting) i ładowanie skryptów firm trzecich dopiero po pierwszej interakcji użytkownika, a nie od razu przy starcie strony.
CLS: gdy layout skacze pod czytelnikiem
CLS (Cumulative Layout Shift) sumuje nieoczekiwane przesunięcia elementów na stronie - klasyczny przykład to link, w który użytkownik chciał kliknąć, a w tym momencie nad nim wskoczyła reklama. Cel: wynik poniżej 0,1. Główne przyczyny to obrazy bez zdefiniowanych wymiarów, brak zarezerwowanego miejsca na embedy i reklamy oraz web fonty, które po doładowaniu zmieniają metryki tekstu.
- Zawsze ustawiaj width/height albo aspect-ratio dla obrazów i wideo.
- Rezerwuj minimalną wysokość (min-height) dla miejsc na reklamy, embedy i dynamiczne widgety.
- Dla web fontów stosuj font-display: optional lub size-adjust, żeby ograniczyć skok tekstu.
- Nowe elementy DOM wstawiaj nad fold tylko wyjątkowo - najlepiej poniżej ekranu albo po interakcji użytkownika.
| Metryka | Dobry wynik | Wymaga poprawy | Słaby wynik |
|---|---|---|---|
| LCP (szybkość ładowania) | < 2,5 s | 2,5-4,0 s | > 4,0 s |
| INP (responsywność) | < 200 ms | 200-500 ms | > 500 ms |
| CLS (stabilność layoutu) | < 0,1 | 0,1-0,25 | > 0,25 |
Jak mierzyć: dane laboratoryjne kontra dane od realnych użytkowników
PageSpeed Insights to dobry punkt startowy - pokazuje wynik laboratoryjny (symulowany test na konkretnym urządzeniu i łączu) oraz, jeśli strona ma wystarczający ruch, dane terenowe z CrUX (Chrome User Experience Report) zebrane od realnych odwiedzających w ostatnich 28 dniach. To właśnie dane terenowe, a nie wynik z Lighthouse, są tym, co Google faktycznie bierze pod uwagę przy ocenie page experience.
Do głębszej analizy warto sięgnąć po WebPageTest.org (szczegółowy wodospad ładowania zasobów) oraz zakładkę Performance w Chrome DevTools, gdzie widać dokładnie, który skrypt blokuje główny wątek. Jeśli strona generuje spory ruch, dashboard CrUX albo narzędzie typu SpeedCurve pozwala śledzić trend w czasie, zamiast jednorazowego pomiaru.
WordPress: najszybsza droga do zielonych pasów
Na WordPressie większość quick winów da się osiągnąć bez ingerencji w kod, jedną dobrze skonfigurowaną wtyczką cache. WP Rocket (płatny) i Perfmatters (płatny) to sprawdzone, kompleksowe rozwiązania łączące cache, minifikację, lazy load i optymalizację obrazów w jednym panelu. Jeśli hosting działa na serwerze LiteSpeed, darmowa wtyczka LiteSpeed Cache potrafi dać porównywalny efekt bez dodatkowych kosztów.
Wskazówka: Testuj na realnym telefonie i przy throttlingu 4G w Chrome DevTools, nie tylko na biurowym Wi-Fi - PageSpeed Insights ocenia domyślnie wersję mobilną, a różnica w wyniku między szybkim łączem a realnym 4G bywa drastyczna.
Częsty błąd: instalowanie dwóch wtyczek cache jednocześnie (np. wbudowanego cache hostingu razem z WP Rocket) - zamiast przyspieszać, zaczynają ze sobą kolidować i psuć CLS przez podwójne ładowanie zasobów. Po każdej zmianie konfiguracji zrób nowy pomiar, zanim wprowadzisz kolejną.
Kluczowe wnioski
- LCP < 2,5 s, INP < 200 ms, CLS < 0,1 - to progi „dobrego” wyniku dla wszystkich trzech metryk.
- Hero image z preload, poprawnymi wymiarami i formatem WebP/AVIF daje największy, najtańszy zysk dla LCP.
- Ciężki JavaScript uruchamiany na kliknięciu (analytics, czaty, widgety) to najczęstszy zabójca INP - odkładaj go w czasie.
- Zdefiniowane wymiary obrazów i zarezerwowane miejsce na reklamy/embedy eliminują większość problemów z CLS.
- Liczy się wynik terenowy z CrUX/Search Console, nie tylko laboratoryjny wynik z PageSpeed Insights czy Lighthouse.
Najczęściej zadawane pytania
Czym różni się INP od dawnego FID?
FID mierzył opóźnienie tylko pierwszej interakcji użytkownika ze stroną. INP ocenia responsywność wszystkich interakcji w trakcie całej wizyty, dlatego jest znacznie trudniejszą metryką do „naciągnięcia” - pokazuje realny komfort korzystania ze strony, nie tylko pierwsze wrażenie.
Czy Core Web Vitals to bezpośredni czynnik rankingowy w Google?
Tak, wchodzą w skład sygnałów page experience, ale to jeden z wielu czynników obok treści, linków i intencji wyszukiwania. W praktyce najczęściej decydują o kolejności między stronami, które są już porównywalnie dobre pod względem treści.
Jak długo trzeba czekać, żeby zobaczyć poprawę w danych CrUX?
Dane terenowe w CrUX opierają się na kroczącym oknie 28 dni realnego ruchu, więc pełny efekt zmian widać dopiero po miesiącu. Wynik w PageSpeed Insights czy Lighthouse zmienia się od razu, ale to dane laboratoryjne, nie to, co widzi Google w rankingu.
Czy wtyczki cache wystarczą, żeby naprawić Core Web Vitals na WordPressie?
W większości przypadków tak, jeśli chodzi o LCP i część CLS - cache, minifikacja i optymalizacja obrazów rozwiązują najczęstsze problemy. INP bywa trudniejsze, bo często wynika z konkretnych wtyczek lub skryptów firm trzecich, które trzeba zidentyfikować i ograniczyć ręcznie.
Co jest ważniejsze: wynik w PageSpeed Insights czy dane z Search Console?
Dane z Search Console (raport Podstawowe wskaźniki internetowe) i CrUX pochodzą od realnych użytkowników i to one odzwierciedlają to, co widzi Google przy ocenie strony. PageSpeed Insights jest świetne do szybkiej diagnozy przyczyn, ale sam wynik laboratoryjny nie jest tym, co trafia do rankingu.
Czy warto gonić za wynikiem 100/100 w PageSpeed Insights?
Zwykle nie - różnica między wynikiem 85 a 100 rzadko przekłada się na odczuwalną różnicę dla użytkownika czy pozycję w wyszukiwarce, a bywa bardzo czasochłonna. Sensowniej skupić się na przejściu progów „dobry wynik” dla LCP, INP i CLS niż na maksymalizacji ostatnich punktów.
Potrzebujesz wsparcia z tematu tego artykułu?
Zobacz: Projektowanie Stron
Komentarze