Core Web Vitals a pozycje w Google - ktore metryki realnie wplywaja na SEO

Kazdy, kto zajmuje sie SEO od kilku lat, slyszal ten argument: "popraw Core Web Vitals, bo Google je karze". Jedni wrzucaja miesiacami budzety w optymalizacje wydajnosci, inni machneli reka i pozycjonuja sie bez problemu z Lighthousem na poziomie 45/100. Prawda, jak zwykle, lezy gdzies posrodku - i jest bardziej konkretna niz wiekszosc poradnikow na ten temat.

W tym artykule rozkladam na czesci, co Google faktycznie robi z metrykami LCP, INP i CLS przy ustalaniu pozycji. Pokazuje, kiedy optymalizacja ma sens, kiedy to strata czasu, i jak podchodzic do tematu praktycznie - szczegolnie na WordPressie i WooCommerce, gdzie pracowalem przy ponad 120 projektach przez ostatnie 13 lat.

Czym sa Core Web Vitals i skad sie wziety

Core Web Vitals to trzy metryki wydajnosci, ktore Google oficjalnie wlaczyl do zestawu sygnałow rankingowych w czerwcu 2021 r. w ramach tzw. Page Experience update. Skupiaja sie na trzech aspektach doswiadczenia uzytkownika:

• LCP (Largest Contentful Paint) - czas do wyswietlenia najwiekszego widocznego elementu na stronie (najczesciej glowny obraz lub naglowek H1). Dobry wynik: ponizej 2,5 s.
• INP (Interaction to Next Paint) - responsywnosc strony na interakcje uzytkownika (klikniecia, tapniecia, nacisnieciai klawiatury). Dobry wynik: ponizej 200 ms.
• CLS (Cumulative Layout Shift) - stabilnosc wizualna strony, czyli jak bardzo elementy przeskakuja podczas ladowania bez dzialania uzytkownika. Dobry wynik: ponizej 0,1.

Wazna zmiana z marca 2024 roku: INP oficjalnie zastapilo FID (First Input Delay). FID mierzyl tylko pierwsza interakcje uzytkownika ze strona. INP mierzy WSZYSTKIE interakcje przez caly czas trwania sesji - co jest znacznie surowsza miara, szczegolnie dla stron z duza iloscia JavaScriptu.

Jak Google naprawde uzywa tych danych - pole vs laboratorium

To jest miejsce, gdzie wiekszos poradnikow myli czytelnikow. Istnieja dwa rodzaje danych o wydajnosci strony:

Dane laboratoryjne (Lab Data) - to, co wida w Lighthouse lub PageSpeed Insights w czeskim "Performance Score". Narzedzie symuluje ladowanie strony w kontrolowanych warunkach sieciowych. Swietne do diagnostyki, ale Google NIE uzywa tych danych do rankingowania.

Dane pola (Field Data / CrUX) - to pomiary zebrane od rzeczywistych uzytkownikow przegladarki Chrome w ostatnich 28 dniach. Google uzywa 75. percentyla tych danych - oznacza to, ze 75% Twoich uzytkownikow musi miec dobry wynik, zeby strona zaliczyla sie jako "dobre" CWV.

Dodatkowy problem: jezeli Twoja strona ma zbyt maly ruch, Google nie ma wystarczajacych danych CrUX. W takim przypadku sygnal CWV w ogole nie jest stosowany dla tej strony. Analiza Ahrefs oszacowala, ze dotyczy to okolo 88% stron w internecie. Innymi slowy - jezeli prowadzisz nowa strone lub mala witryne lokalna, CWV prawdopodobnie nie wplywa na Twoje pozycje w ogole.

Co John Mueller powiedzial o sile sygnalu CWV

Nie ma sensu omijac tego tematu: John Mueller z Google wielokrotnie publicznie ostudzil entuzjazm wokol Core Web Vitals jako czynnika rankingowego. Najglosniejsze jego stwierdzenie brzmialo: "mało prawdopodobne jest duze spadki pozycji wylacznie z powodu CWV" oraz "pogon za idealnym wynikiem CWV tylko dla SEO moze nie byc najlepszym wykorzystaniem Twojego czasu".

Danny Sullivan (Google Search Liaison) doprecyzowal w 2023 r., ze Page Experience zostalo usuniete z listy "systemow rankingowych" Google, ale pozostalo aktywnym sygnałem uzywanym przez inne systemy. To subtelna, ale wazna roznica.

Praktyczna interpretacja: CWV dzialaja bardziej jak czynnik rownowazacy niz dominujacy. Przy dwoch stronach o podobnej tresci, linkach i autorytecie, ta z lepszymi CWV bedzie miala przewage. Ale swietna, ekspercka tresc ze srednimi CWV bedzie bic slaba tresc z idealnym Lighthousem.

LCP - jak to dziala i co go psuje

LCP mierzy, kiedy glowna zawartosc strony staje sie widoczna. Typowe elementy LCP to: obraz bohatera, duzy naglowek H1, thumbnail produktu na stronie kategorii. W sklepach WooCommerce najczestszym elementem LCP jest glowne zdjecie produktu na stronie produktu.

Najczestsze przyczyny zlego LCP:

1. Wolny serwer (wysoki TTFB, czyli czas do pierwszego bajtu). Jezeli TTFB przekracza 600 ms, problem jest na poziomie hostingu, nie optymalizacji frontendu.
2. Obraz LCP ladowany z lazy-loadingiem - to klasyczny blad. Element LCP nigdy nie powinien miec atrybutu loading="lazy".
3. Obraz LCP nie jest preloadowany - przeglgladarka "odkrywa" go za pozno. Rozwiazanie: <link rel="preload" as="image" href="...">.
4. Obraz w zlym formacie (JPEG zamiast WebP lub AVIF) i nieoptymalizowany rozmiar.
5. Render-blocking CSS lub JS wstrzymujace renderowanie strony.

U klienta prowadzacego sklep z meblami dzieciecymi na WooCommerce mialem przypadek, gdzie LCP wynosilo 4,2 s mimo dobrego hostingu. Problem: motyw ladowal slider na stronie glownej przez zewnetrzny skrypt, ktory blokowal renderowanie przez ponad 1,8 s. Po usunieciu slidera i zastapeniu go statycznym obrazem w formacie WebP, LCP spadlo do 1,9 s. Zadna zmiana hostingu, zadna zmiana CSS - tylko usuniecir jednego zbednego skryptu.

INP - najnowsza i najtrudniejsza metryka

INP (Interaction to Next Paint) to metryka, ktora sprawia najwiecej klopotow w 2025-2026. Od marca 2024 zastapila FID i jest surowsza z kilku powodow.

FID mierzyl tylko opoznienie pierwszej interakcji, tzn. ile czasu mija od klikniecia do momentu, gdy przeglgladarka zaczyna przetwarzac zdarzenie. INP mierzy caly cykl: od interakcji do momentu, gdy ekran faktycznie sie odswiezyl (Input Delay + Processing Time + Presentation Delay). I robi to dla WSZYSTKICH interakcji w trakcie wizyty, nie tylko pierwszej.

Dla prostego bloga informacyjnego INP rzadko jest problemem. Dla sklepu WooCommerce z filtrowaniem produktow, live searchem, chatem i skomplikowanym koszykiem - INP moze byc poważnym wyzwaniem.

Jak poprawic INP:

• Usun lub odrocz ciezki JavaScript (wczytuj skrypty third-party po interakcji uzytkownika).
• Podziel dlugie zadania JavaScriptu (Long Tasks powyzej 50 ms) na mniejsze czasy wykonania.
• Ogranicz ilosc event listenerow i upewnij sie, ze kod obslugi zdarzen jest mozliwie prosty.
• Korzystaj z Web Workers dla obliczen w tle.
• Sprawdz raport "Slow Interactions to Next Paint" w Chrome DevTools (Performance panel).

W Search Console raport CWV pokazuje strony z problemami INP agregowane po grupach URL. To dobry punkt startu, bo od razu widac, czy problem dotyczy np. wszystkich stron produktow czy tylko stron kategorii.

CLS - przesuwajacy sie layout, ktory irytuje uzytkownikow i Google

Cumulative Layout Shift mierzy niestabilnosc wizualna - czyli jak czesto i jak mocno elementy przeskakuja podczas ladowania bez interakcji uzytkownika. Wynik 0 oznacza, ze nic sie nie ruszalo. Wynik 0,5 oznacza powazny problem.

Najczestsze przyczyny zlego CLS:

1. Obrazy bez zdefiniowanych wymiarow (brak width i height w HTML). Przeglgladarka nie wie, ile miejsca zarezerwowac przed zaladowaniem obrazu.
2. Czcionki webowe powodujace FOUT (Flash of Unstyled Text) - zamiana systemowej czcionki na webfont przesuwa elementy.
3. Banery cookie, powiadomienia push, live chat - wszystkie elementy dynamicznie wstrzykiwane do DOM po zaladowaniu strony.
4. Reklamy bez zarezerwowanego miejsca.
5. W WooCommerce: powiadomienia o koszyku, belki z ofertami, dynamicznie ladowane produkty "klienci kupili rowniez".

Praktyczny tip: jezeli korzystasz z Google Fonts, przenies czcionki na wlasny serwer (@font-face z lokalnych plikow) i uzyj font-display: swap. To eliminuje FOUT powodowany przez zewnetrzne serwery Googlea.

Realny wplyw na pozycje - mity i fakty

Mit: "przejscie z 65/100 do 95/100 w Lighthouse da mi +10 pozycji".
Fakt: Lighthouse to dane laboratoryjne, ktore Google nie uzywa do rankingowania.

Mit: "moje CWV sa slabe, wiec Google karze moja strone".
Fakt: jezeli Twoja strona ma maly ruch i brak danych CrUX, sygnal CWV nie jest w ogole stosowany.

Mit: "Core Web Vitals wazniejsze sa niz tresc".
Fakt: Google wielokrotnie potwierdzil odwrotna hierarchie. Tresc, relevancja i autorytet domeny sa dominujacymi czynnikami.

Fakt, ktory sie liczy: przejscie ze statusu "slabe" do "dobre" w rzeczywistych danych CrUX ma mierzalny wplyw na rankingi, szczegolnie w niszach z podobna jakoscia tresci u konkurencji. Takie przejscie jest warte inwestycji.

Fakt, ktory sie liczy dla e-commerce: Badanie Google i Deloitte "Milliseconds Make Millions" dokumentuje, ze kazde 0,1 s przyspieszenia ladowania moze zwiekszac konwersje o 8% w handlu detalicznym. Vodafone zaraportowalo 8% wzrost sprzedazy po poprawie LCP o 31%. Rakuten odnotowalo 33% wzrost konwersji po optymalizacji CWV. Argument za optymalizacja jest tutaj bardziej biznesowy niz SEO.

Narzedzia do audytu CWV - od czego zaczac

Kolejnosc ma znaczenie:

1. Google Search Console - raport Core Web Vitals (lewy panel > Doswiadczenie > Core Web Vitals). To jest zrodlo danych, ktore Google faktycznie uzywa. Raport pokazuje zagregowane wyniki dla grup URL (strony produktow, posty bloga, strony glowna etc.) i rozdziela dane mobilne od desktopowych. Zacznij tutaj.

2. PageSpeed Insights (pagespeed.web.dev) - dla konkretnego URL laczy dane CrUX (pole) z diagnostyka Lighthouse (lab). Jezeli widoczna jest sekcja "Dane pola", masz prawdziwe dane. Jezeli jej nie ma - za malo ruchu.

3. Chrome DevTools (F12 > Lighthouse lub Performance) - do diagnozowania konkretnych problemow. Panel Performance pozwala nagrac interakcje i zobaczyc dokladnie, co spowalnia INP.

4. web-vitals.js - biblioteka JavaScriptu do zbierania danych CWV bezposrednio z Twojej strony i wysylania ich do Analytics lub dowolnego systemu monitoringu.

Do pozycjonowania stron firmowych i sklepow klientow korzystam ze standardowej troiki: GSC jako zrodlo prawdy, PSI do analizy URL-po-URL, DevTools do glebokiej diagnostyki. Zewnetrzne narzedzia jak Semrush lub Ahrefs czerpie dane z tych samych zrodel, wiec nie daja dodatkowej wartosci dla CWV specyficznie.

Jak poprawic Core Web Vitals na WordPressie - praktyczny plan

WordPress i WooCommerce maja specyficzne wyzwania: duza ilosc pluginow, tematy ladujace wiele skryptow, bazy danych generujace zapytania przy kazdym requescie. Oto kolejnosc dzialan, ktora stosuje w projektach:

Krok 1 - Hosting i TTFB
Jezeli TTFB przekracza 800 ms, reszta optymalizacji bedzie walka z wiatrakami. Na LH.pl (gdzie hostuje wiele klientow) TTFB przy wlaczonym cache jest ponizej 200 ms. Na tanich shared hostingach bywa 1-3 s. Rozwiazanie: wydzierzonienie serwera VPS lub przejscie na hosting z LiteSpeed Web Server.

Krok 2 - Cache na poziomie serwera i pluginu
LiteSpeed Cache (plugin, darmowy, wymaga LiteSpeed na serwerze) daje najlepsze wyniki CWV przy odpowiedniej konfiguracji. Na hostingach Apache lub nginx - WP Rocket (59 USD/rok za 1 strone). Oba pluginy obsluguja automatyczny preload cache, minifikacje CSS/JS i integracje z CDN.

Krok 3 - Optymalizacja obrazow
Kazdy obraz powinien miec zdefiniowane width i height (eliminuje CLS), byc skonwertowany do WebP lub AVIF (mniejszy rozmiar, szybszy LCP) i miec native lazy-loading - z wyjatkiem obrazu LCP, ktory zawsze ladowany jest bez lazy i z preloadem.

Krok 4 - JavaScript
Pluginy sa glownym zrodlem problemow z INP. Usun nieuzywane pluginy, odrocz ladowanie skryptow third-party (chat, heatmapy, marketing automation) az do momentu interakcji uzytkownika. Uzyj Query Monitor, aby zobaczyc, ktore pluginy generuja zapytania i skrypty.

Krok 5 - CDN
Cloudflare w darmowym planie jest wystarczajacy dla wiekszosci projektow MSP. Przyspiesza dostarczanie statycznych zasobow, dodaje cache na krawedzi sieci i redukcuje czas odpowiedzi dla uzytkownikow z roznych lokalizacji. Wazne przy sklepach z klientami w calej Polsce i Niemczech.

Jezelii chcesz dowiedziec sie wiecej o kompleksowym podejsciu do pozycjonowania SEO, sprawdz rowniez jak AI Overview Google wplywa na widocznosc organiczna - bo szybkosc strony wplywa takze na szanse cytowania przez AI.

Kiedy WARTO, a kiedy NIE WARTO priorytetyzowac CWV

Moje rekomendacje po 13 latach projektow:

Warto inwestowac czas w CWV, gdy:

• Twoja strona/sklep ma setki lub tysiace unikalnych uzytkownikow miesiecznie (dostepne dane CrUX).
• Status w GSC to "slabe" lub "wymaga poprawy" - jest potencjal do przejscia do "dobre".
• Prowadzisz sklep e-commerce, gdzie szybkos bezposrednio wplywa na konwersje.
• Konkurencja w Twojej niszy ma podobna jakosc tresci - CWV moze byc czynnikiem przewagi.

Mozna odpuscic lub odlozyc, gdy:

• Strona jest nowa lub ma maly ruch (brak danych CrUX = sygnal nie jest uzywany).
• Metryki sa juz w strefie "dobre" - przejscie z 1,8 s do 1,2 s LCP nie da mierzalnego efektu rankingowego.
• Poprawa wymagalaby przeprojektowania architektury strony za nieadekwatna cene wzgledem potencjalnego efektu.
• Masz powazne problemy z trescia, linkami lub technicalnym SEO - te poprawy daja wiekszy zwrot.

Widze, ze wiele agencji SEO sprzedaje optymalizacje CWV jako "must have" dla kazdej strony. To czesto nie jest prawda. Dla malej strony wizytowkowej fryzjera z Poznania, ktorej Google nie ma danych CrUX, dwie godziny pracy nad trescia i linkowaniem lokalnym przyniesie 10x wiekszy efekt niz caly dzien walki z Lighthousem.

Jesli interesuje Cie lokalne SEO, sprawdz jak skutecznie wejsc do Map Google dla biznesu lokalnego - tam CWV prawie w ogole nie gra roli, a profil GMB i recenzje decyduja o widocznosci.

Podsumowanie - mit vs fakt, skondensowana wersja

Core Web Vitals sa realnym sygnałem rankingowym Google - ale sygnałem o umiarkowanej sile, nie o dominujacej. Dzieje sie tu kilka rzeczy naraz:

Po pierwsze, sygnał dziala tylko wtedy, gdy strona ma wystarczajace dane CrUX. Dla zdecydowanej wiekszosci stron w internecie ten warunek nie jest spelniany. Po drugie, Google uzywa danych pola (rzeczywistych pomiarow uzytkownikow Chrome), a nie Lighthousa - wiec wynik laboratoryjny PSI jest punktem diagnostycznym, nie celem samym w sobie. Po trzecie, wartosc optymalizacji CWV dla sklepow e-commerce jest wiekesza przez pryzmat konwersji niz przez pryzmat SEO.

Jezeli Twoja strona ma "slabe" CWV i realny ruch uzytkownikow - warto to naprawiac. Jezeli ma juz zielone metryki - zajmij sie trescia, linkami i architektura informacji. I jesli chcesz wiedziec, jak to wszystko uklada sie w szersza strategie, zerknij na przewodnik SEO i widocznosc w AI na 2026 rok, ktory pokazuje pelny obraz dzisiejszego pozycjonowania.

Jestem webdeveloperem WordPress od 13 lat i przy stronach internetowych oraz sklepach internetowych regularnie przechodze przez te analizy z klientami. Jezeli potrzebujesz audytu lub konkretnych rekomendacji - odezwij sie.

Najczęstsze pytania

Czy Core Web Vitals sa bezposrednim czynnikiem rankingowym Google?

Tak, ale z zastrzezeniami. Google oficjalnie potwierdza, ze CWV sa sygnałem rankingowym w ramach tzw. Page Experience. John Mueller z Google powiedzial jednak wprost, ze to 'nie sa gigantyczne czynniki' i ze mało prawdopodobne jest duze spadki pozycji wylacznie z ich powodu. Tresc i relevancja strony pozostaje wazniejsza. CWV dzialaja jako czynnik rownowazacy przy stronach o podobnej jakosci tresci.

Co sie stanie, jesli moja strona ma 'slabe' Core Web Vitals?

W praktyce strona moze tracic pozycje w porownaniu do konkurencji z podobna trescia, ale majaca lepsze metryki. Wieksze ryzyko to jednak odpady uzytkownikow: strony ladujace ponad 3 s tracca okolo 53% odwiedzajacych na mobilce (dane Google). Pierwsze dzialanie powinno byc sprawdzenie, czy strona ma w ogole dane CrUX w Google Search Console - jezeli trafila do kategorii 'brak danych', sygnał CWV nie jest stosowany.

Jaka jest roznica miedzy danymi laboratoryjnymi Lighthouse a danymi pola CrUX?

Lighthouse (dostepny przez PageSpeed Insights lub DevTools) symuluje ladowanie strony w kontrolowanych warunkach - to swietne narzedzie diagnostyczne, ale Google NIE uzywa tych wynikow do rankingu. Do rankingu uzywa danych CrUX, czyli rzeczywistych pomiarow zebranych od uzytkownikow Chrome w ostatnich 28 dniach, na 75. percentylu. Mozna miec Lighthouse 95/100 i nadal miec slabe CWV w GSC, jezeli prawdziwi uzytkownicy korzystaja ze slow polo badz starszych telefonow.

INP zastapilo FID - co to oznacza dla mojego sklepu WooCommerce?

Od 12 marca 2024 r. obowiazuje INP (Interaction to Next Paint) zamiast FID. Zmiana jest wazna dla e-commerce: FID mierzyl tylko PIERWSZA interakcje, INP mierzy WSZYSTKIE interakcje przez caly czas trwania wizyty. Sklepy z duza iloscia JavaScriptu (filtry, koszyk, live search, chatbot) sa narazane znacznie bardziej. Dobry INP to ponizej 200 ms, 200-500 ms wymaga poprawy, powyzej 500 ms to wynik slaby wplywajacy negatywnie na ranking.

Czy moge miec dobry wynik SEO przy slabych Core Web Vitals?

Tak, to czesta sytuacja. Wiele stron informacyjnych o silnym profilu linkowym i swietnej tresci pozycjonuje sie wysoko mimo srednych metryk CWV. Google sam potwierdzil ten priorytet: relevancja i autorytet strony wazniejszy jest od technikalii. Niemniej dla sklepow internetowych optymalizacja CWV ma dodatkowy wymiar biznesowy - szybsze strony po prostu lepiej konwertuja.

Jak sprawdzic Core Web Vitals mojej strony?

Najlepsze narzedzia to: (1) Google Search Console - raport Core Web Vitals, dane pola dla calej domeny; (2) PageSpeed Insights (pagespeed.web.dev) - laczy dane laboratoryjne z danymi CrUX dla konkretnego URL; (3) Chrome DevTools (F12 > Lighthouse lub Performance) - analiza diagnostyczna. Zaczynaj od GSC, bo tylko tam zobaczysz, czy Google ma wystarczajace dane do rankingowania i jak ocenia poszczegolne grupy stron.

Czy plugin cache wystarczy do poprawienia Core Web Vitals na WordPressie?

Plugin cache to dobry start, ale rzadko wystarczy sam w sobie. Cache redukuje TTFB i pomaga LCP, ale nie naprawia CLS (przesuniec layoutu) ani INP (powolnego JavaScriptu). Dobry efekt daje kombinacja: szybki hosting (LiteSpeed lub nginx), plugin cache (LiteSpeed Cache gratis lub WP Rocket od 59 USD/rok), CDN (Cloudflare w darmowym planie), optymalizacja obrazow (WebP, prawidlowe wymiary, preload LCP image) i audyt JavaScriptu (defer/async, usuwanie nieuzywanych skryptow).

Jak dlugo Google potrzebuje na odnotowanie poprawy Core Web Vitals w rankingach?

CrUX zbiera dane w oknie 28-dniowym. Oznacza to, ze po wdrozeniu optymalizacji musisz poczekac od 4 do 8 tygodni, zanim nowe dane pelnie wplyna na raport w GSC i potencjalnie na ranking. Nie oceniaj zmian po tygodniu - to zbyt krotki okres. Kontrola wynikow powinna byc regularna: sprawdz GSC po 30 i po 60 dniach od wdrozenia zmian.