Core Web Vitals - szybkość strony a pozycje w Google

Twoja strona może mieć świetne treści i mocne linki, a mimo to przegrywać w Google z konkurentem, którego strona po prostu działa szybciej i płynniej. Core Web Vitals - po polsku „podstawowe wskaźniki internetowe” - to zestaw trzech mierzalnych parametrów, którymi Google ocenia realne doświadczenie użytkownika na stronie: szybkość ładowania, responsywność na interakcje i stabilność wizualną. W tym przewodniku wyjaśniamy po ludzku, co mierzą LCP, INP i CLS, jakie wartości są „dobre”, jak sprawdzić swoje wyniki w darmowych narzędziach i - najważniejsze - co konkretnie poprawić, żeby wskaźniki zzieleniały, a strona przestała gubić użytkowników i pozycje.

Czym są Core Web Vitals i dlaczego mają znaczenie

Core Web Vitals to trzy wskaźniki jakości strony wprowadzone przez Google w ramach inicjatywy Web Vitals: LCP (Largest Contentful Paint - szybkość ładowania), INP (Interaction to Next Paint - responsywność) i CLS (Cumulative Layout Shift - stabilność układu). Od 2021 roku wchodzą w skład sygnałów rankingowych związanych z doświadczeniem strony (page experience), a ich wartości dla realnych użytkowników Google zbiera przez raport CrUX (Chrome User Experience Report) - anonimowe dane z przeglądarek Chrome.

Jak mocno wpływają na pozycje? Uczciwa odpowiedź: to sygnał pomocniczy, nie główny czynnik - świetne CWV nie wyniosą słabej treści do TOP3. Ale działa to w dwie strony: przy porównywalnej jakości treści wygrywa strona o lepszym doświadczeniu, a bardzo słabe wskaźniki potrafią realnie ciążyć całej domenie. Co ważniejsze, CWV wpływają na biznes bezpośrednio, z pominięciem Google: badania od lat pokazują, że każda dodatkowa sekunda ładowania obniża konwersję o kilka-kilkanaście procent, a użytkownicy mobilni masowo porzucają strony ładujące się dłużej niż 3 sekundy. Optymalizacja CWV to więc inwestycja o podwójnym zwrocie: pozycje + konwersje.

LCP - Largest Contentful Paint (szybkość ładowania)

LCP mierzy czas od rozpoczęcia ładowania strony do wyrenderowania jej największego elementu widocznego na ekranie - zwykle zdjęcia hero, banera lub głównego bloku tekstu. To odpowiedź na pytanie użytkownika: „kiedy widzę to, po co przyszedłem?”.

• Dobrze: do 2,5 s • Wymaga poprawy: 2,5-4 s • Źle: powyżej 4 s

Najczęstsi winowajcy złego LCP: wolny hosting (długi czas odpowiedzi serwera - TTFB), nieskompresowane obrazy hero, brak priorytetu ładowania dla głównego obrazu, blokujące renderowanie skrypty i style, brak cache. Jak poprawić:

• zainwestuj w porządny hosting lub dodaj CDN - TTFB poniżej 600 ms to fundament,
• serwuj obrazy w WebP/AVIF, w wymiarach dopasowanych do ekranu, z atrybutem fetchpriority=”high” dla obrazu hero,
• NIE stosuj lazy loadingu dla elementu LCP (częsty błąd wtyczek optymalizacyjnych!),
• włącz pełne cache stron (np. LiteSpeed Cache, WP Rocket) i kompresję,
• ogranicz CSS/JS blokujące renderowanie: krytyczny CSS inline, reszta asynchronicznie.

INP - Interaction to Next Paint (responsywność)

INP zastąpił w marcu 2024 roku dawny wskaźnik FID i mierzy, jak szybko strona reaguje wizualnie na interakcje użytkownika - kliknięcia, dotknięcia, wpisywanie - przez cały czas trwania wizyty (raportowana jest zła końcówka rozkładu, nie tylko pierwsza interakcja). To odpowiedź na pytanie: „czy strona słucha, gdy klikam?”.

• Dobrze: do 200 ms • Wymaga poprawy: 200-500 ms • Źle: powyżej 500 ms

INP psuje przede wszystkim nadmiar JavaScriptu: ciężkie motywy, dziesiątki wtyczek, skrypty marketingowe i śledzące, długie zadania blokujące główny wątek przeglądarki. Jak poprawić:

• zrób audyt skryptów zewnętrznych - każdy piksel, czat i heatmapa kosztuje; usuń nieużywane,
• ładuj skrypty z atrybutami defer/async, a narzędzia marketingowe przez menedżera tagów z rozsądkiem,
• na WordPressie: przejrzyj wtyczki (mniej znaczy szybciej), rozważ lżejszy motyw,
• rozbijaj długie zadania JS i odkładaj pracę poza główny wątek (dla programistów: web workers, requestIdleCallback),
• uważaj na animowane suwaki, mega-menu i buildery stron generujące tony kodu.

CLS - Cumulative Layout Shift (stabilność wizualna)

CLS mierzy, jak bardzo elementy strony „skaczą” podczas ładowania - znasz to, gdy chcesz kliknąć przycisk, a w ostatniej chwili wskakuje baner i klikasz reklamę. To odpowiedź na pytanie: „czy strona jest stabilna, gdy z niej korzystam?”.

• Dobrze: do 0,1 • Wymaga poprawy: 0,1-0,25 • Źle: powyżej 0,25

Typowe przyczyny: obrazy i osadzenia bez zdefiniowanych wymiarów, banery zgód i reklamy wstrzykiwane nad treścią, webfonty podmieniające się z przeskokiem, dynamicznie doładowywane sekcje. Jak poprawić:

• zawsze deklaruj wymiary obrazów, wideo i iframe’ów (width/height lub aspect-ratio),
• rezerwuj miejsce na banery, reklamy i elementy dynamiczne,
• ładuj fonty z font-display: swap i preloadem kluczowych plików,
• nie wstawiaj treści nad już wyświetloną zawartością (wyjątek: reakcja na akcję użytkownika).

Dane laboratoryjne vs terenowe - dlaczego wyniki się różnią

To najczęstsze źródło zamieszania: PageSpeed Insights pokazuje dwa zestawy danych. Dane terenowe (CrUX) to realne pomiary z przeglądarek użytkowników z ostatnich 28 dni - to NIMI Google ocenia Twoją stronę. Dane laboratoryjne (Lighthouse) to jednorazowa symulacja na wystandaryzowanym urządzeniu - służy do diagnozy, nie do oceny. Stąd paradoksy: strona może mieć „czerwony” wynik Lighthouse i zielone CWV w terenie (bo realni użytkownicy mają szybkie łącza) albo odwrotnie. Zasada: cel wyznaczają dane terenowe, drogę do niego - laboratoryjne.

Ważny niuans: Google ocenia 75. percentyl - Twoja strona „zdaje” wskaźnik, jeśli dobre doświadczenie ma co najmniej 75% wizyt. Mediana nie wystarczy; liczy się też ogon wolniejszych użytkowników na słabszych telefonach i łączach.

Jak sprawdzić Core Web Vitals - narzędzia

• PageSpeed Insights - wpisujesz adres URL, dostajesz dane terenowe (jeśli strona ma wystarczający ruch) + diagnozę laboratoryjną z listą poprawek. Pierwsze i najważniejsze narzędzie.
• Google Search Console → raport „Podstawowe wskaźniki internetowe” - zbiorczy widok wszystkich podstron z podziałem na dobre/wymagające poprawy/słabe; idealny do znajdowania problematycznych grup stron.
• Lighthouse w Chrome DevTools - audyt lokalny z pełną diagnostyką; testuj w trybie incognito, żeby wtyczki przeglądarki nie zakłamywały wyniku.
• CrUX Dashboard / crux-vis - historyczne trendy danych terenowych domeny.
• Web Vitals (rozszerzenie Chrome) - podgląd wskaźników na żywo podczas przeglądania własnej strony.

Plan naprawczy dla typowej strony na WordPressie

Większość polskich stron firmowych działa na WordPressie, więc oto sprawdzona kolejność działań, od największego efektu:

• 1. Hosting - jeśli TTFB przekracza 800 ms, żadna wtyczka nie uratuje wyniku; przenosiny na porządny hosting (LiteSpeed/NVMe) to często połowa sukcesu,
• 2. Cache + kompresja - wtyczka cache (LiteSpeed Cache, WP Rocket), kompresja Brotli/GZIP, cache przeglądarki,
• 3. Obrazy - konwersja do WebP, wymiary pod ekran, lazy loading (poza hero!), kompresja stratna ~80%,
• 4. Porządki w skryptach - usunięcie zbędnych wtyczek, defer dla JS, ograniczenie skryptów marketingowych do niezbędnych,
• 5. Fonty - lokalne hostowanie, font-display: swap, preload, ograniczenie wariantów,
• 6. CLS-y - wymiary mediów, rezerwacja miejsca na banery zgód,
• 7. Pomiar po 28 dniach - dane terenowe odświeżają się kroczącym oknem 28 dni, więc na potwierdzenie efektów w CrUX trzeba poczekać.

Pułapka, którą widzimy notorycznie: instalowanie trzech „przyspieszających” wtyczek naraz, które wzajemnie się gryzą i pogarszają INP. Mniej znaczy szybciej - jedna dobra wtyczka cache plus higiena to zwykle wszystko, czego potrzebuje strona firmowa.

Core Web Vitals a SEO - ile to naprawdę daje

Uporządkujmy oczekiwania. Poprawa CWV z „czerwonych” na „zielone” rzadko sama z siebie skokowo podnosi pozycje - Google wielokrotnie potwierdzał, że treść i linki ważą więcej. Realne korzyści są jednak twarde: lepszy crawling (szybsze strony są wydajniej indeksowane), niższy współczynnik odrzuceń, wyższe konwersje z istniejącego ruchu, lepszy wynik jakości w Google Ads (tańsze kliknięcia!) oraz przewaga w wyrównanych pojedynkach rankingowych. Traktuj CWV jak higienę: nie wygrywa meczu, ale bez niej przegrywasz walkowerem. Kompleksowe spojrzenie na kondycję strony - od techniki po treści - znajdziesz w naszej checkliście audytu SEO.

Pozostałe wskaźniki Web Vitals - TTFB, FCP, TBT

Obok trzech głównych wskaźników w raportach spotkasz metryki pomocnicze - warto je rozumieć, bo diagnozują przyczyny problemów z „wielką trójką”:

• TTFB (Time to First Byte) - czas do pierwszego bajtu odpowiedzi serwera; cel poniżej 800 ms, dobrze poniżej 600 ms. Wysoki TTFB to niemal zawsze hosting lub brak cache - i pierwszy podejrzany przy złym LCP.
• FCP (First Contentful Paint) - moment pojawienia się pierwszego elementu treści; cel do 1,8 s. Duża różnica między FCP a LCP wskazuje na problem z samym elementem hero (za ciężki obraz, złe priorytety).
• TBT (Total Blocking Time) - laboratoryjny odpowiednik INP; suma czasu, przez który główny wątek był zablokowany. Wysoki TBT = za dużo JavaScriptu.
• Speed Index - tempo wizualnego wypełniania ekranu; przydatny do porównań przed/po optymalizacji.

Diagnostyczna ściąga: zły LCP przy wysokim TTFB → serwer/cache; zły LCP przy dobrym TTFB → obrazy i render-blocking; zły INP/TBT → JavaScript; zły CLS → wymiary mediów i wstrzykiwane elementy.

Core Web Vitals w e-commerce - priorytet, nie opcja

Nigdzie związek szybkości z pieniędzmi nie jest tak bezpośredni jak w sklepie internetowym. Użytkownik mobilny z koszykiem pełnym zakupów i wolną stroną płatności to utracona transakcja - badania rynkowe konsekwentnie pokazują, że poprawa LCP o sekundę przekłada się na kilkuprocentowy wzrost konwersji, co przy dużym ruchu oznacza dziesiątki tysięcy złotych rocznie. Sklepy mają przy tym najtrudniej: rozbudowane menu, filtry, sliders, skrypty rekomendacji, remarketing i czaty potrafią zdusić INP. Priorytety dla e-commerce: błyskawiczne karty produktów i checkout (to tam zapadają decyzje), obrazy produktowe w WebP z poprawnymi wymiarami (CLS!), bezlitosny audyt skryptów zewnętrznych oraz monitoring CWV per szablon strony - osobno dla kart produktów, kategorii i koszyka, bo każdy typ ma inne problemy.

Jak monitorować CWV stale, nie od święta

Jednorazowa poprawa bez monitoringu kończy się regresją po trzech aktualizacjach wtyczek. Minimalny system kontroli: co miesiąc rzut oka na raport podstawowych wskaźników w Google Search Console (grupy adresów, trend), po każdej większej zmianie na stronie (nowa wtyczka, przebudowa szablonu, nowy skrypt marketingowy) - szybki test PageSpeed Insights kluczowych podstron, a przy sklepach dodatkowo alerty na pogorszenie (narzędzia typu DebugBear czy SpeedCurve robią to automatycznie). Dobrą praktyką jest też „budżet wydajności” przy rozwoju strony: każda nowa funkcja musi się zmieścić w limicie wagi strony i czasu blokowania - inaczej wraca do poprawki. To tania polisa: pilnowanie zieleni kosztuje ułamek tego, co jej odzyskiwanie.

Studium przypadku: z czerwieni do zieleni w 30 dni

Jak wygląda taka optymalizacja w praktyce? Typowy przebieg dla strony firmowej na WordPressie (motyw z builderem, 30 wtyczek, tani hosting współdzielony):

• Stan wyjściowy: LCP 4,8 s / INP 420 ms / CLS 0,31 - wszystkie trzy wskaźniki czerwone; TTFB 1,4 s.
• Tydzień 1 - infrastruktura: migracja na hosting LiteSpeed z NVMe (TTFB spada do 380 ms), konfiguracja LiteSpeed Cache z kompresją Brotli. LCP: 4,8 → 3,1 s.
• Tydzień 2 - obrazy i fonty: masowa konwersja do WebP, wymiary i lazy loading (bez hero), fonty lokalnie z font-display: swap. LCP: 3,1 → 2,2 s; CLS: 0,31 → 0,12.
• Tydzień 3 - JavaScript: usunięcie 9 zbędnych wtyczek, defer dla skryptów, czat doładowywany po interakcji, menedżer tagów odchudzony do 3 tagów. INP: 420 → 210 ms.
• Tydzień 4 - szlif: rezerwacja miejsca na baner zgód (CLS: 0,12 → 0,06), preload obrazu hero, krytyczny CSS. Finalnie: LCP 1,9 s / INP 180 ms / CLS 0,06 - komplet zieleni w danych laboratoryjnych.

Potwierdzenie w danych terenowych CrUX przyszło zgodnie z mechaniką 28-dniowego okna - po miesiącu raport w Search Console pokazał wszystkie adresy w kategorii „dobre”. Efekt biznesowy: współczynnik odrzuceń na mobile spadł o jedną piątą, a liczba zapytań z formularza wzrosła, mimo niezmienionego ruchu. Koszt całości: hosting (ok. 600 zł/rok) plus kilkanaście godzin pracy specjalisty.

Czego NIE robić - antywzorce optymalizacji

• nie instaluj kilku wtyczek optymalizacyjnych naraz - konflikty cache’ów i podwójna minifikacja psują więcej, niż naprawiają,
• nie lazy-loaduj obrazu hero - to podręcznikowy sposób na pogorszenie LCP,
• nie goń za wynikiem 100/100 w Lighthouse - różnica między 92 a 100 punktów nie ma znaczenia biznesowego ani rankingowego; liczą się zielone progi w danych terenowych,
• nie ukrywaj problemów przed testem - sztuczki typu opóźnianie wszystkich skryptów do interakcji potrafią zawyżyć wynik laboratoryjny, pogarszając realne doświadczenie (i INP),
• nie optymalizuj tylko strony głównej - użytkownicy z Google lądują na podstronach usług i wpisach; to ich wskaźniki widzi większość odwiedzających,
• nie zapominaj o mobile - dane terenowe są zdominowane przez telefony; testuj na realnym, średniej klasy urządzeniu.

Hosting a Core Web Vitals - fundament, o którym się zapomina

W dyskusjach o optymalizacji królują wtyczki i skrypty, tymczasem najwięcej polskich stron firmowych przegrywa wskaźniki już na poziomie serwera. Hosting współdzielony za 100 zł rocznie, na którym Twoja strona sąsiaduje z setkami innych, potrafi generować TTFB powyżej sekundy w godzinach szczytu - i żadna optymalizacja frontendowa tego nie odrobi, bo LCP zaczyna się liczyć od odpowiedzi serwera. Na co patrzeć przy wyborze: dyski NVMe, serwer LiteSpeed lub nginx z HTTP/2 i HTTP/3, PHP w aktualnej wersji z OPcache, lokalizacja serwera w Polsce lub Europie (fizyczna odległość to milisekundy opóźnienia) oraz limity zasobów adekwatne do ruchu. Różnica w cenie między słabym a dobrym hostingiem dla strony firmowej to 300-600 zł rocznie - w przeliczeniu na efekt to najtańsza optymalizacja CWV, jaką można kupić. Przy sklepach i serwisach z ruchem powyżej kilkudziesięciu tysięcy wizyt miesięcznie standardem staje się VPS lub hosting menedżerowany plus CDN, który serwuje statyczne zasoby z serwera najbliższego użytkownikowi.

Core Web Vitals a wyszukiwanie AI - nowy powód, by być szybkim

Warto dodać argument, który pojawił się wraz z erą odpowiedzi generatywnych: crawlery systemów AI (Googlebot dla AI Overview, GPTBot, PerplexityBot) pracują na budżetach - wolne strony są crawlowane rzadziej i płycej, co ogranicza szansę na obecność w cytowaniach. Strona techniczne sprawna to warunek udziału we wszystkich kanałach naraz: klasycznym rankingu, AI Overview i rekomendacjach chatbotów. Szybkość przestała być tylko „czynnikiem UX” - stała się biletem wstępu do widoczności w ogóle. Jeśli chcesz wiedzieć, gdzie Twoja strona gubi milisekundy i pozycje, napisz do nas - diagnoza wskaźników to stały element naszych audytów.

Ściąga: progi Core Web Vitals w jednym miejscu

• LCP - dobre ≤ 2,5 s · do poprawy 2,5-4 s · złe > 4 s,
• INP - dobre ≤ 200 ms · do poprawy 200-500 ms · złe > 500 ms,
• CLS - dobre ≤ 0,1 · do poprawy 0,1-0,25 · złe > 0,25,
• pomocniczo: TTFB ≤ 800 ms, FCP ≤ 1,8 s,
• ocena: 75. percentyl danych terenowych CrUX z okna 28 dni.

FAQ

Czym są Core Web Vitals najprościej?

To trzy wskaźniki, którymi Google mierzy jakość doświadczenia na stronie: LCP (jak szybko ładuje się główna treść - cel do 2,5 s), INP (jak szybko strona reaguje na kliknięcia - cel do 200 ms) i CLS (czy elementy nie skaczą podczas ładowania - cel do 0,1). Dane pochodzą od realnych użytkowników Chrome.

Czy Core Web Vitals wpływają na pozycje w Google?

Tak, ale jako sygnał pomocniczy - treść i autorytet ważą więcej. CWV robią różnicę w wyrównanej konkurencji, wpływają na wydajność indeksowania, a bardzo słabe wyniki ciążą domenie. Bezpośredni i pewny jest za to wpływ na konwersje: szybsze strony po prostu więcej sprzedają.

Co zastąpiło FID i czym jest INP?

W marcu 2024 roku wskaźnik FID (opóźnienie pierwszej interakcji) został zastąpiony przez INP (Interaction to Next Paint), który mierzy responsywność wszystkich interakcji w trakcie całej wizyty, nie tylko pierwszej. INP jest wymagającym wskaźnikiem - strony przeładowane JavaScriptem, które „zdawały” FID, z INP często mają problem.

Jak sprawdzić Core Web Vitals mojej strony?

Najszybciej w PageSpeed Insights (pagespeed.web.dev) - zobaczysz dane terenowe z realnych wizyt i diagnozę z listą poprawek. Zbiorczy obraz wszystkich podstron znajdziesz w Google Search Console w raporcie „Podstawowe wskaźniki internetowe”. Pamiętaj: liczą się dane terenowe (CrUX), test laboratoryjny to tylko symulacja diagnostyczna.

Dlaczego mam dobry wynik w Lighthouse, a słabe CWV (albo odwrotnie)?

Bo to dwa różne pomiary: Lighthouse symuluje jedno wejście na wystandaryzowanym urządzeniu, a CWV agregują 28 dni realnych wizyt Twoich użytkowników - z ich telefonami i łączami. Google ocenia stronę po danych terenowych (75. percentyl), więc to one są celem; Lighthouse służy do znajdowania przyczyn.

Ile kosztuje poprawa Core Web Vitals?

Podstawowy pakiet (lepszy hosting ~400-1000 zł/rok, konfiguracja cache i optymalizacja obrazów - kilka godzin pracy) rozwiązuje problem większości stron firmowych; u specjalisty to zwykle 500-2000 zł jednorazowo. Głęboka optymalizacja rozbudowanego sklepu z dziesiątkami skryptów potrafi kosztować 5000-15 000 zł, ale zwraca się w konwersjach i tańszych kliknięciach Google Ads.

« wróć na bloga