Core Web Vitals – przewodnik: LCP, INP, CLS (2026)

Core Web Vitals to trzy metryki Google – LCP, INP i CLS – które mierzą rzeczywiste doświadczenia użytkowników i bezpośrednio wpływają na pozycje w Google oraz widoczność w AI Overviews. Progi są twarde: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Ten przewodnik pokazuje, jak odczytać raport w Search Console, ustalić priorytety napraw i wdrożyć poprawki – bez zbędnego żargonu, z perspektywy technicznego SEO w praktyce.

Czym są Core Web Vitals i dlaczego Google je wprowadził

Core Web Vitals to trzy mierzalne wskaźniki jakości doświadczenia użytkownika, które Google oficjalnie włączył do algorytmu rankingowego jako sygnał Page Experience w 2021 roku. Oficjalna polska nazwa to “podstawowe wskaźniki internetowe” – termin rzadko używany w praktyce, branża operuje angielską nazwą lub skrótem CWV.

Google ogłosił CWV w 2020 roku, wdrożył jako sygnał rankingowy dla mobile w czerwcu 2021, dla desktop rozszerzył w marcu 2022. Motywacja była konkretna: korelacja między techniczną jakością strony a satysfakcją użytkownika i konwersjami była już wtedy dobrze udokumentowana – Google wolał skwantyfikować ją w powtarzalnych metrykach, niż zostawić webmasterom interpretację “dobrego UX”.

Core Web Vitals jako sygnał rankingowy nie zastępuje jakości treści. Oficjalnie Google traktuje je jako jeden z wielu sygnałów Page Experience – ale sygnał potwierdzony i mierzalny. Artykuł z dobrym contentem i słabymi CWV nie wyleci z pierwszej strony. Artykuł z dobrym contentem i dobrymi CWV ma przewagę nad identycznym artykułem konkurenta ze słabymi CWV. To schemat tie-breaker, nie override. Szczegóły mechanizmu rankowania wyjaśniam w artykule jak działa SEO.

LCP – Largest Contentful Paint (ładowanie)

LCP mierzy czas do wyrenderowania największego elementu widocznego na ekranie – najczęściej zdjęcia hero lub dużego bloku tekstu. Progi: dobre LCP < 2,5 s, wymaga poprawy 2,5-4 s, słabe > 4 s.

Przeglądarka dynamicznie wybiera “największy element” podczas ładowania strony – może się on zmieniać, gdy kolejne zasoby się ładują. W praktyce dla większości stron elementem LCP jest hero image na górze strony. Jeśli nie masz dużego obrazu powyżej foldu, LCP może być duży blok tekstu lub wideo.

Kluczowe dla LCP: element musi być widoczny dla użytkownika, nie schowany za foldą. Lazy loading obrazów powyżej foldu to jeden z najczęstszych błędów – przeglądarka odkłada ładowanie elementu LCP, przez co czas rośnie.

INP – Interaction to Next Paint (interaktywność)

INP mierzy czas od interakcji użytkownika – kliknięcia, tapnięcia lub naciśnięcia klawisza – do wizualnej odpowiedzi przeglądarki. Progi: dobre INP < 200 ms, wymaga poprawy 200-500 ms, słabe > 500 ms.

INP zastąpił FID (First Input Delay) w marcu 2024. Fundamentalna różnica: FID mierzył tylko pierwszą interakcję na stronie, INP mierzy wszystkie interakcje podczas całej sesji i raportuje najgorszy wynik. Strona może mieć dobry FID i zły INP – dlatego po zmianie wiele serwisów zobaczyło pogorszenie wyników w Search Console.

INP powyżej 200 ms użytkownik odczuwa jako “lagującą” stronę – kliknięcie przycisku, otwarcie menu czy wypełnienie formularza odpowiada z opóźnieniem. Na urządzeniach mobilnych z wolniejszymi procesorami efekt jest jeszcze bardziej odczuwalny.

CLS – Cumulative Layout Shift (stabilność wizualna)

CLS mierzy sumę niespodziewanych przesunięć elementów podczas ładowania i korzystania ze strony. Progi: dobre CLS < 0,1, wymaga poprawy 0,1-0,25, słabe > 0,25.

Wzór CLS to iloczyn pola przesunięcia (jaka część ekranu się przesunęła) i odległości przesunięcia (jak daleko). Wartość bezwymiarowa – 0,1 oznacza, że suma przesunięć była umiarkowana.

Przykład z życia: użytkownik czyta artykuł, strona kończy ładować reklamę bez zarezerwowanego miejsca – reklama wskakuje między akapity, przesuwając tekst o 200 px w dół. Użytkownik klika nie w link, który chciał, ale w element który wskoczył pod kursorem. To CLS w czystej postaci.

Ewolucja metryk – FID a INP (marzec 2024)

Google zastąpił FID metryką INP w marcu 2024, bo FID mierzył tylko pierwszą interakcję, co pomijało problemy z responsywnością podczas całej sesji. FID mógł być doskonały (strona szybko reagowała na pierwsze kliknięcie), podczas gdy kolejne interakcje lagowały przez przeciążony JavaScript.

Dla webmasterów, którzy optymalizowali pod FID: dobra wiadomość – techniki poprawy FID (czyszczenie JS, defer, code splitting) bezpośrednio pomagają też INP. Zła wiadomość: INP jest bardziej wymagający, bo liczy najgorszą interakcję z całej sesji, nie pierwszą.

Jak Google mierzy CWV – dane terenowe kontra laboratoryjne

Google rankinguje strony wyłącznie na podstawie danych terenowych (CrUX) – rzeczywistych pomiarów z przeglądarek Chrome – nie na podstawie wyników laboratoryjnych z PageSpeed Insights. To rozróżnienie jest źródłem największego zamieszania w pracy z CWV: możesz mieć wynik 90/100 w PageSpeed a czerwony status w GSC.

CrUX (Chrome UX Report) to baza danych agregująca rzeczywiste pomiary ze stron odwiedzanych przez użytkowników Chrome (którzy wyrazili zgodę na zbieranie danych). Google zbiera dane przez 28 dni i na tej podstawie ocenia stronę. Dane laboratoryjne – wynik Lighthouse w PageSpeed Insights – to symulacja w kontrolowanych warunkach, nie rzeczywistość.

Dlaczego rozbieżność? Lighthouse testuje stronę na wirtualnej maszynie z konkretnym procesorem i prędkością sieci. Twoi użytkownicy mogą mieć wolniejsze urządzenia, słabszą sieć, zainstalowane rozszerzenia przeglądarki – i różne zachowania (zostawiają karty w tle, wracają do strony po godzinie). CrUX agreguje tę różnorodność.

Wniosek praktyczny: nie optymalizuj pod Lighthouse, optymalizuj pod CrUX. Używaj PageSpeed Insights do diagnostyki (co jest problemem), ale oceniaj wyniki w raporcie CWV w Search Console (jak wygląda rzeczywistość dla twoich użytkowników).

CrUX i 75. percentyl – jak liczony jest wynik

Google ocenia wyniki CWV na 75. percentylu – oznacza to, że 1 na 4 użytkowników z najgorszym doświadczeniem decyduje o statusie strony. Nie jest to średnia. Jeśli 74% twoich użytkowników ma LCP 1,5 s, a 26% ma LCP 4 s – strona dostaje status “wymaga poprawy”, bo 75. percentyl przekracza próg 2,5 s.

Konsekwencja: strona może wyglądać dobrze “dla większości użytkowników” i mimo to mieć czerwony status w GSC. Warto sprawdzić, czy problem nie dotyczy konkretnego segmentu – np. użytkowników mobile lub określonej przeglądarki. Dane CrUX są zbierane przez 28-dniowe okno czasowe, co oznacza, że zmiany widać z opóźnieniem.

Desktop vs mobile – dlaczego mobile decyduje o rankingu

Od 2021 roku Google stosuje mobile-first indexing – wersja mobilna strony jest podstawą oceny CWV przy rankingowaniu. CWV mierzone są osobno dla desktop i mobile, ale wynik mobilny ma większą wagę.

Typowe przyczyny rozbieżności między mobile a desktop: wolniejszy procesor telefonu (większe obciążenie JavaScript), wolniejsza sieć (LTE/5G zamiast WiFi), większy rozmiar obrazów renderowanych na mniejszym ekranie, skrypty third-party (chatboty, pop-upy) jeszcze bardziej obciążające mobile. W praktyce: naprawiając mobile naprawisz też desktop, ale nie odwrotnie.

Narzędzia do mierzenia Core Web Vitals

Google oferuje cztery główne narzędzia do mierzenia Core Web Vitals – PageSpeed Insights do szybkiej diagnozy jednej strony, Google Search Console do monitoringu całej witryny, Chrome DevTools do debugowania konkretnych problemów, WebPageTest do zaawansowanej analizy.

Każde narzędzie odpowiada na inne pytanie. PageSpeed Insights: “jaki jest wynik tej konkretnej strony teraz?”. Search Console: “które strony mają problem, ilu użytkowników dotyczy?”. DevTools: “co dokładnie powoduje problem?”. WebPageTest: “jak ładuje się strona krok po kroku dla różnych lokalizacji i urządzeń?”.

Google PageSpeed Insights i Lighthouse

PageSpeed Insights (PSI) na pagespeed.web.dev dostępny jest bez logowania i pokazuje zarówno dane laboratoryjne (Lighthouse), jak i dane terenowe (CrUX) dla tej samej strony. To kluczowe narzędzie do wstępnej diagnozy.

W PSI widzisz dwie sekcje: “Field Data” (dane CrUX dla tej URL – rzeczywiste pomiary z Chrome) i “Lab Data” (wynik Lighthouse – symulacja). Jeśli Field Data brakuje (szary komunikat), strona ma za mało danych w CrUX – mała strona lub niedawno uruchomiona. Lighthouse uruchamia się zawsze.

Interpretacja wyniku Lighthouse 0-100: to nie jest ocena CWV, to zagregowany wynik wielu metryk wydajności. Możesz mieć Lighthouse 85 i zielone CWV, albo Lighthouse 60 i żółte CWV. Patrzeć na konkretne metryki (LCP, INP, CLS), nie na ogólny score.

Raport Core Web Vitals w Google Search Console

Raport CWV w GSC znajdziesz w sekcji “Jakość strony” (lub “Środowisko” w nowszym UI) i pokazuje on, ile URL-i twojego serwisu ma status dobry/wymaga poprawy/słaby – osobno dla mobile i desktop. To jedyne miejsce, gdzie widzisz dane CrUX dla całej witryny.

Jak korzystać z raportu: kliknij w problem (np. “Słaby LCP – ponad 4 s – Mobile”) → zobaczysz listę URL-i z tym problemem. Zacznij od stron z największym ruchem – naprawa strony głównej lub top 10 landing pages przynosi największy efekt. Po wdrożeniu poprawek kliknij “Zweryfikuj poprawkę” – GSC ponownie oceni URL-e po zebraniu nowych danych CrUX (co może zająć do 28 dni).

Ważne: GSC grupuje URL-e według problemu, nie pokazuje każdej URL z osobna jeśli serwis jest duży. Możesz zobaczyć “przykładowe URL-e” – nie musisz naprawiać ich wszystkich osobno, często jedno wdrożenie (np. optymalizacja szablonu kategorii) naprawia całą grupę.

Chrome DevTools i WebPageTest – dla zaawansowanych

Chrome DevTools (zakładka Performance) i WebPageTest.org to narzędzia do debugowania konkretnych problemów na poziomie technicznym – sięgaj po nie, gdy PSI wskazuje problem, ale nie wiesz co dokładnie go powoduje.

W DevTools nagraj ładowanie strony i interakcje – zobaczysz “long tasks” zaznaczone na czerwono (blokujące main thread dłużej niż 50 ms), timeline ładowania zasobów, momenty CLS. WebPageTest generuje waterfall diagram (co ładuje się w jakiej kolejności), filmstrip (jak strona wygląda w kolejnych klatkach) i jest dostępny dla różnych lokalizacji i urządzeń.

Jak Core Web Vitals wpływają na pozycje i konwersje

Core Web Vitals są potwierdzonym sygnałem rankingowym od 2021 roku – nie nadpisują jakości treści, ale przy zbliżonym contencie decydują o przewadze; poza SEO wpływają bezpośrednio na konwersje, bounce rate i koszty kampanii Google Ads. To nie jest sygnał teoretyczny – Google wielokrotnie potwierdzał jego wagę w dokumentacji Google Search Central.

Wpływ na konwersje dokumentuje wiele badań. Google opublikowało dane: przy czasie ładowania powyżej 3 sekund na mobile ponad 50% użytkowników porzuca stronę. Każda dodatkowa sekunda ładowania zmniejsza konwersje. Dla e-commerce poprawa LCP o 0,1 s może zwiększyć konwersję o kilka procent – przy skali tysiące zamówień to konkretna liczba złotówek.

CWV jako sygnał Page Experience – co Google potwierdza

Google oficjalnie potwierdza, że CWV są jednym z sygnałów Page Experience wpływających na ranking, ale nie nadpisują jakości i trafności treści. Cytat z Google Search Central: “Page experience is one of many factors that Google uses to evaluate web content, alongside other signals”.

Praktyczna interpretacja: jeśli twoja strona ma unikalny, wartościowy content na temat niszowy z niską konkurencją – złe CWV nie wyrzucą cię z wyników. Jeśli walczysz o pozycję z 5 innymi stronami o porównywalnej treści i autorytecie domeny – CWV mogą decydować o kolejności. Im bardziej konkurencyjna fraza, tym większe znaczenie sygnałów technicznych.

CWV a Quality Score w Google Ads (wyższy CPC jako ukryty koszt)

Zły wynik CWV podwyższa CPC w kampaniach Google Ads przez wpływ na Quality Score – wolna, niestabilna strona docelowa dostaje niższy Landing Page Experience, co bezpośrednio zwiększa koszty kliknięcia. To argument, który trafia do decydentów biznesowych lepiej niż abstrakcyjne pozycje w wynikach organicznych.

Quality Score w Google Ads składa się z trzech składowych: Expected Click-Through Rate, Ad Relevance i Landing Page Experience. Ta ostatnia zależy od użyteczności i szybkości strony – Google ocenia ją podobnymi sygnałami co CWV. Gorszy Quality Score = wyższy CPC przy tej samej pozycji reklamy. Dla kampanii z budżetem 10 000 zł miesięcznie nawet 15% wzrost CPC z powodu słabej strony docelowej to 1500 zł miesięcznie “spalonych” na złym UX.

CWV a widoczność w AI Overviews (2026)

Strony z dobrymi Core Web Vitals mają wyższą szansę na cytowanie przez Google AI Overviews – techniczna jakość strony wpływa na to, czy Google uzna ją za wiarygodne i łatwo dostępne źródło do generatywnego podsumowania. To kierunek potwierdzony przez mechanikę RAG (Retrieval-Augmented Generation), na której opiera się AI Overviews.

W systemach RAG “koszt pobierania” (cost of retrieval) informacji ze strony wpływa na to, jak często jest ona cytowana. Strona wolna, niestabilna wizualnie lub słabo renderowana w Chrome jest technicznie droższa do przetworzenia. Google przy wyborze źródeł do AI Overviews faworyzuje strony o wysokiej jakości technicznej – to naturalna konsekwencja preferencji dla stron “good for users”. Jeśli chcesz pojawić się w AI Overviews jako cytowane źródło, CWV to jeden z filarów technicznego fundamentu – obok BLUF, struktury nagłówków i E-E-A-T. Więcej o optymalizacji pod AI piszę przy opisie usługi AIO/GEO.

Jak poprawić LCP – ładowanie największego elementu

70% problemów z LCP pochodzi z jednego źródła – dużego, niezoptymalizowanego obrazu hero; konwersja do WebP i dodanie atrybutu preload często przesuwa wynik z czerwonego na zielony bez zaangażowania dewelopera. To najlepszy stosunek efektu do nakładu spośród wszystkich optymalizacji CWV.

Hierarchia przyczyn złego LCP, od najczęstszej: (1) niezoptymalizowany obraz hero (za duży plik, brak preload), (2) render-blocking CSS i JavaScript opóźniające renderowanie, (3) wolny hosting lub brak CDN (wysoki TTFB), (4) lazy loading na elemencie powyżej foldu. Zanim zaangażujesz dewelopera, sprawdź w PSI co konkretnie jest wskazane jako “Reduce initial server response time” lub “Largest Contentful Paint element”.

Optymalizacja obrazów (WebP, preload, wymiary)

Konwersja obrazu hero do formatu WebP zmniejsza rozmiar pliku o 25-35% vs JPEG i 60-80% vs PNG przy tej samej jakości wizualnej – to najszybszy sposób na poprawę LCP.

Praktyczna lista działań:
– Konwertuj hero image i kluczowe obrazy do WebP (narzędzia: Squoosh.app, ImageOptim, wtyczki WP: ShortPixel, Imagify)
– Dodaj <link rel="preload" as="image" href="/images/hero.webp"> w <head> – przeglądarka pobierze obraz wcześniej, zamiast odkrywać go podczas parsowania strony
– Zawsze ustawiaj width i height na obrazach w HTML – eliminuje CLS i pomaga przeglądarce zarezerwować miejsce
– Używaj loading="lazy" TYLKO na obrazach poniżej foldu – dla hero image wyłącz lazy loading lub użyj loading="eager"

Dla WordPress: ShortPixel lub Imagify automatycznie konwertują do WebP i serwują nowoczesny format z fallbackiem dla starszych przeglądarek. Wtyczka generuje też automatycznie srcset dla responsywnych obrazów.

Eliminacja render-blocking resources

CSS i JavaScript ładowane w <head> bez atrybutów defer lub async blokują renderowanie strony – przeglądarka czeka na ich pobieranie i wykonanie zanim narysuje cokolwiek na ekranie.

Jak sprawdzić problem: w PageSpeed Insights sekcja “Eliminate render-blocking resources” pokazuje konkretne pliki z szacowanym opóźnieniem. W DevTools zakładka Performance – “Render-blocking stylesheets/scripts” w diagramie.

Rozwiązania: defer na skryptach JS (pobierają się równolegle, wykonują po parsowaniu HTML), async na skryptach niezależnych (np. Google Analytics – wykonują się jak tylko się załadują), krytyczny CSS inline w <head> (wyodrębnij CSS potrzebny do renderowania above-the-fold, resztę ładuj asynchronicznie), minifikacja CSS i JS.

CDN i szybki hosting jako fundament

TTFB (Time to First Byte) powyżej 800 ms jest sygnałem, że problem leży po stronie serwera, nie optymalizacji frontend – w tej sytuacji optymalizacja obrazów da ograniczone rezultaty. Target: TTFB < 800 ms, optymalnie < 200 ms.

CDN (Content Delivery Network) serwuje zasoby statyczne z serwera geograficznie bliskiego użytkownikowi – zamiast serwera w Warszawie obsługiwać użytkownika z Gdańska przez 800 ms, serwer CDN w regionie odpowiada w 50 ms. Dla polskiego serwisu kluczowe: CDN z węzłami w Polsce lub Europie Środkowej (Cloudflare, Bunny.net mają PoP w Warszawie i Frankfurcie).

Jak poprawić INP – reaktywność na interakcje

Wysoki INP to prawie zawsze problem z przeciążonym głównym wątkiem JavaScript – strona jest zajęta przetwarzaniem skryptów, gdy użytkownik chce kliknąć. Main thread przeglądarki jest jeden: jeśli wykonuje zadania JavaScript, nie może jednocześnie reagować na interakcje użytkownika. Stąd opóźnienie.

Winowajcy w kolejności częstości: skrypty reklamowe (Google Ads, Meta Pixel, programmatic ads), narzędzia analityczne (GA4, Hotjar, Clarity), wtyczki third-party (chatboty, pop-upy GDPR, widżety social media), własny kod JavaScript (eventlisteners, animacje, komplikowane filtry). Dla stron WordPress: każda zainstalowana wtyczka dodaje swój JavaScript do frontendu.

Optymalizacja JavaScript (long tasks, code splitting)

Long task to zadanie JavaScript trwające dłużej niż 50 ms – blokuje main thread i powoduje, że kliknięcie użytkownika musi czekać na zakończenie zadania. W Chrome DevTools zakładka Performance długie taski widać jako czerwone zaznaczenia na osi czasu main thread.

Jak diagnozować: nagraj interakcję w DevTools → sprawdź które skrypty tworzą long tasks → zidentyfikuj źródło (nazwa pliku wskazuje często na konkretną wtyczkę lub skrypt third-party). Priorytet usuwania: skrypty reklamowe i trackingowe third-party mają największy wpływ na INP przy najmniejszej wartości biznesowej dla UX.

Code splitting to technika deweloperska: zamiast jednego dużego pliku bundle.js dzielisz kod na mniejsze kawałki ładowane tylko gdy są potrzebne. Szczególnie ważne dla aplikacji SPA (React, Vue, Angular) i sklepów z rozbudowanymi filtrami produktów.

Opóźnianie niekrytycznych skryptów (defer, async)

Skrypty third-party – Hotjar, LiveChat, chatboty, widżety social media – powinny ładować się po załadowaniu głównej treści strony, nie blokując jej renderowania.

Różnica między defer a async: defer – skrypt pobiera się równolegle z parsowaniem HTML, wykonuje się dopiero po załadowaniu całego HTML (dobry dla skryptów zależnych od DOM); async – skrypt pobiera się równolegle, wykonuje się jak tylko się załaduje przerywając parsowanie (dobry dla niezależnych skryptów jak analytics).

Dla WordPress: wtyczki WP Rocket, Flying Scripts lub LiteSpeed Cache pozwalają opóźnić ładowanie konkretnych skryptów bez modyfikowania kodu. Skrypt GA4 możesz bezpiecznie ładować z defer – Google potwierdza, że nie wpływa to na jakość danych.

Jak poprawić CLS – stabilność wizualna

CLS najczęściej psują elementy bez zdefiniowanych rozmiarów – obrazy i reklamy bez width/height powodują skoki layoutu, gdy strona kończy ładowanie. To błąd, który można wyeliminować w jeden dzień bez zaawansowanych prac technicznych.

Hierarchia winowajców CLS: (1) obrazy bez width i height, (2) reklamy bez zarezerwowanego miejsca w kontenerze, (3) dynamicznie ładowane treści wskakujące nad istniejący content, (4) fonty web powodujące podmianę fallback na docelowy krój.

Rezerwowanie miejsca dla obrazów i reklam

Dodanie atrybutów width i height do każdego obrazu w HTML eliminuje CLS spowodowany przez obrazy – przeglądarka zna rozmiar elementu zanim pobierze plik i rezerwuje odpowiednie miejsce.

Przykład kodu (HTML):

<img src="/images/hero.webp" width="1200" height="600" alt="Opis" loading="eager">

Dla reklam (Google AdSense, sieci programmatic): ustaw min-height dla kontenera reklamy odpowiadający rozmiarowi najbardziej popularnego formatu reklamowego w tym miejscu. Jeśli blok reklamowy może mieć 90 px lub 250 px – ustaw min-height: 250px, żeby nigdy nie było przeskoku w górę.

Dla dynamicznie ładowanych elementów (embedy Twitter, iframes YouTube): użyj CSS aspect-ratio lub padding-top hack zarezerwuj przestrzeń przed załadowaniem treści. Przykład: aspect-ratio: 16/9 na kontenerze iframe YouTube.

Fonty i layout shift – jak zapobiegać

Niestandardowe fonty webowe powodują CLS, gdy przeglądarka przez chwilę renderuje tekst czcionką systemową (fallback), a po załadowaniu fontu zamienia ją na docelowy krój – jeśli kroje mają różne metryki, tekst “skacze”.

Rozwiązania: font-display: swap w CSS pozwala renderować fallback do momentu załadowania fontu, ale powoduje FOUT (Flash of Unstyled Text). font-display: optional wstrzymuje ładowanie fontu jeśli nie jest dostępny od razu – eliminuje FOUT, ale użytkownicy ze słabym łączem widzą systemowy font. size-adjust w CSS (nowszy atrybut) pozwala dopasować rozmiar fallback fontu do docelowego kroju, minimalizując przeskoki.

Preload fontu w <head>: <link rel="preload" href="/fonts/font.woff2" as="font" crossorigin> – przeglądarka pobierze font wcześniej, skracając czas do jego dostępności.

Od czego zacząć – priorytetyzacja napraw CWV

Zacznij od metryki z czerwonym statusem w GSC, od podstron z największym ruchem – jedna naprawiona strona główna często przesunie cały serwis z czerwonego na żółty. Nie naprawiaj po kolei wszystkich URL-i – napraw wzorzec (szablon strony) i problem zniknie masowo.

Framework priorytetyzacji (5 kroków):
1. Otwórz raport CWV w GSC – sprawdź ile URL-i jest czerwonych dla mobile
2. Posortuj problemy wg liczby URL-i w grupie – największa grupa = największy efekt naprawy
3. Sprawdź URL-e z tej grupy w PageSpeed Insights – zidentyfikuj przyczynę (co konkretnie PSI wskazuje)
4. Oceń trudność naprawy: wymiana obrazu na WebP (1 godzina) vs refaktoryzacja JavaScript (tydzień pracy dewelopera)
5. Wdróż i kliknij “Zweryfikuj poprawkę” w GSC – dane CrUX odświeżają się co 28 dni

Dla audytu SEO moich klientów zbieram dane CWV z GSC i PSI jako element raportu technicznego – priorytetyzacja jest zawsze relative do architektury serwisu i możliwości technicznych zespołu.

Schemat decyzji – które metryki naprawiać najpierw

Hierarchia napraw: LCP > CLS > INP – LCP jest najczęściej problemowy, CLS zwykle najłatwiejszy do naprawy, INP wymaga analizy JavaScript i angażuje dewelopera.

Czerwony przed żółtym, mobile przed desktop – taka jest hierarchia. Jeśli wszystkie trzy metryki są czerwone, zacznij od LCP i CLS (szybkie wygrane), a przy INP równolegle diagnozuj JavaScript.

Pamiętaj: techniczne SEO to nie tylko CWV – crawlability, indeksacja i JavaScript rendering to równie ważne elementy. CWV to jeden z filarów, nie cały fundament.

CWV dla różnych typów stron

Priorytety optymalizacji CWV różnią się w zależności od typu strony – e-commerce koncentruje się na LCP i CLS, strony content na LCP, landing page na INP.

Sklep e-commerce: LCP krytyczny (zdjęcia produktów często duże i niezoptymalizowane), CLS krytyczny (reklamy, banery promocyjne, dynamiczne elementy cennika powodują skoki), INP ważny (filtry produktów, dodawanie do koszyka muszą reagować szybko). Szczegółowo o technicznych aspektach SEO dla sklepów można przeczytać w artykule o pozycjonowaniu sklepu internetowego.

Blog i strony content: LCP dominuje (hero image lub tekst), CLS zwykle niskie (mniej dynamicznych elementów), INP rzadko problemowy (mało interakcji).

Landing page: INP istotny (formularze, przyciski CTA muszą reagować natychmiast – opóźnienie 300 ms na “Zamów demo” to utracona konwersja), LCP ważny (czas ładowania above-the-fold wpływa na bounce rate).

FAQ – najczęstsze pytania o Core Web Vitals

Czy Core Web Vitals to jedyne czynniki rankingowe Google?

Nie – Core Web Vitals to jeden z potwierdzonych sygnałów rankingowych, ale Google używa setek czynników. CWV nie nadpisują jakości i trafności treści. Przy identycznym contencie mogą decydować o przewadze, ale strona z wartościowym contentem nie wyleci z wyników organicznych wyłącznie przez złe CWV.

Co oznacza dobry wynik Core Web Vitals?

Dobre CWV to: LCP < 2,5 s, INP < 200 ms, CLS < 0,1 – dla 75. percentyla użytkowników danej strony. Wszystkie trzy metryki muszą być jednocześnie w strefie “dobre”, żeby strona dostała zielony status w raporcie GSC. Wystarczy jedna metryka poniżej progu, by całość była oznaczona jako “wymaga poprawy” lub “słabe”.

Czy PageSpeed Insights 90/100 oznacza dobre Core Web Vitals?

Nie. Wynik 90/100 w PageSpeed Insights to ocena Lighthouse na podstawie danych laboratoryjnych – symulacji w kontrolowanych warunkach. Ranking Google oparty jest wyłącznie na danych terenowych z CrUX (rzeczywiste pomiary z przeglądarek Chrome). Możesz mieć PSI 95 i czerwony status CWV w GSC, jeśli twoi rzeczywiści użytkownicy mają inne urządzenia i sieć niż symulacja Lighthouse.

Jak często odświeżają się dane CWV w Search Console?

Dane CWV w GSC opierają się na oknie czasowym CrUX wynoszącym 28 dni. Oznacza to, że po wdrożeniu poprawek musisz czekać do 4 tygodni na widoczną zmianę statusu. Kliknij “Zweryfikuj poprawkę” w GSC – system zacznie zbierać nowe dane i poinformuje cię o statusie.

Czy Core Web Vitals wpływają na ruch z reklam Google Ads?

Tak – przez Quality Score. Wolna lub niestabilna strona docelowa dostaje niższy Landing Page Experience w Quality Score, co podnosi CPC przy zachowaniu tej samej pozycji reklamy. Dla kampanii o znaczących budżetach poprawa CWV strony docelowej może obniżyć CPC o kilkanaście procent.

Czy CWV mają znaczenie dla małych stron z małym ruchem?

Małe strony mogą nie mieć wystarczającej liczby pomiarów w CrUX, by pojawić się w raporcie GSC – brakuje pola “Field Data”. Nie oznacza to braku wpływu CWV na UX. Dobra techniczna jakość strony przekłada się na konwersje niezależnie od rankingów. Gdy ruch wzrośnie do progu CrUX, strona zostanie oceniona – warto zadbać o CWV wcześniej.

Jak CWV wpływają na widoczność w AI Overviews?

Google AI Overviews przy wyborze źródeł faworyzuje strony o wysokiej jakości technicznej – szybko ładujące się, stabilne wizualnie i dobrze renderowane. Strona z złymi CWV może być traktowana jako niskiej jakości i pominięta przy generowaniu podsumowania AI. To powiązanie wynika z mechaniki RAG i preferencji Google dla “good for users” treści.

Co to jest CrUX i dlaczego nie widać moich danych?

CrUX (Chrome UX Report) to baza danych agregująca rzeczywiste pomiary wydajności stron odwiedzanych przez użytkowników Google Chrome, którzy wyrazili zgodę na zbieranie danych. Małe strony mogą nie osiągać minimalnego progu liczby pomiarów potrzebnego do pojawienia się w CrUX – wtedy PSI nie pokazuje sekcji Field Data, a raport GSC nie wyświetla URL-i. Rozwiązanie: poczekaj na wzrost ruchu lub zbieraj dane w Google Analytics (nie zastąpi CrUX, ale da ci orientację).