Co to jest Core Web Vitals?
Core Web Vitals (CWV) to trzy metryki wydajności strony, które Google oficjalnie uznało za czynnik rankingowy w 2021 roku w ramach Page Experience Update. Mierzą rzeczywiste doświadczenie użytkownika: jak szybko widzisz główną treść (LCP), czy strona nie skacze podczas ładowania (CLS) i jak szybko reaguje na Twoje kliknięcia (INP). Złe wyniki CWV to podwójny problem: gorsze pozycje w Google i wyższy bounce rate, bo użytkownicy opuszczają wolne strony.
Trzy metryki Core Web Vitals – co mierzą i jakie są progi?
| Metryka | Co mierzy | Dobry wynik | Zły wynik |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Czas załadowania największego elementu widocznego na ekranie (obraz hero, nagłówek H1) | ≤ 2.5s | > 4.0s |
| CLS (Cumulative Layout Shift) | Sumaryczne przesunięcia layoutu podczas ładowania (elementy skaczące) | ≤ 0.1 | > 0.25 |
| INP (Interaction to Next Paint) | Czas odpowiedzi strony na kliknięcie, dotyk lub naciśnięcie klawisza | ≤ 200ms | > 500ms |
LCP – najważniejsza metryka i jak ją poprawić
LCP (Largest Contentful Paint) mierzy czas do wyświetlenia największego widocznego elementu strony. Najczęściej to zdjęcie hero lub duży nagłówek. Dla SEO i UX to kluczowa metryka – użytkownik ocenia szybkość strony właśnie na podstawie tego, kiedy widzi coś znaczącego, nie kiedy zakończyło się całkowite ładowanie.
Najczęstsze przyczyny złego LCP: obraz hero w formacie JPEG bez kompresji serwowany przez serwer zamiast CDN, brak atrybutu `fetchpriority="high"` lub `loading="eager"` na obrazie LCP, zbyt wolny serwer (TTFB powyżej 600ms), renderowanie blokowane przez CSS i JS ładowane w sekcji `<head>`. W Next.js Image component z atrybutem `priority` automatycznie dodaje `fetchpriority="high"` i preload link – dlatego LCP na moich projektach Next.js naturalnie spada poniżej 1.5s.
CLS – dlaczego strony skaczą i jak to naprawić?
CLS powyżej 0.1 oznacza, że podczas ładowania elementy strony przeskakują – tekst, który zacząłeś czytać, nagle przesuwa się w dół bo załadował się baner powyżej. To frustrujące dla użytkownika i karane przez Google. Najczęstsze przyczyny: obrazy bez zdefiniowanych wymiarów width/height (przeglądarka nie wie ile miejsca zarezerwować), czcionki webowe powodujące FOUT (Flash of Unstyled Text), reklamy i embedy ładowane dynamicznie bez rezerwacji przestrzeni.
Rozwiązania: zawsze definiuj width i height na elementach `<img>`, używaj `font-display: swap` dla czcionek zewnętrznych (Google Fonts), rezerwuj przestrzeń dla dynamicznych elementów (min-height na kontenerze przed załadowaniem). W WordPress głównym winowajcą CLS są często wtyczki slidera i pop-upów ładowane bez wymiarów.
Max Mazurkiewicz
FounderTwoja strona ma złe Core Web Vitals i traci pozycje w Google?
Diagnozuję i naprawiam problemy z wydajnością na WordPressie i Next.js. Sprawdź, co możemy zrobić z Twoim PageSpeed.
Zobacz ofertę optymalizacjiINP – nowa metryka, która zastąpiła FID
W marcu 2024 roku Google zastąpiło FID (First Input Delay) metryką INP (Interaction to Next Paint). Różnica jest istotna: FID mierzył tylko czas do pierwszej interakcji, INP mierzy responsywność na wszystkie interakcje przez cały czas korzystania ze strony. Strony z dużą ilością JavaScript, animacjami CSS i ciężkimi widgetami często mają INP powyżej 500ms.
Poprawa INP to przede wszystkim redukcja main thread blocking: code splitting (ładuj JS tylko gdy potrzebny), deferred loading ciężkich komponentów (calendly, chatboty, mapy), i unikanie długich zadań JavaScript (Long Tasks w DevTools). Na WordPressie INP psują najczęściej: załadowane przy starcie pliki JS od wtyczek, które nie oferują lazy loadingu.
Jak mierzyć Core Web Vitals swojej strony?
Najważniejsze jest rozróżnienie między danymi laboratoryjnymi i polowymi. Laboratoryjne (Lighthouse, PageSpeed Insights) to symulacja w kontrolowanych warunkach. Polowe (field data) to rzeczywiste dane od prawdziwych użytkowników, zbierane przez Chrome User Experience Report (CrUX). Google używa danych polowych jako czynnika rankingowego, nie laboratoryjnych.
Najlepsze narzędzia: PageSpeed Insights (psi.web.dev) pokazuje oba typy danych jednocześnie, Google Search Console → Core Web Vitals raport pokazuje które strony mają problemy w prawdziwym ruchu, Chrome DevTools → Performance i Lighthouse dla debugowania konkretnych problemów. Optymalizacja Core Web Vitals zaczyna się od analizy danych polowych w GSC, nie od wyniku Lighthouse, który wielu mylnie traktuje jako jedyną prawdę.
Czy poprawienie CWV realnie poprawia pozycje w Google?
To pytanie, które słyszę często – i odpowiedź jest bardziej niuansowana niż „tak\" lub „nie\". Core Web Vitals są czynnikiem rankingowym, ale tie-breakerowym: przy identycznej jakości treści i profilu linków, strona z lepszymi CWV wygrywa. Jeśli Twoja strona ma słabą treść lub mało linków, poprawienie PageSpeed z 50 do 90 nie wyskoczy Cię z pozycji 40 na pozycję 3.
Jednak pośredni wpływ CWV na SEO jest realny i często ważniejszy niż bezpośredni: szybsza strona = niższy bounce rate = lepsze sygnały użytkownika dla Google, lepszy crawl budget (bot Google eksploruje więcej stron szybszej witryny), wyższy współczynnik konwersji (wyniki biznesowe). Poprawienie CWV rzadko robi cuda samo w sobie, ale zawsze jest wartościową inwestycją w kontekście kompleksowej strategii SEO.