Core Web Vitals są obecnie najważniejszym technicznym sygnałem rankingowym Google, a zarazem najsilniejszą obiektywną miarą jakości użytkownika na stronie. Trzy metryki: LCP, INP i CLS, mierzone w danych terenowych CrUX, definiują jak Google ocenia komfort korzystania ze strony. Ten artykuł rozkłada każdą z metryk na czynniki pierwsze: co dokładnie mierzy, jakie ma progi, najczęstsze przyczyny słabych wyników i konkretny plan naprawy. Materiał jest oparty na audytach dla klientów Niemczech, Austrii i Szwajcarii i PL, w których Core Web Vitals są stałym punktem programu.
Czym są Core Web Vitals i dlaczego Google je waży w SEO
Core Web Vitals to zestaw trzech metryk wprowadzonych przez Google w maju 2020 roku jako reakcja na rosnącą frustrację użytkowników wolnymi i niestabilnymi stronami mobilnymi. Maj 2021 to oficjalne włączenie tych metryk do algorytmu Google jako sygnał Page Experience. W marcu 2024 INP zastąpiło dotychczasowe FID jako trzecią metrykę, co wymusiło aktualizację narzędzi i metodologii audytu w całej branży.
Waga Core Web Vitals w rankingach Google jest oceniana na 5 do 10 procent w konkurencyjnych niszach, a w niszach o niskiej konkurencji jako rozstrzygnięcie między stronami o porównywalnym autorytecie i jakości treści. Innymi słowy: Core Web Vitals same w sobie nie wprowadzą strony na top 3 dla trudnej frazy, ale przy 4 stronach o podobnej treści zwykle wygrywa ta z lepszymi metrykami.
Istotne jest rozróżnienie między Core Web Vitals jako czynnikiem rankingowym a Core Web Vitals jako sygnałem doświadczenia użytkownika. Google nie ujawnia dokładnej wagi, ale empirycznie z analiz tysięcy stron wynika, że spadek z poziomu „good” do „poor” w którejkolwiek metryce koreluje z 10 do 30 procent spadkiem CTR i pozycji, niezależnie od formalnego rankingowego wpływu.
Audyt Core Web Vitals jest stałym elementem każdego audytu strony WWW. Bez liczb LCP, INP i CLS rozmowa o wydajności jest oparta na wrażeniach. Z liczbami staje się rozmową inżynierską, w której każde znalezisko ma mierzalny punkt wyjścia i mierzalny cel po wdrożeniu poprawki.
LCP (Largest Contentful Paint): interpretacja
LCP mierzy czas od momentu rozpoczęcia ładowania strony do wyrenderowania największego elementu widocznego na ekranie. Tym elementem jest zwykle obraz hero, główny nagłówek H1, baner z wideo, lub blok z dużym blokiem tekstu na pierwszym ekranie. Google opublikował precyzyjne progi: poniżej 2.5 sekundy to „good”, 2.5-4 sekundy to „needs improvement”, powyżej 4 sekund to „poor”.
W praktyce dla stron WordPress hostowanych na typowym shared hostingu w Polsce typowy punkt wyjścia LCP wynosi 2.8-4.5 sekundy bez optymalizacji. Po pełnym audycie i wdrożeniu szybkich usprawnień schodzimy zwykle do 1.4-2.2 sekundy. U nas w studio LCP wynosi 1.4 sekundy na mobile w danych CrUX, co plasuje stronę w top 10 procent niszy własny WordPress w Polsce.
Najczęstsze przyczyny słabego LCP w audytach: obraz hero bez fetchpriority=”high” oraz bez preload (pojedynczo największa przyczyna, około 40 procent przypadków), wolny czas odpowiedzi serwera powyżej 600 ms (typowo problem shared hostingu z LiteSpeed Cache wyłączonym lub źle skonfigurowanym), CSS blokujący renderowanie i synchroniczne czcionki internetowe ładowane przed pierwszym malowaniem, skrypty zewnętrzne blokujące główny wątek w pierwszej sekundzie (Google Tag Manager, moduły czatu typu Tawk lub Crisp).
Plan naprawy LCP w pięciu krokach: dodaj fetchpriority=”high” na obraz hero i preload w sekcji head, skonwertuj obraz hero do WebP lub AVIF (redukcja 60-80 procent rozmiaru pliku), dodaj responsywny srcset z 4 wariantami (480w, 768w, 1280w, 1920w), włącz LiteSpeed Cache lub WP Rocket dla pełnego pamięć podręczna strony (TTFB z 600 ms do 80 ms), opóźnij wszystkie skrypty zewnętrzne atrybutem async lub strategią „lazyOnload”.
Konkretny przykład z praktyki: klient w niszy podłóg B2B z obrazem hero PNG 2.3 MB ładowanym przez tag img bez priorytetu, LCP w CrUX 4.8 sekundy na mobile. Po wdrożeniu WebP z responsywnym srcset (suma rozmiarów 180 KB) plus fetchpriority=”high” plus preload, LCP spadło do 1.9 sekundy. Czas wdrożenia 1.5 godziny, cena 300 PLN, efekt mierzalny w Google Search Console w 14 dni jako wzrost średniej pozycji o 3.2 punktu.
INP (Interaction to Next Paint): interpretacja
INP zastąpiło FID w marcu 2024 jako trzecia oficjalna metryka Core Web Vitals. INP mierzy najwolniejszą interakcję użytkownika z całej sesji na stronie. Interakcją jest kliknięcie, dotknięcie, naciśnięcie klawisza. Google liczy 75 percentyl interakcji wśród użytkowników. Progi: poniżej 200 ms to „good”, 200-500 ms to „needs improvement”, powyżej 500 ms to „poor”.
Różnica między FID a INP jest istotna. FID mierzyło tylko opóźnienie pierwszej interakcji, więc strony z dobrym pierwszym malowaniem ale złą ogólną wydajnością JavaScript mogły mieć FID poniżej 100 ms. INP mierzy najwolniejszą interakcję, więc wyciąga problemy z JavaScript w trakcie sesji (np. otwieranie okna modalnego, filtrowanie produktów w WooCommerce, akordeon w FAQ).
Najczęstsze przyczyny słabego INP w audytach: długie zadania JavaScript powyżej 50 ms blokujące główny wątek (typowo koszt rekoncyliacji w React lub ciężkie obsługi zdarzeń), skrypty zewnętrzne wykonujące się reaktywnie na interakcjach (analityka, moduły czatu, panel zgody na cookies przy ponownym renderze po akceptacji), ciężkie obsługi zdarzeń na elementach często klikanych (np. dodaj do koszyka w WooCommerce z kalkulacją cen w JavaScript zamiast w PHP).
Plan naprawy INP: zidentyfikuj długie zadania w Chrome DevTools Performance z włączonym throttle CPU 4x (symulacja mobile mid-range), przenieś ciężkie obliczenia z głównego wątku do Web Worker, użyj scheduler.yield() do dzielenia długich zadań na kawałki, zmniejsz liczbę skryptów zewnętrznych (każdy moduł czatu to typowo 80-200 ms blokowania głównego wątku), zoptymalizuj komponenty React lub Vue z useMemo i React.memo.
Dla typowej strony WordPress bez frontendowego narzędzie programistycznea JavaScript INP jest zwykle 80-150 ms (good), więc rzadko wymaga aktywnej optymalizacji. Problem pojawia się w sklepach WooCommerce z dużą liczbą filtrów (filtrowanie AJAX-em przebudowujące cały HTML zamiast filtrowania po stronie klienta) oraz w stronach z aktywnymi modułami czatu typu Intercom lub HubSpot. Tu INP potrafi skoczyć do 350-600 ms na mobile.
Praktyczna obserwacja: INP poprawia się znacząco po przeniesieniu analityki na server-side GTM zamiast client-side. Server-side GTM redukuje liczbę skryptów zewnętrznych wykonujących się w przeglądarce z 8-15 do 1-2 (sam kontener GTM plus opcjonalny panel zgód). Średnia poprawa INP w naszych audytach to 80-120 ms, czyli przejście z „needs improvement” do „good”. Koszt wdrożenia server-side GTM to 4-6 godzin pracy plus 5-15 EUR miesięcznie za hosting endpointu.
CLS (Cumulative Layout Shift): interpretacja
CLS mierzy sumę wszystkich nieoczekiwanych przesunięć układu strony w czasie sesji użytkownika. Każde przesunięcie ma wagę liczoną jako iloczyn frakcji ekranu, na którą wpłynęło, i dystansu przesunięcia. CLS jest bezwymiarowe, ale jego progi są jasne: poniżej 0.1 to „good”, 0.1-0.25 to „needs improvement”, powyżej 0.25 to „poor”.
CLS jest metryką, która często zostaje zaniedbana w audytach prowadzonych szybko, bo nie pokazuje się jako „wolna strona”. Zamiast tego pokazuje się jako frustracja typu „kliknąłem w przycisk, ale layout się zmienił i kliknąłem w reklamę” lub „czytałem tekst, ale obraz się załadował i pchnął wszystko niżej”. Te doświadczenia psują postrzeganie marki nawet bardziej niż wolne ładowanie.
Najczęstsze przyczyny słabego CLS: obrazy bez atrybutów width i height (przeglądarka nie zna proporcji, więc po załadowaniu pcha treść w dół), czcionki internetowe ładowane z FOIT (Flash of Invisible Text) powodują ponowny układ po przyjściu fontu, dynamicznie wstawiana treść (banner cookies, okienko miesięczne notatki, wariant testu A/B) bez zarezerwowanego miejsca, reklamy i ramki iframe bez stałych wymiarów, lazy-loaded obrazy bez aspect-ratio w CSS.
Plan naprawy CLS w pięciu krokach: dodaj width i height na każdym tagu img (lub aspect-ratio w CSS), użyj font-display: swap z preload na krytyczne fonty plus dopasowanie fontu zapasowego (Adobe font-style-matcher), zarezerwuj miejsce dla bannera cookies z fixed height i transform: translateY zamiast display: block, ustaw aspect-ratio na wszystkich osadzonych iframe, użyj content-visibility: auto na długich stronach by pominąć renderowanie poza ekranem.
Z naszej praktyki CLS jest najtańszą do naprawy metryką spośród trzech. Większość poprawek to czysty CSS plus drobne zmiany w plikach motywu, bez konieczności ruszania backendu PHP. Klient bez technicznego zaplecza może wdrożyć większość szybkich usprawnień CLS sam, jeśli ma dostęp do motywu potomnego. Audyt dostarcza precyzyjną listę z numerami linii w plikach i sugerowanym kodem do dodania.
Konkretny przykład: klient z branży usług prawnych miał CLS 0.34 w CrUX, głównie z powodu bannera cookies ładowanego asynchronicznie po 800 ms (banner pchał treść w dół o 96 pikseli na mobile). Po zarezerwowaniu stałej wysokości 96px dla placeholdera bannera i transform: translateY(-96px) w stanie hide, CLS spadło do 0.04. Czas wdrożenia 45 minut.
Dane terenowe vs laboratoryjne: co liczy się dla Google
Krytyczne rozróżnienie w audycie Core Web Vitals: dane terenowe versus dane laboratoryjne. Google używa danych terenowych (CrUX, Chrome User Experience Report) jako czynnika rankingowego. Dane laboratoryjne (Lighthouse, WebPageTest) służą jako narzędzie developera do debugowania, ale samo w sobie nie wpływają na ranking.
Dane terenowe CrUX są zbierane anonimowo z prawdziwych użytkowników Chrome którzy włączyli „URL keywords” w synchronizacji. Dane są agregowane na poziomie originu (domena plus subdomeny) lub poszczególnych URL-i, jeśli ten URL ma minimum 1000 wizyt w 28-dniowym oknie. Mniejsze strony mogą nie mieć danych na poziomie URL, tylko na poziomie originu.
Dane laboratoryjne Lighthouse są symulacją: throttling CPU 4x, throttling sieci „Slow 4G” (1.6 Mbps download, 150 ms RTT), Chrome bez rozszerzeń, ekran 360×640. Jest powtarzalna, dobra do CI/CD, ale nie odzwierciedla rzeczywistego doświadczenia. Klient na iPhone 15 Pro z WiFi 5 GHz zobaczy stronę 3-4x szybciej niż Lighthouse mu pokazuje.
Nasze podejście: testujemy obie metryki, ale priorytet decyzyjny daje CrUX. Lighthouse jest narzędziem developmentu („zoptymalizowałem poprawkę, czy lokalnie widzę poprawę?”), CrUX jest narzędziem prawdy („czy poprawka poprawiła rzeczywistych użytkowników w 28 dni?”). Klienci nie patrzą na Lighthouse, patrzą na publiczny wynik PSI, który łączy CrUX (jeśli dostępne) z Lighthouse.
Narzędzia: PSI vs Lighthouse vs WebPageTest vs Chrome DevTools
Audyt Core Web Vitals nie polega na jednym narzędziu. Każde narzędzie ma swoje silne strony i ograniczenia, dobre audytowanie używa 3-4 narzędzi w sekwencji.
PageSpeed Insights to pierwszy przystanek. Pokazuje dane terenowe CrUX plus jeden przebieg Lighthouse. Dobre do szybkiego sprawdzenia i komunikacji z klientem, bo wynik PSI (0-100) jest zrozumiały dla nietechnicznego decydenta. Nie nadaje się do debugowania pojedynczego problemu, bo przebieg Lighthouse jest jeden i może być zaszumiony.
Lighthouse w Chrome DevTools daje szczegółowy raport laboratoryjny z audytami, rekomendacjami i linkami do źródła. Idealne do iteracyjnego developmentu: zmień coś, uruchom Lighthouse, sprawdź czy wynik wzrósł. Można uruchamiać headless w CI/CD przez @lhci/cli, łapać regresję wyniku w pull requestach.
WebPageTest to złoty standard dla głębokiego debugowania. Daje widok waterfall z milisekundową granulacją, wspiera własny throttling (np. 3G Polska, Niemcy), wiele lokalizacji (test z USA, Sydney, Frankfurt jednocześnie), widok filmstrip (renderowanie klatka po klatce). Płatny w pełnej wersji, ale publiczny WebPageTest.org wystarcza dla 80 procent przypadków.
Chrome DevTools Performance jest najgłębszym narzędziem, ale wymaga doświadczenia. Pokazuje flame chart wszystkich wywołań funkcji na głównym wątku, waterfall sieci, zdarzenia przesunięcia układu, długie zadania. Niezastąpione przy debugowaniu problemów z INP (gdzie dokładnie blokuje się główny wątek podczas interakcji?).
Szybkie usprawnienia które poprawią Vitals w 1 tygodniu
Praktyczna lista szybkich usprawnień dla typowej strony WordPress, którą zespół 1-2 osobowy może wdrożyć w 5-8 godzin pracy. Każde ma estymowany wpływ w sekundach LCP lub punktach Lighthouse.
- Konwersja obrazu hero do WebP plus responsywny srcset (redukcja LCP 0.8-1.5s).
- Dodanie fetchpriority=”high” oraz preload link na obraz hero (redukcja LCP 0.3-0.6s).
- Włączenie LiteSpeed Cache lub WP Rocket dla pełnego pamięć podręczna strony (redukcja TTFB 400-600ms).
- Opóźnienie niekrytycznego JavaScript przez async lub strategię „lazyOnload” (redukcja INP 50-150ms).
- Dodanie width i height na wszystkie tagi img (redukcja CLS 0.05-0.15).
- Font-display: swap z preload na krytyczne fonty (redukcja CLS 0.03-0.08 plus szybsze pierwsze wyświetlenie tekstu).
- Lazy-load obrazów poniżej pierwszego ekranu z natywnym loading=”lazy” (mniejsze zużycie danych, lepszy wynik Lighthouse).
Te 7 usprawnień wdrożone razem przekształcają typową stronę WordPress z wyniku 50-65 Lighthouse w wynik 85-95. Dalsze optymalizacje (ekstrakcja Critical CSS, HTTP/2 push, pamięć podręczna na brzegu sieci) dają dodatkowe 5-10 punktów ale wymagają zaawansowanej wiedzy i są częścią naszej pełnej oferty.
Preferowany stos techniczny dla agresywnej optymalizacji Core Web Vitals to WordPress plus Astra Pro plus własny motyw potomny plus LiteSpeed Cache plus Cloudflare jako CDN. Ta konfiguracja dostarcza out-of-the-box Lighthouse 90+ na większości stron, bez konieczności zaawansowanego własnego kodu. Alternatywa Next.js plus Vercel jest opcją dla klientów z budżetem, gdzie SSG plus funkcje na brzegu sieci dostarczają LCP poniżej 800 ms.
FAQ
Jak często sprawdzać Core Web Vitals?
Aktualizacja CrUX jest miesięczna z 28-dniowym oknem zbierania. Sprawdzanie codziennie nie ma sensu, dane się nie zmienią szybciej. Rekomendujemy miesięczny monitoring przez PSI plus alert w Google Search Console na raport „Page experience”. W okresie po wdrożeniu poprawki sprawdzaj co tydzień przez 4 tygodnie, żeby zobaczyć trend.
Czy WordPress może osiągnąć Lighthouse 99/100?
Tak. U nas w studio osiągamy 98-99 punktów wydajności na mobile, 100 punktów na desktop, a u jednego z klientów z branży developerskiej 100/100/100/100 we wszystkich czterech kategoriach. WordPress nie jest blokerem wydajności, blokerem jest wybór motywu i wtyczek. Astra Pro plus własny motyw potomny plus 8-10 wtyczek core zamiast 35 losowych.
Czy TTFB liczy się dla Google?
TTFB (Time To First Byte) nie jest oficjalnym Core Web Vitals, ale wlicza się do LCP. Szybki TTFB poniżej 200 ms daje przewagę 1-2 sekundy w LCP. Google rekomenduje TTFB poniżej 600 ms jako próg „good”. Najprostszą drogą do dobrego TTFB jest pełny pamięć podręczna strony plus shared hosting w tej samej geografii co większość ruchu.
Mobile vs desktop wyniks: który ważniejszy?
Mobile. Google przeszedł na indeksowanie mobile-first w 2021 roku, więc ranking jest oparty głównie na mobilnej wersji strony. Wynik desktop jest ważny dla doświadczenia użytkownika, ale dla SEO priorytet zdecydowanie mobile. Sprawdzaj zawsze mobile najpierw, desktop jako drugorzędny.
Jeśli chcesz wycenę audytu Core Web Vitals dla swojej strony, napisz do nas z adresem strony. Odpowiedź ze wstępną oceną PSI plus rekomendacjami w 24 godziny. Pełny audyt 1500-3000 PLN, dostarczenie 5-10 dni roboczych.