Core Web Vitals: co to jest i jak poprawić LCP, INP i CLS

Core Web Vitals (CWV) to trzy wskaźniki Google: LCP, INP i CLS. Mierzą, jak szybko ładuje się strona, jak reaguje na kliknięcia i czy jej układ nie skacze podczas ładowania. Google używa ich jako jednego z sygnałów rankingowych. 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ć kolejność napraw i wdrożyć poprawki bez zbędnego żargonu, z perspektywy praktyka technicznego SEO.

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. W polskiej dokumentacji Search Console Google używa nazwy „raport dotyczący Core Web Vitals”; w branży mówi się po prostu CWV.

Google ogłosił CWV w 2020 roku, wprowadził je jako sygnał rankingowy na urządzeniach mobilnych w czerwcu 2021 roku, a na komputerach w marcu 2022 roku. Powód był konkretny: związek technicznej jakości strony z zadowoleniem użytkowników i konwersjami był już wtedy dobrze opisany, więc Google wolał zmierzyć go powtarzalnymi wskaźnikami, niż zostawić właścicielom stron dowolną interpretację „dobrego UX”.

Core Web Vitals jako sygnał rankingowy nie zastępują jakości treści. Oficjalnie Google traktuje je jako jeden z wielu sygnałów doświadczenia na stronie (Page Experience), ale jest to sygnał potwierdzony i mierzalny. Artykuł z dobrą treścią i słabymi CWV nie wypadnie z pierwszej strony. Artykuł z dobrą treścią i dobrymi CWV ma jednak przewagę nad podobnym artykułem konkurenta ze słabymi CWV. CWV rozstrzygają więc między podobnymi stronami, ale nie zastępują dobrej treści. Szczegóły działania rankingu 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 dużego zdjęcia na górze strony albo dużego bloku tekstu. Progi: dobre LCP < 2,5 s, do poprawy 2,5–4 s, słabe > 4 s.

Przeglądarka wybiera „największy element” na bieżąco podczas ładowania strony i może go zmieniać, gdy ładują się kolejne zasoby. W praktyce w większości stron elementem LCP jest główne zdjęcie na górze strony. Jeśli nie masz dużego obrazu na pierwszym ekranie, elementem LCP może być duży blok tekstu albo wideo.

Dla LCP liczy się element widoczny na pierwszym ekranie. Leniwe ładowanie (lazy loading) obrazów na pierwszym ekranie to jeden z najczęstszych błędów: przeglądarka odkłada pobranie elementu LCP, więc czas rośnie.

INP: Interaction to Next Paint (interaktywność)

INP mierzy czas od działania użytkownika (kliknięcia, dotknięcia albo naciśnięcia klawisza) do widocznej reakcji przeglądarki. Progi: dobre INP < 200 ms, do poprawy 200–500 ms, słabe > 500 ms.

INP zastąpił FID (First Input Delay) w marcu 2024 roku. Najważniejsza różnica: FID mierzył tylko pierwszą interakcję na stronie, a INP obserwuje wszystkie interakcje podczas wizyty i podaje wynik zbliżony do najgorszego. Strona może mieć dobry FID i zły INP, dlatego po zmianie wiele serwisów zobaczyło gorsze wyniki w Search Console.

INP powyżej 200 ms użytkownik odczuwa jako stronę, która „zacina się”: kliknięcie przycisku, otwarcie menu czy wypełnianie formularza działa z opóźnieniem. Na telefonach z wolniejszymi procesorami efekt jest jeszcze mocniejszy.

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.

Każde pojedyncze przesunięcie ocenia się jako iloczyn pola przesunięcia (jaka część ekranu się przesunęła) i odległości przesunięcia (jak daleko). CLS to wynik największej serii takich przesunięć w krótkim oknie czasowym, a nie suma przesunięć z całej wizyty. Wartość 0,1 lub mniej oznacza stabilny układ strony.

Przykład z życia: użytkownik czyta artykuł, a strona kończy ładować reklamę bez zarezerwowanego miejsca. Reklama wskakuje między akapity i przesuwa tekst o 200 px w dół. Użytkownik klika nie w link, który chciał, tylko w element, który wskoczył pod kursor. 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 osób, które optymalizowały strony pod FID, jest dobra wiadomość: techniki poprawy FID (porządki w JS, defer, dzielenie kodu) pomagają też INP. Zła wiadomość: INP jest bardziej wymagający, bo uwzględnia najgorsze interakcje z całej wizyty, a nie tylko pierwszą.

Jak Google mierzy CWV: dane terenowe kontra laboratoryjne

W ocenie Core Web Vitals Google bierze pod uwagę dane od użytkowników (CrUX), czyli rzeczywiste pomiary z przeglądarek Chrome, a nie wyniki laboratoryjne z PageSpeed Insights. To rozróżnienie wywołuje najwięcej zamieszania w pracy z CWV: możesz mieć wynik 90/100 w PageSpeed i czerwony status w GSC.

CrUX (Chrome UX Report) to baza, która zbiera rzeczywiste pomiary ze stron odwiedzanych przez użytkowników Chrome, którzy zgodzili się na przesyłanie danych. Google bierze dane z 28 dni i na ich podstawie ocenia stronę. Dane laboratoryjne, czyli wynik Lighthouse w PageSpeed Insights, to symulacja w kontrolowanych warunkach, a nie rzeczywistość.

Skąd ta rozbieżność? Lighthouse testuje stronę na wirtualnej maszynie z określonym procesorem i prędkością sieci. Twoi użytkownicy mogą mieć wolniejsze urządzenia, słabszą sieć i rozszerzenia w przeglądarce, a do tego różnie się zachowują (zostawiają karty w tle, wracają na stronę po godzinie). CrUX uwzględnia całą 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, więc o statusie strony decyduje co czwarty użytkownik z najgorszymi warunkami. To nie jest ś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.

W efekcie strona może dobrze działać „dla większości użytkowników”, a mimo to mieć czerwony status w GSC. Sprawdź, czy problem nie dotyczy konkretnej grupy, np. użytkowników telefonów albo określonej przeglądarki. Dane CrUX obejmują 28 dni, więc zmiany widać z opóźnieniem.

Desktop vs mobile: dlaczego mobile decyduje o rankingu

Google indeksuje strony na podstawie ich wersji mobilnej (przejście na mobile-first indexing zakończył 31 października 2023 r.), dlatego wyniki CWV na telefonach są ważniejsze. Raport w Search Console pokazuje CWV osobno dla telefonów i komputerów.

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 zewnętrzne (czaty, okna pop-up) jeszcze bardziej obciążające telefony. W praktyce: naprawiając mobile naprawisz też desktop, ale nie odwrotnie.

Narzędzia do mierzenia Core Web Vitals

Do mierzenia Core Web Vitals służą cztery główne narzędzia: PageSpeed Insights do szybkiej diagnozy jednej strony, Google Search Console do obserwacji całej witryny, Chrome DevTools do szukania przyczyn konkretnych problemów i 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: dane od użytkowników (CrUX dla tego adresu, czyli rzeczywiste pomiary z Chrome) i dane laboratoryjne (wynik Lighthouse, czyli symulacja). Jeśli danych od użytkowników brakuje (szary komunikat), strona ma za mało pomiarów w CrUX, bo jest mała albo 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. Patrz na konkretne metryki (LCP, INP, CLS), a nie na ogólny wynik.

Raport Core Web Vitals w Google Search Console

Raport Core Web Vitals w Search Console pokazuje, ile adresów Twojego serwisu ma status „dobry”, „wymaga poprawy” albo „słaby”, osobno dla telefonów i komputerów. To jedyne miejsce, w którym widzisz dane CrUX dla całej witryny pogrupowane według podobnych stron.

Jak korzystać z raportu: kliknij problem (np. „Słaby LCP, ponad 4 s, urządzenia mobilne”), a zobaczysz listę adresów z tym problemem. Zacznij od stron z największym ruchem, bo naprawa strony głównej albo 10 najczęściej odwiedzanych stron daje największy efekt. Po wdrożeniu poprawek kliknij „Sprawdź poprawkę”; GSC ponownie oceni adresy po zebraniu nowych danych CrUX, co może potrwać do 28 dni.

W dużych serwisach GSC grupuje adresy według problemu i nie pokazuje każdego osobno, tylko „przykładowe adresy URL”. Nie musisz naprawiać ich pojedynczo, bo często jedna zmiana (np. optymalizacja szablonu kategorii) naprawia całą grupę.

Chrome DevTools i WebPageTest: dla zaawansowanych

Chrome DevTools (zakładka Performance) i WebPageTest.org służą do szukania przyczyn 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, a zobaczysz długie zadania (long tasks) zaznaczone na czerwono, czyli blokujące główny wątek dłużej niż 50 ms, oś czasu ładowania zasobów i momenty przesunięć układu. WebPageTest tworzy wykres kaskadowy (co ładuje się w jakiej kolejności), serię klatek (jak strona wygląda w kolejnych chwilach) i działa dla różnych lokalizacji i urządzeń.

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

Core Web Vitals są sygnałem rankingowym od 2021 r. Nie zastępują jakości treści, ale przy podobnych stronach dają przewagę, a poza SEO wpływają na konwersję i koszt kampanii reklamowych. Google opisuje je w dokumentacji Search Central jako część oceny wygody korzystania ze strony.

Związek szybkości z konwersją pokazują badania, ale ich wyniki zależą od branży i metody. Raport Deloitte dla Google z 2020 r. („Milliseconds Make Millions”) dotyczył poprawy szybkości stron mobilnych o 0,1 s, a nie samego LCP. Dlatego zamiast przenosić procenty z badań, porównaj konwersję w swoim sklepie przed poprawą i po niej.

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”.

W praktyce: jeśli Twoja strona ma unikalną, wartościową treść w niszowym temacie z małą konkurencją, słabe CWV nie wyrzucą jej 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)

Wolna, niestabilna strona docelowa może też podnosić koszty Google Ads, bo obniża ocenę jakości strony docelowej w Wyniku jakości (Quality Score). Ten argument trafia do decydentów lepiej niż pozycje w wynikach organicznych.

Wynik jakości w Google Ads ma trzy składowe: przewidywany CTR, trafność reklamy i jakość strony docelowej. Ta ostatnia zależy m.in. od użyteczności i szybkości strony. Niższy Wynik jakości oznacza wyższy koszt kliknięcia przy tej samej pozycji reklamy. Przy budżecie 10 000 zł miesięcznie nawet 15% wzrostu CPC przez słabą stronę docelową to 1500 zł miesięcznie wydane na gorszą jakość strony.

CWV a widoczność w AI Overviews

Google nie podaje, że Core Web Vitals wpływają na wybór źródeł do AI Overviews. Według dokumentacji strona musi być zaindeksowana i móc wyświetlać się z fragmentem; dodatkowych wymagań technicznych nie ma. Szybka i stabilna strona jest lepsza dla użytkowników, którzy klikną link z podsumowania, ale nie traktuj CWV jako sposobu na cytowania.

Jak poprawić LCP: ładowanie największego elementu

Najczęstszą przyczyną słabego LCP jest duży, niezoptymalizowany obraz na górze strony. Zmiana formatu na WebP lub AVIF i wczesne ładowanie tego obrazu (preload, fetchpriority="high") często wystarczają, żeby LCP spadł poniżej 2,5 s. To zwykle najlepszy stosunek efektu do nakładu pracy spośród 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)

Zapisanie głównego obrazu w formacie WebP zmniejsza plik o 25–35% w porównaniu z JPEG i o 60–80% w porównaniu z PNG przy tej samej jakości, co jest najszybszym sposobem 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>, a przeglądarka pobierze obraz wcześniej, zamiast odkrywać go podczas analizy strony
• Zawsze ustawiaj width i height obrazów w HTML: przeglądarka zarezerwuje miejsce i nie będzie przesunięć układu (CLS)
• Stosuj loading="lazy" WYŁĄCZNIE dla obrazów poniżej pierwszego ekranu; dla głównego obrazu na górze strony wyłącz leniwe ładowanie albo 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, bo przeglądarka czeka na ich pobranie i wykonanie, zanim cokolwiek wyświetli.

Jak sprawdzić problem: w PageSpeed Insights sekcja o zasobach blokujących renderowanie („Eliminate render-blocking resources”) pokazuje konkretne pliki z szacowanym opóźnieniem. W DevTools widać je na wykresie w zakładce Performance.

Rozwiązania: defer dla skryptów JS (pobierają się równolegle i wykonują po przetworzeniu HTML), async dla niezależnych skryptów (np. Google Analytics, które wykonują się zaraz po pobraniu), krytyczny CSS wpisany w <head> (CSS potrzebny do pierwszego ekranu, a reszta ładowana asynchronicznie) i zmniejszanie plików CSS i JS.

CDN i szybki hosting jako fundament

TTFB (Time to First Byte) powyżej 800 ms to sygnał, że problem leży po stronie serwera, a nie w optymalizacji frontendu, więc optymalizacja obrazów da wtedy ograniczone efekty. Cel: TTFB poniżej 800 ms, najlepiej około 200 ms.

CDN (Content Delivery Network) dostarcza zasoby statyczne z serwera położonego blisko użytkownika. Zamiast obsługiwać użytkownika z Gdańska z serwera w Warszawie przez 800 ms, odpowiada serwer CDN w regionie w 50 ms. Dla polskiego serwisu ważny jest CDN z węzłami w Polsce albo w Europie Środkowej (Cloudflare i Bunny.net mają punkty w Warszawie i Frankfurcie).

Jak poprawić INP: reaktywność na interakcje

Wysoki INP to prawie zawsze przeciążony główny wątek JavaScriptu: strona jest zajęta przetwarzaniem skryptów, gdy użytkownik chce kliknąć. Przeglądarka ma jeden główny wątek. Jeśli wykonuje zadania JavaScriptu, nie może jednocześnie reagować na działania użytkownika i 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 zewnętrzne (czaty, okna zgód RODO, widżety mediów społecznościowych), własny kod JavaScript (obsługa zdarzeń, animacje, skomplikowane filtry). Dla stron WordPress: każda zainstalowana wtyczka dodaje swój JavaScript do frontendu.

Optymalizacja JavaScript (long tasks, code splitting)

Długie zadanie (long task) to zadanie JavaScriptu trwające ponad 50 ms; blokuje główny wątek, więc kliknięcie użytkownika musi czekać na jego koniec. W Chrome DevTools w zakładce Performance długie zadania widać jako czerwone oznaczenia na osi czasu głównego wątku.

Jak diagnozować: nagraj interakcję w DevTools → sprawdź które skrypty tworzą long tasks → zidentyfikuj źródło (nazwa pliku często wskazuje konkretną wtyczkę lub zewnętrzny skrypt). Kolejność usuwania: zewnętrzne skrypty reklamowe i śledzące 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)

Zewnętrzne skrypty, takie jak Hotjar, LiveChat, czaty i widżety mediów społecznościowych, powinny ładować się po załadowaniu głównej treści strony, nie blokując jej renderowania.

Różnica między defer a async: skrypt z defer pobiera się równolegle z przetwarzaniem HTML i wykonuje dopiero po wczytaniu całego HTML (dobry dla skryptów zależnych od DOM); skrypt z async pobiera się równolegle i wykonuje zaraz po pobraniu, przerywając przetwarzanie (dobry dla niezależnych skryptów, takich jak analityka).

Dla WordPress: wtyczki WP Rocket, Flying Scripts lub LiteSpeed Cache pozwalają opóźnić ładowanie konkretnych skryptów bez modyfikowania kodu. Skrypt GA4 (gtag.js) ładuje się asynchronicznie. Opóźnienie go do pierwszej interakcji użytkownika zmniejsza obciążenie, ale może zaniżyć w statystykach liczbę bardzo krótkich wizyt.

Jak poprawić CLS: stabilność wizualna

CLS najczęściej psują elementy bez określonych wymiarów: obrazy i reklamy bez width i height powodują skoki układu, gdy strona kończy się ładować. Ten błąd da się usunąć 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

Atrybuty width i height przy każdym obrazie w HTML usuwają CLS spowodowany przez obrazy, bo przeglądarka zna rozmiar elementu przed pobraniem pliku 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 kontenera reklamy odpowiadający najczęstszemu formatowi w tym miejscu. Jeśli blok reklamowy może mieć 90 px albo 250 px, ustaw min-height: 250px, żeby nigdy nie przeskakiwał w górę.

Dla dynamicznie ładowanych elementów (embedy Twitter, iframes YouTube): zarezerwuj miejsce przed załadowaniem treści za pomocą CSS aspect-ratio albo dawnej techniki z padding-top. Przykład: aspect-ratio: 16/9 na kontenerze iframe YouTube.

Fonty i layout shift: jak zapobiegać

Niestandardowe fonty powodują CLS, gdy przeglądarka przez chwilę wyświetla tekst czcionką systemową (zastępczą), a po pobraniu fontu podmienia ją na docelowy krój; jeśli kroje mają różne wymiary, tekst „skacze”.

Rozwiązania: font-display: swap w CSS wyświetla font zastępczy do czasu pobrania właściwego, ale powoduje mignięcie tekstu przy zmianie kroju (FOUT). font-display: optional nie czeka na font, jeśli nie jest dostępny od razu, co usuwa mignięcie, ale użytkownicy ze słabym łączem zobaczą font systemowy. Nowsza właściwość size-adjust w CSS pozwala dopasować rozmiar fontu zastępczego do docelowego kroju i ograniczyć przeskoki.

Wczesne pobranie fontu w <head>: <link rel="preload" href="/fonts/font.woff2" as="font" crossorigin> sprawia, że przeglądarka pobierze font wcześniej i szybciej będzie mogła go użyć.

Od czego zacząć: priorytetyzacja napraw CWV

Zacznij od wskaźnika z czerwonym statusem w GSC i od podstron z największym ruchem; naprawa strony głównej często przesuwa cały serwis z czerwonego na żółty. Nie naprawiaj adresów po kolei, tylko popraw szablon strony, a problem zniknie na wszystkich stronach, które z niego korzystają.

Framework priorytetyzacji (5 kroków):
1. Otwórz raport CWV w GSC i sprawdź, ile adresów ma czerwony status na urządzeniach mobilnych
2. Posortuj problemy według liczby adresów w grupie, bo naprawa największej grupy daje największy efekt
3. Sprawdź adresy z tej grupy w PageSpeed Insights i ustal przyczynę (co konkretnie wskazuje PSI)
4. Oceń trudność naprawy: wymiana obrazu na WebP (1 godzina) vs refaktoryzacja JavaScript (tydzień pracy dewelopera)
5. Wdróż poprawkę i kliknij „Sprawdź poprawkę” w GSC; dane CrUX obejmują 28 dni

W audycie SEO zbieram dane CWV z GSC i PSI jako część raportu technicznego, a kolejność napraw zawsze zależy od architektury serwisu i możliwości zespołu.

Schemat decyzji: które metryki naprawiać najpierw

Kolejność napraw: LCP, potem CLS, potem INP. LCP najczęściej sprawia problemy, CLS zwykle najłatwiej naprawić, a INP wymaga analizy JavaScriptu i pracy programisty.

Czerwony status przed żółtym, telefony przed komputerami. Jeśli wszystkie trzy wskaźniki są czerwone, zacznij od LCP i CLS (szybkie efekty), a równolegle szukaj przyczyn słabego INP w JavaScripcie.

Pamiętaj, że techniczne SEO to nie tylko CWV. Dostępność dla robotów, indeksacja i renderowanie JavaScriptu są równie ważne. CWV to jeden z filarów, a nie cały fundament.

CWV dla różnych typów stron

Priorytety optymalizacji CWV zależą od typu strony: sklepy skupiają się na LCP i CLS, serwisy z treściami na LCP, a strony docelowe kampanii 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).

Strona docelowa kampanii: INP ma duże znaczenie, bo formularze i przyciski muszą reagować natychmiast, a 300 ms opóźnienia przy „Zamów demo” to utracona konwersja. Ważny jest też LCP, bo czas ładowania pierwszego ekranu wpływa na liczbę osób, które od razu wychodzą.

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 bierze pod uwagę bardzo wiele czynników. CWV nie są ważniejsze od jakości i trafności treści. Przy podobnej treści mogą dać przewagę, ale wartościowa strona nie wypadnie z wyników organicznych tylko przez słabe CWV.

Co oznacza dobry wynik Core Web Vitals?

Dobre CWV to LCP < 2,5 s, INP < 200 ms i CLS < 0,1 dla 75. percentyla użytkowników danej strony. Wszystkie trzy wskaźniki muszą jednocześnie być w strefie „dobre”, żeby strona dostała zielony status w raporcie GSC. Wystarczy jeden wskaźnik poniżej progu, a całość zostanie oznaczona jako „wymaga poprawy” albo „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, czyli symulacji w kontrolowanych warunkach. W ocenie CWV Google korzysta z danych od użytkowników z CrUX (rzeczywistych pomiarów z przeglądarek Chrome). Możesz mieć w PSI wynik 95 i czerwony status CWV w GSC, jeśli Twoi 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 obejmują okres 28 dni z CrUX. Po wdrożeniu poprawek musisz więc czekać do 4 tygodni na widoczną zmianę statusu. Kliknij „Sprawdź poprawkę” w GSC, a system zacznie zbierać nowe dane i poinformuje Cię o wyniku.

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

Może, przez Wynik jakości. Wolna albo niestabilna strona docelowa dostaje niższą ocenę jakości strony docelowej, co podnosi koszt kliknięcia przy tej samej pozycji reklamy. Przy dużych budżetach poprawa szybkości strony docelowej może więc obniżyć koszty kampanii.

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

Małe strony mogą mieć za mało pomiarów w CrUX, żeby pojawić się w raporcie GSC, i wtedy brakuje danych od użytkowników. Nie znaczy to, że CWV nie wpływają na doświadczenie użytkownika. Dobra jakość techniczna strony przekłada się na konwersje niezależnie od pozycji. Gdy ruch wzrośnie do progu CrUX, strona zostanie oceniona, więc warto zadbać o CWV wcześniej.

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

Google nie potwierdza takiego związku. Do AI Overviews strona musi być zaindeksowana i móc wyświetlać się z fragmentem, bez dodatkowych wymagań technicznych. Dobre CWV pomagają użytkownikom, którzy wejdą na stronę z podsumowania, ale nie są warunkiem cytowania.

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

CrUX (Chrome UX Report) to baza rzeczywistych pomiarów wydajności stron odwiedzanych przez użytkowników Chrome, którzy zgodzili się na przesyłanie danych. Małe strony mogą nie osiągać minimalnej liczby pomiarów potrzebnej do pojawienia się w CrUX. Wtedy PSI nie pokazuje danych od użytkowników, a raport GSC nie wyświetla adresów. Rozwiązanie: poczekaj na wzrost ruchu albo mierz wskaźniki samodzielnie, np. biblioteką web-vitals z wysyłką do Google Analytics. Nie zastąpi to CrUX, ale da orientację.