Klient klika w wynik wyszukiwania, patrzy na biały ekran, wraca do Google i wchodzi do konkurencji. Trwa to trzy sekundy i nie zostawia po sobie żadnego śladu w statystykach sprzedaży, poza tym, że jej nie ma. Core Web Vitals to trzy liczby, którymi Google mierzy dokładnie ten moment. Poniżej: co dokładnie mierzą, jak mocno naprawdę wpływają na pozycje, co najczęściej spowalnia polskie strony i ile kosztuje doprowadzenie tego do porządku.
Krótka odpowiedź: Core Web Vitals to trzy metryki oceniające realne doświadczenie użytkownika. LCP (do 2,5 s), INP (do 200 ms) i CLS (do 0,1). Są potwierdzonym sygnałem rankingowym, ale słabszym niż treść: rozstrzygają remisy między stronami podobnej jakości. Znacznie mocniej działają pośrednio, wolna strona traci klienta, zanim Google zdąży cokolwiek ocenić.
Co znajdziesz w tym artykule
- Czym są Core Web Vitals — trzy metryki i ich progi?
- Czy Core Web Vitals naprawdę wpływają na pozycje
- Jak sprawdzić swoją stronę w 10 minut?
- Najczęstsi winowajcy wolnych stron
- Co poprawisz sam, a do czego potrzebujesz programisty?
- Ile kosztuje doprowadzenie strony do zieleni?
- Jak zbudowaliśmy tę stronę — nasze liczby?
- Kiedy Core Web Vitals nie są Twoim problemem?
- Najczęstsze pytania
Czym są Core Web Vitals — trzy metryki i ich progi?
Core Web Vitals (po polsku: podstawowe wskaźniki internetowe) to trzy pomiary, które Chrome zbiera od prawdziwych użytkowników odwiedzających Twoją stronę. Nie z symulacji, nie z testu na szybkim łączu w biurze, z telefonów ludzi stojących na przystanku z jedną kreską zasięgu.
| Metryka | Co mierzy | Dobry wynik | Najczęstsza przyczyna problemu |
|---|---|---|---|
| LCP Largest Contentful Paint | kiedy widać główny element: zdjęcie w nagłówku albo duży tytuł | do 2,5 s | ciężkie zdjęcie i wolny serwer |
| INP Interaction to Next Paint | ile czasu mija od kliknięcia do reakcji strony | do 200 ms | nadmiar JavaScriptu z wtyczek |
| CLS Cumulative Layout Shift | czy treść przeskakuje podczas ładowania | do 0,1 | obrazy i reklamy bez zarezerwowanego miejsca |
LCP — jak szybko widać główną treść?
LCP mierzy moment, w którym na ekranie pojawia się największy widoczny element: zwykle zdjęcie w sekcji powitalnej albo duży nagłówek. To najbliższy odpowiednik potocznego „strona się załadowała”. Na wynik LCP składają się dwie rzeczy: jak szybko odpowiada serwer (TTFB, czyli czas do pierwszego bajtu, cel poniżej 800 ms) i ile waży to, co ma się wyświetlić.
INP — czy strona reaguje na kliknięcie?
INP sprawdza, ile czasu mija od kliknięcia do widocznej reakcji: rozwinięcia menu, otwarcia zakładki, dodania produktu do koszyka. Mierzy wszystkie interakcje w trakcie wizyty i bierze pod uwagę tę najgorszą. W marcu 2024 roku zastąpił starszy wskaźnik FID, który badał wyłącznie pierwsze kliknięcie, a to było zbyt pobłażliwe, bo problemy zaczynały się zwykle później.
CLS — czy treść skacze pod palcem?
Znasz to z telefonu: sięgasz po przycisk „Zadzwoń”, w tym momencie doładowuje się baner, cała strona przesuwa się w dół i trafiasz w link do polityki prywatności. CLS zlicza takie przeskoki. Powstają, gdy przeglądarka nie wie z góry, ile miejsca zajmie obrazek, reklama albo font, więc najpierw rysuje układ bez nich, a potem go przebudowuje.
Dlaczego liczy się 75. percentyl, a nie średnia?
Google nie uśrednia wyników, tylko sprawdza, czy trzy czwarte wizyt zmieściło się w progu. Średnia potrafi ukryć katastrofę: jeśli połowa użytkowników ma LCP 1 s, a połowa 6 s, średnia wynosi przyzwoite 3,5 s, a co druga osoba widzi pustą stronę przez sześć sekund. Dane pochodzą z raportu CrUX i obejmują ruchome okno 28 dni, dlatego po wdrożeniu poprawek wynik w Search Console zmienia się dopiero po kilku tygodniach.
Czy Core Web Vitals naprawdę wpływają na pozycje?
Tak, ale nie tak mocno, jak sugerują nagłówki agencyjnych blogów. Google potwierdził, że Core Web Vitals wchodzą w skład sygnałów Page Experience i są brane pod uwagę przy ustalaniu kolejności wyników. Waga tego sygnału jest jednak mała w porównaniu z dopasowaniem treści do zapytania i autorytetem domeny. Zielone wskaźniki nie wypchną słabej strony na pierwsze miejsce.
Znaczenie pojawia się przy remisie. Gdy dwie strony odpowiadają na to samo zapytanie równie dobrze i mają zbliżony profil linków, o kolejności decydują drobiazgi, a szybkość jest jednym z nich. W praktyce oznacza to tyle: optymalizacja szybkości nie zastąpi treści ani linków, ale potrafi rozstrzygnąć walkę o pozycje 3–7, gdzie różnice bywają minimalne. Dlatego traktujemy ją jako część pozycjonowania stron, a nie osobną usługę techniczną.
Wpływ pośredni, który jest mocniejszy od bezpośredniego
Prawdziwy koszt wolnej strony rozgrywa się poza algorytmem. Badania Google i Deloitte pokazują, że przy wydłużeniu ładowania z 1 do 3 sekund prawdopodobieństwo porzucenia strony rośnie o 32%, a przy 5 sekundach o 90%. Amazon policzył, że każde 100 ms opóźnienia kosztuje go 1% sprzedaży. Renault po skróceniu LCP o sekundę odnotował 13% wzrostu konwersji.
Dla firmy usługowej przekłada się to na coś prostszego: klient, który nie doczekał, nie zadzwoni. A jeśli wrócił do wyników wyszukiwania i kliknął konkurenta, Google też to widzi. Ten sygnał, natychmiastowy powrót do SERP-a, jest dla algorytmu czytelniejszy niż same milisekundy. Przy pozycjonowaniu lokalnym ma to podwójne znaczenie, bo ruch z map i zapytań „w pobliżu” jest niemal wyłącznie mobilny, często na przeciętnym zasięgu.
Core Web Vitals a widoczność w AI Overviews
Odpowiedzi generowane przez Google i chaty pokroju ChatGPT czy Perplexity cytują konkretne strony. Modele nie mierzą LCP, ale korzystają z treści, które trzeba najpierw pobrać i przetworzyć, a strona, która długo odpowiada albo renderuje treść dopiero JavaScriptem po stronie przeglądarki, bywa dla nich po prostu pusta. Szybki, statyczny HTML jest tu warunkiem wejścia, nie ozdobą. Rozwijamy ten wątek przy widoczności w AI.
Szybkość strony a koszt reklam w Google Ads
To najmniej znany koszt wolnej strony. W kampaniach Google Ads jednym ze składników Wyniku Jakości jest jakość strony docelowej, a szybkość ładowania wchodzi w jej skład. Niższy Wynik Jakości oznacza wyższą stawkę za to samo kliknięcie i tę samą pozycję reklamy. Wolna strona podnosi więc rachunek za reklamę niezależnie od tego, co dzieje się w wynikach organicznych.
Jak sprawdzić swoją stronę w 10 minut?
Wejdź na PageSpeed Insights, wklej adres i przełącz na widok mobilny. Interesuje Cię wyłącznie górna sekcja: „Dane pochodzące od rzeczywistych użytkowników”. To realne pomiary z ostatnich 28 dni i tylko one liczą się dla Google. Punktacja poniżej, ta kolorowa z liczbą 0–100, pochodzi z symulacji laboratoryjnej i służy do debugowania, nie do oceny.
Dlatego strona może mieć 95 punktów w teście i czerwone Core Web Vitals w danych rzeczywistych, albo odwrotnie. Test laboratoryjny odpala się raz, na symulowanym urządzeniu, przy stabilnym łączu. Dane terenowe zbierają wszystko: stare telefony, słaby zasięg, przeciążony serwer w poniedziałek rano.
Drugi krok to raport Podstawowe wskaźniki internetowe w Google Search Console. PageSpeed pokazuje jeden adres, Search Console grupuje całą witrynę i mówi, ile adresów jest w kłopotach oraz co je łączy. Zwykle okazuje się, że problem dotyczy jednego szablonu, na przykład wszystkich wpisów blogowych albo wszystkich kart produktów.
Jeśli Twoja strona ma mały ruch, w PageSpeed Insights nie zobaczysz danych terenowych. Chrome potrzebuje odpowiedniej liczby wizyt, żeby je udostępnić. Wtedy zostaje test laboratoryjny i zdrowy rozsądek: zmierz czas ładowania na własnym telefonie, w transmisji komórkowej, poza domowym wi-fi.
Najczęstsi winowajcy wolnych stron
Po kilkunastu latach zaglądania pod maskę polskich stron firmowych lista podejrzanych jest krótka i powtarzalna.
Page builder — najdroższy kilobajt w polskim WordPressie
Elementor, WPBakery czy Divi pozwalają zbudować stronę bez kodu i za to je lubimy. Płaci się jednak wagą: builder ładuje własny zestaw CSS i JavaScriptu na każdej podstronie, także tam, gdzie użyto z niego dwóch funkcji. Do tego dochodzą dodatki rozszerzające builder, każdy z własnymi plikami. Typowa strona firmowa na takim zestawie waży 2–4 MB i osiąga LCP w okolicach 4–7 sekund w transmisji komórkowej.
Da się to poprawić: wyłączaniem nieużywanych modułów, opóźnianiem skryptów, agresywnym cache’owaniem. Do pewnego momentu. Potem walczy się z fundamentem, a nie z ustawieniami, i taniej wychodzi zbudować stronę od nowa niż w nieskończoność łatać starą.
Zdjęcia w pełnej rozdzielczości
Klasyk: zdjęcie prosto z aparatu, 4000 pikseli szerokości i 3 MB wagi, wrzucone do galerii i wyświetlane w okienku o szerokości 400 pikseli. Przeglądarka i tak musi pobrać całość. Konwersja do WebP zmniejsza plik o 25–35% wobec JPEG i o 60–80% wobec PNG, a zmiana wymiarów do realnie potrzebnych, jeszcze kilkukrotnie.
Wtyczki, z których każda dokłada własne skrypty
Formularz, slider, popup z rabatem, czat, mapa, pixel Facebooka, dwa narzędzia analityczne i wtyczka do plików cookie. Każde z osobna waży niewiele. Razem tworzą kilkaset kilobajtów JavaScriptu, który przeglądarka musi pobrać, sparsować i wykonać, i to on najczęściej psuje INP. Zasada jest prosta: wtyczka, której nie potrafisz wskazać na stronie, powinna zniknąć.
Tani hosting i długi czas odpowiedzi serwera
Na współdzielonym hostingu za 80 zł rocznie Twoja strona dzieli procesor z setkami innych. Efekt widać w TTFB: zanim przeglądarka dostanie pierwszy bajt, mija sekunda albo dwie, i tego czasu nie odrobisz żadną optymalizacją grafiki, bo LCP startuje dopiero po odpowiedzi serwera. Pomaga cache po stronie serwera, aktualne PHP i hosting, na którym ktoś odbiera telefon.
Fonty i skrypty zewnętrzne blokujące renderowanie
Font pobierany z zewnętrznego serwera przy każdym wejściu, arkusz stylów ładowany przed wyświetleniem czegokolwiek, skrypt czatu wykonujący się w trakcie renderowania. Każdy z tych elementów wstrzymuje wyświetlenie treści. Font warto trzymać na własnym serwerze i dodać font-display: swap, żeby tekst pokazał się natychmiast, zanim font się dociągnie.
Co poprawisz sam, a do czego potrzebujesz programisty?
| Zadanie | Kto to zrobi | Poprawia |
|---|---|---|
| Zmniejszenie i konwersja zdjęć do WebP | samodzielnie, w panelu | LCP |
| Usunięcie nieużywanych wtyczek | samodzielnie, ostrożnie | INP, LCP |
| Włączenie cache po stronie serwera | samodzielnie lub hostingodawca | LCP |
| Przeniesienie na lepszy hosting | hostingodawca | LCP (TTFB) |
Wymiary width i height przy obrazach | osoba od strony | CLS |
| Rezerwacja miejsca na banery i osadzone elementy | osoba od strony | CLS |
| Krytyczny CSS i opóźnianie skryptów | programista | LCP, INP |
| Podział i ograniczenie JavaScriptu | programista | INP |
| Zejście z page buildera | przebudowa strony | wszystkie trzy |
Zacznij od góry tabeli i mierz po każdej zmianie. Najczęstszy błąd to instalowanie trzech wtyczek „przyspieszających” naraz, gdy coś się rozjedzie, nie wiadomo, która to zrobiła, a strona bywa wolniejsza niż przed operacją, bo wtyczki nadpisują sobie ustawienia.
Granica opłacalności naprawy przebiega mniej więcej tam, gdzie koszt kolejnych poprawek zbliża się do połowy kosztu zbudowania nowej strony, a efekt wciąż nie sięga progów. Przy stronie sprzed sześciu lat, na porzuconym szablonie, z builderem i dwudziestoma wtyczkami, ta granica bywa blisko.
Ile kosztuje doprowadzenie strony do zieleni?
| Zakres | Koszt (netto) | Kiedy wystarczy |
|---|---|---|
| Audyt wydajności z listą zadań | 800–2000 zł | gdy chcesz wiedzieć, co konkretnie boli |
| Pakiet szybkich poprawek (obrazy, cache, wtyczki) | 1000–3000 zł | strona zasadniczo zdrowa, wyniki na pograniczu |
| Pełna optymalizacja techniczna | 3000–8000 zł | czerwone wskaźniki, ale sensowny fundament |
| Nowa strona na lekkim motywie | od 2000 zł | page builder, stary szablon, wszystko na czerwono |
Warto zestawić to z budżetem na promocję. Jeśli wydajesz miesięcznie kilka tysięcy złotych na pozycjonowanie albo reklamy, a strona traci co trzeciego użytkownika w trakcie ładowania, jednorazowa naprawa zwraca się szybciej niż większość działań marketingowych. Kupujesz lepszy wynik w Google, a przy okazji wyższą skuteczność każdej złotówki wydanej na ściąganie ruchu.
Jak zbudowaliśmy tę stronę — nasze liczby?
Łatwo doradzać szybkość, trudniej pokazać własny wynik. Strona, którą właśnie czytasz, ma na urządzeniach mobilnych LCP 1,7 sekundy, CLS równe zero i waży 69 kilobajtów.
Złożyło się na to kilka decyzji podjętych na etapie projektu, nie doklejonych później:
- Autorski motyw zamiast page buildera: na stronę trafia tylko ten kod, który jest naprawdę używany.
- Około 3 kilobajtów JavaScriptu na całą witrynę, bez zewnętrznych bibliotek.
- Krytyczny CSS wpisany w kod strony, reszta arkusza ładowana po wyświetleniu treści.
- Font zmienny na własnym serwerze, tylko dwa zestawy znaków, bez zapytania do zewnętrznego dostawcy.
- Obrazy w WebP z podanymi wymiarami: stąd CLS równe zero, nic nie przeskakuje.
Nie jest to sztuka dla sztuki. Lekka strona lepiej znosi słaby zasięg, taniej się utrzymuje i nie wymaga trzech wtyczek do przyspieszania, które same trzeba aktualizować. Tak samo budujemy strony klientów.
Kiedy Core Web Vitals nie są Twoim problemem?
Zdarza się, że firma wydaje kilka tysięcy złotych na optymalizację wydajności i nie dostaje nic, bo problem leżał gdzie indziej. Trzy sytuacje, w których szybkość poczeka:
- Strona jest zielona, a ruchu nie ma. Wtedy brakuje treści odpowiadających na realne zapytania i linków, a nie milisekund. Szybkość niczego nie naprawi.
- Strona ma trzydzieści wizyt miesięcznie. Najpierw widoczność — wizytówka Google i frazy lokalne dadzą więcej niż skrócenie LCP o pół sekundy.
- Wynik jest w kategorii „wymaga poprawy”, a nie „słaby”. Różnica między 2,8 s a 2,4 s w LCP rzadko zmienia cokolwiek w sprzedaży. Różnica między 6 s a 2,4 s zmienia wszystko.
Uczciwa kolejność wygląda tak: najpierw strona ma odpowiadać na to, czego szukają klienci, potem ma być znaleziona, a na końcu ma być szybka. Z jednym wyjątkiem, jeśli wskaźniki są głęboko na czerwono, szybkość wskakuje na początek listy, bo wtedy psuje wszystkie pozostałe działania.
Podsumowanie — pięć rzeczy do zapamiętania
- Progi są twarde: LCP do 2,5 s, INP do 200 ms, CLS do 0,1, licząc dla 75% wizyt.
- Core Web Vitals to potwierdzony, ale słaby sygnał rankingowy — rozstrzyga remisy, nie wygrywa walki o frazę.
- Wpływ pośredni jest mocniejszy: ładowanie z 1 do 3 sekund to +32% porzuceń.
- Liczą się dane terenowe z ostatnich 28 dni, nie punktacja z testu laboratoryjnego.
- Najczęstsza przyczyna czerwonych wyników to page builder plus kilkanaście wtyczek, a nie brak wtyczki do cache’owania.
Nie wiesz, na czym stoi Twoja strona? Zamów bezpłatny audyt szybkości — sprawdzimy dane terenowe, wskażemy trzy rzeczy o największym wpływie i powiemy wprost, czy warto naprawiać, czy budować od nowa.
Najczęstsze pytania o Core Web Vitals
Czy Core Web Vitals są czynnikiem rankingowym w Google?
Tak. Google potwierdził, że wchodzą w skład sygnałów Page Experience branych pod uwagę przy ustalaniu pozycji. Waga tego sygnału jest jednak mała w porównaniu z dopasowaniem treści do zapytania i autorytetem domeny. W praktyce Core Web Vitals rozstrzygają, gdy dwie strony są pod innymi względami podobne.
Jakie wyniki Core Web Vitals uznaje się za dobre?
LCP do 2,5 sekundy, INP do 200 milisekund, CLS do 0,1. Wynik musi zostać osiągnięty dla co najmniej 75% wizyt, osobno na urządzeniach mobilnych i na komputerach. Wartości pomiędzy progiem dobrym a słabym Google oznacza jako „wymaga poprawy”.
Dlaczego wynik w PageSpeed Insights różni się od danych w Search Console?
Bo mierzą co innego. Punktacja 0–100 w PageSpeed Insights pochodzi z jednorazowego testu laboratoryjnego na symulowanym urządzeniu. Search Console pokazuje dane terenowe zebrane od realnych użytkowników Chrome z ostatnich 28 dni. Dla pozycji w Google liczą się wyłącznie dane terenowe.
Czy 100 punktów w PageSpeed Insights oznacza zielone Core Web Vitals?
Nie zawsze. Wysoka punktacja laboratoryjna oznacza dobrze zoptymalizowany kod, ale realni użytkownicy mogą mieć wolniejsze urządzenia, słabszy zasięg albo trafiać na przeciążony serwer. Zdarza się też odwrotnie: przeciętna punktacja i zielone dane terenowe.
Co to jest INP i dlaczego zastąpił FID?
INP mierzy czas od kliknięcia do widocznej reakcji strony i bierze pod uwagę wszystkie interakcje w trakcie wizyty, wskazując tę najgorszą. Zastąpił FID w marcu 2024 roku, ponieważ FID badał tylko opóźnienie pierwszej interakcji, przez co wiele stron miało dobry wynik mimo wyraźnych zacięć w dalszej części wizyty.
Jak często aktualizują się dane Core Web Vitals?
Dane obejmują ruchome okno 28 dni, więc efekt poprawek widać stopniowo przez cztery tygodnie od wdrożenia. Pierwsze zmiany w raporcie Search Console pojawiają się zwykle po kilkunastu dniach. Test laboratoryjny w PageSpeed Insights pokazuje nowy wynik od razu.
Czy Core Web Vitals mają znaczenie przy małej, lokalnej stronie?
Mają, choć nie jako priorytet numer jeden. Ruch lokalny jest niemal w całości mobilny i często odbywa się przy słabym zasięgu, więc wolna strona kosztuje tu realne telefony. Jeśli jednak strona ma kilkadziesiąt wizyt miesięcznie, najpierw warto zająć się widocznością, a dopiero potem milisekundami.
Czy wtyczka optymalizacyjna wystarczy, żeby przejść Core Web Vitals?
Czasem tak, przy zdrowej stronie z wynikami na pograniczu progów. Wtyczka włączy cache, zminifikuje pliki i opóźni część skryptów. Nie usunie jednak nadmiarowego kodu page buildera ani ciężkich zdjęć, a to najczęstsze przyczyny czerwonych wyników. Instalowanie kilku wtyczek naraz zwykle pogarsza sprawę.
Czy szybkość strony wpływa na koszt reklam w Google Ads?
Tak. Jakość strony docelowej jest jednym ze składników Wyniku Jakości, a szybkość ładowania wchodzi w jej skład. Niższy Wynik Jakości oznacza wyższą stawkę za kliknięcie przy tej samej pozycji reklamy. Wolna strona podnosi więc rachunek za reklamę niezależnie od wyników organicznych.
Ile kosztuje poprawa Core Web Vitals?
Audyt wydajności z listą zadań to 800–2000 zł netto, pakiet szybkich poprawek 1000–3000 zł, pełna optymalizacja techniczna 3000–8000 zł. Gdy strona stoi na page builderze i wszystko świeci na czerwono, nowa strona na lekkim motywie (od 2000 zł netto) bywa tańsza niż łatanie starej.
Czy da się poprawić Core Web Vitals bez wiedzy technicznej?
Częściowo tak. Samodzielnie zmniejszysz i przekonwertujesz zdjęcia, usuniesz nieużywane wtyczki i włączysz cache, to zwykle daje największy efekt przy najmniejszym ryzyku. Krytyczny CSS, podział JavaScriptu i rezerwacja miejsca dla elementów wymagają już wejścia w kod motywu.
Czy Core Web Vitals wpływają na widoczność w AI Overviews i ChatGPT?
Pośrednio. Modele nie mierzą LCP ani CLS, ale muszą pobrać i przetworzyć treść strony. Witryna, która długo odpowiada albo buduje treść dopiero JavaScriptem w przeglądarce, bywa dla nich pusta. Szybki, dostępny od razu HTML jest warunkiem tego, żeby w ogóle dało się Cię zacytować.
