„Zielony pasek” w PageSpeed Insights cieszy oko, ale nie zawsze przekłada się na pozycje – i to jedno z najczęstszych nieporozumień wokół Core Web Vitals. Liczy się nie wynik z testu laboratoryjnego, lecz to, jak Twoją stronę odczuwają realni użytkownicy. Ten przewodnik pokazuje, jak diagnozować i naprawiać trzy wskaźniki CWV – LCP, INP i CLS – tak, by poprawić jednocześnie ranking i konwersję.
To artykuł z klastra zaawansowanej optymalizacji technicznej SEO – jeśli szukasz szerszego kontekstu technicznego, zacznij od huba.
Czym są Core Web Vitals i dlaczego są czynnikiem rankingowym Google?
Core Web Vitals (CWV) to trzy wskaźniki, którymi Google mierzy realne doświadczenie użytkownika na stronie: LCP (szybkość ładowania głównego elementu), INP (responsywność na interakcje) i CLS (stabilność układu). Są częścią oceny Page Experience i wpływają na ranking – a jednocześnie bezpośrednio przekładają się na konwersję.
Google potwierdza, że Core Web Vitals są sygnałem rankingowym – choć sygnałem o umiarkowanej wadze, działającym najmocniej jako „rozstrzygacz” między stronami o zbliżonej jakości treści. Ale ranking to tylko połowa historii. Druga, ważniejsza dla biznesu, to obrona współczynnika konwersji: użytkownicy porzucają sesje przy wolnym ładowaniu, nieresponsywnym interfejsie i skaczącym układzie. Optymalizując CWV, jednocześnie bronisz pozycji i sprzedaży.
Wartości progowe, do których dążymy:
| Wskaźnik | Co mierzy | Cel (dobry wynik) |
|---|---|---|
| LCP | Szybkość ładowania głównego elementu | ≤ 2,5 s |
| INP | Responsywność na interakcje | ≤ 200 ms |
| CLS | Stabilność wizualna układu | ≤ 0,1 |
LCP (Largest Contentful Paint): diagnostyka i optymalizacja
LCP mierzy czas, po którym renderuje się największy element widoczny w pierwszym oknie – zwykle główna grafika, baner hero albo duży blok tekstu. To wskaźnik odczuwalnej szybkości: moment, w którym użytkownik uznaje, że strona „się załadowała”.
Najczęstsze problemy z LCP: grafika, TTFB i renderowanie blokujące
Trzy źródła odpowiadają za większość słabych wyników LCP. Pierwsze to ciężkie grafiki – nieskompresowane, w przestarzałych formatach, bez wymiarów. Drugie to wolny czas odpowiedzi serwera (TTFB) – zanim cokolwiek się załaduje, przeglądarka czeka na pierwszy bajt od serwera. Jeśli TTFB jest wysoki, problem jest po stronie hostingu, backendu lub braku cache – a wykryjesz go najpewniej w analizie logów serwerowych. Trzecie to renderowanie blokujące – pliki CSS i JS, które przeglądarka musi przetworzyć, zanim pokaże treść.
Techniki naprawy LCP: preload, priority hints i formaty WebP/AVIF
Konkretne dźwignie poprawy LCP: przejście na nowoczesne formaty grafik WebP/AVIF (kilkukrotnie mniejszy rozmiar przy tej samej jakości), wstępne ładowanie kluczowego zasobu (preload) i nadanie mu wysokiego priorytetu (priority hints), odroczenie nieistotnych skryptów, wdrożenie cache i CDN dla skrócenia TTFB oraz eliminacja zasobów blokujących render. Cel: największy element pojawia się poniżej 2,5 sekundy.
INP (Interaction to Next Paint): nowa era responsywności (następca FID)
To najważniejsza zmiana ostatnich lat w Core Web Vitals. W marcu 2024 wskaźnik INP zastąpił dawny FID jako oficjalny Core Web Vital – i nie była to kosmetyka.
INP (Interaction to Next Paint) mierzy responsywność strony przez cały czas wizyty: ile czasu mija od interakcji użytkownika (kliknięcia, dotyku) do widocznej reakcji interfejsu. W odróżnieniu od FID, który oceniał tylko pierwszą interakcję, INP bierze pod uwagę wszystkie – dlatego znacznie surowiej obnaża ciężki JavaScript.
FID mierzył jedynie opóźnienie wejścia przy pierwszym kliknięciu – i niemal każda strona zdawała ten egzamin. INP ocenia każdą interakcję w trakcie sesji: rozwinięcie menu, filtr w sklepie, dodanie do koszyka. Wąskim gardłem są tu zwykle długie zadania (Long Tasks) JavaScriptu, które blokują główny wątek przeglądarki – przez co interfejs „zawiesza się” na ułamek sekundy po kliknięciu.
Jak zredukować opóźnienia INP – optymalizacja wątku głównego
Klucz to odciążenie głównego wątku: dzielenie długich zadań JavaScriptu na mniejsze, usuwanie nieużywanego kodu, odraczanie skryptów innych firm (czaty, analityka, reklamy) i ograniczanie pracy wykonywanej przy interakcji. To obszar mocno powiązany z architekturą frontendu – dlatego rozwijamy go w artykule o JavaScript SEO (SSR vs CSR). Im mniej JavaScriptu blokuje wątek główny, tym niższy INP i płynniejsze działanie strony.
CLS (Cumulative Layout Shift): stabilność wizualna a doświadczenia użytkownika
CLS mierzy, jak bardzo „skacze” układ podczas ładowania. Każdy zna to z autopsji: chcesz kliknąć przycisk, w ostatniej chwili doładowuje się baner, układ przeskakuje i klikasz w coś innego. To frustracja użytkownika i – w sklepie – realna utrata konwersji przez przypadkowe kliknięcia.
Eliminacja przesunięć układu: wymiary, fonty i dynamiczne treści
Najczęstsze przyczyny i ich naprawa: brak wymiarów obrazów i elementów osadzonych (rozwiązanie: zawsze deklaruj width i height albo rezerwuj miejsce przez CSS), fonty powodujące przeskok tekstu przy ładowaniu (zjawiska FOIT/FOUT – opanujesz je przez font-display i preload fontu) oraz dynamiczne treści wstrzykiwane nad istniejącą zawartością (banery, reklamy – rezerwuj dla nich miejsce z góry). Cel: CLS poniżej 0,1.
Dane laboratoryjne vs dane rzeczywiste (Field Data): rola raportu CrUX
To rozróżnienie wyjaśnia największe nieporozumienie wokół CWV. Dane laboratoryjne (Lighthouse, zakładka „Lab” w PageSpeed Insights) to pomiar symulowany, w kontrolowanych warunkach – przydatny do diagnozy i debugowania. Dane rzeczywiste (Field Data) pochodzą z raportu CrUX (Chrome User Experience Report) – to zagregowane pomiary od prawdziwych użytkowników Chrome, na ich urządzeniach i łączach.
I tu pułapka: to dane rzeczywiste (CrUX), a nie laboratoryjne, liczą się dla rankingu i pokazują się w Google Search Console. Dlatego „zielony pasek” w pojedynczym teście Lighthouse nie oznacza sukcesu – możesz mieć świetny wynik laboratoryjny i słabe pole, bo realni użytkownicy wchodzą z wolniejszych urządzeń. Zawsze weryfikuj efekt w danych rzeczywistych, nie tylko w teście.
Narzędzia do analizy CWV
Komplet, który wystarcza do pełnej diagnozy:
- PageSpeed Insights – łączy dane laboratoryjne i rzeczywiste (CrUX) dla pojedynczego URL, z konkretnymi rekomendacjami. Metodykę pomiaru opisuje dokumentacja web.dev.
- Google Search Console – raport Core Web Vitals dla całego serwisu, pogrupowany po typach stron; pokazuje skalę problemu na danych rzeczywistych. Zasady opisuje Google Search Central.
- Chrome DevTools – szczegółowa diagnoza wątku głównego, Long Tasks i renderowania (zakładki Performance i Lighthouse).
Wpływ Core Web Vitals na konwersję w e-commerce
W sklepie internetowym każdy z trzech wskaźników ma bezpośrednie przełożenie na sprzedaż. Wolny LCP to klienci, którzy wychodzą przed załadowaniem listy produktów. Wysoki INP to frustracja przy filtrowaniu i dodawaniu do koszyka – im więcej interakcji wymaga proces zakupowy, tym mocniej INP decyduje o płynności. CLS to przypadkowe kliknięcia i porzucone koszyki. Optymalizacja CWV to nie kosmetyka pod algorytm – to obrona przychodu. Dlatego traktujemy ją jako integralną część pozycjonowania stron i optymalizacji technicznej.
FAQ – Core Web Vitals w praktyce
Jak poprawić wynik LCP powyżej 2,5 sekundy?
Zacznij od trzech źródeł: skompresuj i podaj grafiki w formatach WebP/AVIF, skróć czas odpowiedzi serwera (cache, CDN, lepszy hosting) i usuń zasoby blokujące renderowanie. Kluczowy element widoku warto wstępnie załadować (preload) z wysokim priorytetem.
Czym różni się INP od FID i jak go zmierzyć?
FID mierzył tylko opóźnienie pierwszej interakcji; INP ocenia responsywność wszystkich interakcji przez całą wizytę i jest surowszy. INP zastąpił FID w marcu 2024. Zmierzysz go w PageSpeed Insights (dane rzeczywiste) i Chrome DevTools.
Czy słabe Core Web Vitals wpływają na pozycję w Google?
Tak, choć z umiarkowaną wagą – najmocniej jako rozstrzygacz między stronami o zbliżonej jakości treści. Ważniejszy bywa jednak wpływ na konwersję: słabe wskaźniki zwiększają porzucanie sesji.
Jak naprawić CLS bez ingerencji w wygląd strony?
Najczęściej wystarczy zadeklarować wymiary obrazów i elementów osadzonych, zarezerwować miejsce dla treści doładowywanych dynamicznie i ustawić poprawne ładowanie fontów. To zmiany techniczne, niewidoczne dla użytkownika, które eliminują przeskoki układu.
Dlaczego mam zielony wynik w teście, a problem w Search Console?
Bo test (Lighthouse) to dane laboratoryjne, a Search Console pokazuje dane rzeczywiste z raportu CrUX – od użytkowników na różnych, często wolniejszych urządzeniach. Dla rankingu liczą się dane rzeczywiste, więc zawsze weryfikuj efekt na nich.
Podsumowanie
Core Web Vitals to nie wyścig o zielony pasek, lecz realne doświadczenie użytkownika mierzone na trzech osiach: szybkości (LCP), responsywności (INP) i stabilności (CLS). Najważniejsza zmiana to INP w miejsce FID – wskaźnik, który surowo rozlicza ciężki JavaScript. Optymalizuj na danych rzeczywistych (CrUX), nie tylko laboratoryjnych, i pamiętaj, że każda poprawa CWV to jednocześnie obrona konwersji.
Chcesz wiedzieć, które wskaźniki ciągną Twoją stronę w dół i co konkretnie je psuje? W SEONIM diagnozujemy Core Web Vitals na danych rzeczywistych w ramach technicznego audytu SEO i dajemy listę poprawek uszeregowaną wg wpływu na wynik. Napisz do nas – sprawdzimy Twój serwis bez zobowiązań.
