Core Web Vitals
Zestaw wskaźników Google mierzących UX: LCP (ładowanie), INP (interaktywność) i CLS (stabilność layoutu). Wpływają na ranking.
Kontekst: dlaczego Google zdecydowało się mierzyć UX?
Przez lata Google rankowało strony przede wszystkim na podstawie relevantności treści i profilu linków. Szybkość strony była czynnikiem rankingowym od 2010 roku, ale nie istniała standaryzowana miara doświadczenia użytkownika. W maju 2020 roku Google ogłosiło Core Web Vitals — zestaw trzech konkretnych, mierzalnych wskaźników UX, które miały wejść jako oficjalne sygnały rankingowe. Algorytm Page Experience Update, wdrożony w 2021 roku, uczynił to oficjalnym.
Decyzja miała jeden cel: skłonić webmasterów do inwestowania w realną jakość użytkowania strony, a nie tylko w optymalizację treści pod kątem robotów. Strona, która ładuje się 8 sekund i „skacze" podczas renderowania, nie zasługuje na wysoką pozycję — bez względu na jakość treści.
Trzy metryki Core Web Vitals
| Metryka | Co mierzy | Dobry wynik | Wymaga poprawy | Słaby |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | Czas załadowania największego widocznego elementu (obraz, blok tekstu) | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP — Interaction to Next Paint | Responsywność na interakcje użytkownika (kliknięcia, tapnięcia) | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Stabilność wizualna — czy elementy „skaczą" podczas ładowania | ≤ 0,1 | 0,1–0,25 | > 0,25 |
LCP w szczegółach — co spowalnia ładowanie głównego elementu?
LCP mierzy czas do załadowania największego widocznego elementu w viewporcie użytkownika — zwykle jest to główne zdjęcie sekcji hero, duży nagłówek lub baner. Najczęstsze przyczyny słabego LCP to: niezoptymalizowane obrazy (zbyt duże pliki, brak WebP/AVIF), wolny serwer lub hosting (wysokie TTFB — Time to First Byte), JavaScript blokujący renderowanie (render-blocking scripts w sekcji head) oraz CSS blokujący renderowanie (duże arkusze stylów bez podziału krytycznego CSS). Poprawa LCP często zaczyna się od optymalizacji obrazu hero i wyboru lepszego hostingu — dwie zmiany, które mogą przesunąć wskaźnik z czerwonego do zielonego.
INP — dlaczego jest najtrudniejszy do naprawienia?
INP mierzy opóźnienie między akcją użytkownika (kliknięcie, tapnięcie, naciśnięcie klawisza) a momentem, gdy przeglądarka wyrenderuje odpowiedź wizualną. Główny wróg INP todługie zadania JavaScript (Long Tasks) — skrypty, które monopolizują wątek główny przeglądarki na ponad 50 ms. Efektem jest „zamrożony" interfejs — użytkownik klika, ale nic się nie dzieje.
Naprawienie INP wymaga często głębokiej pracy z kodem JS: dzielenia długich zadań na mniejsze (chunking), odkładania nieistotnych operacji (deferring), usuwania zbędnych skryptów (analityki, widżetów społecznościowych, chatbotów) i optymalizacji event handlerów. To praca dla deweloperów, nie wystarczy sama konfiguracja WordPressa czy zmiana motywu.
CLS — skaczące przyciski i frustracja użytkownika
CLS mierzy sumę nieoczekiwanych przesunięć layoutu podczas ładowania strony — wyrażoną jako bezwymiarowa liczba od 0 (brak przesunięć) do wartości powyżej 1 (ekstremalne skakanie). Typowe przyczyny: obrazy bez zdefiniowanych atrybutów width i height(przeglądarka nie wie ile miejsca zarezerwować przed załadowaniem), reklamy wstrzykiwane dynamicznie bez placeholder o stałym rozmiarze, czcionki webowe powodujące FOUT (Flash of Unstyled Text) i elementy wczytywane asynchronicznie bez rezerwacji miejsca.
Jak mierzyć Core Web Vitals?
Google Search Console — zakładka „Komfort użytkowania strony" (Core Web Vitals) pokazuje dane z rzeczywistych odwiedzin użytkowników (CrUX — Chrome User Experience Report). To dane polowe (field data) — najważniejsze, bo odzwierciedlają prawdziwe doświadczenie użytkownika.
PageSpeed Insights (pagespeed.web.dev) — łączy dane polowe CrUX z danymi laboratoryjnymi (symulacja), dostarcza konkretnych rekomendacji naprawczych z priorytetem wpływu.
Chrome DevTools — zakładka Performance i Lighthouse, dane laboratoryjne, przydatne do debugowania konkretnych problemów z LCP, INP i CLS.
web-vitals JavaScript library — możliwość zbierania danych CWV bezpośrednio ze swojej strony i wysyłania do Google Analytics lub innego systemu analitycznego.
FAQ — Core Web Vitals
Czy Core Web Vitals są czynnikiem rankingowym?
Tak — oficjalnie od aktualizacji Page Experience w 2021 roku. Google jasno komunikuje, że CWV wchodzi do zestawu sygnałów rankingowych jako tiebreaker przy stronach o podobnej relevantności. W praktyce: bardzo słabe CWV mogą pogorszyć pozycje, ale same dobre wyniki CWV nie wywindują słabej treści na szczyt. Technical SEO i CWV to fundament — budowanie na nim wymaga dobrej treści i linków.
Jak szybko po naprawieniu CWV poprawią się pozycje?
Google zbiera dane CWV z 28-dniowego okna czasowego (Rolling Average). Oznacza to, że nawet po natychmiastowej naprawie technicznej, poprawa w raportach Google Search Console pojawi się po 28 dniach od wdrożenia zmian. Efekty rankingowe mogą zająć kolejne kilka tygodni.
Czy CWV jest mierzony dla wersji mobilnej czy desktopowej?
Dane CWV są zbierane oddzielnie dla mobile i desktop — i Google w rankingach bierze pod uwagę wersję mobilną (ze względu na mobile-first indexing). Jeśli Twoja strona ma dobre CWV na desktop, ale słabe na mobile — to te drugie decydują o rankingach. Testuj zawsze obie wersje.