Core Web Vitals — dlaczego Google karze wolne strony i jak to naprawić

Core Web Vitals to zestaw trzech wskaźników Google, które mierzą realne doświadczenie użytkownika na stronie: jak szybko strona się ładuje (LCP), jak szybko reaguje na kliknięcia (INP) i jak stabilny jest jej układ (CLS). To nie laboratoryjny gadżet dla programistów, tylko oficjalny czynnik rankingowy — przy podobnej jakości treści szybsza strona wygrywa pozycję w Google z wolniejszą. W tym przewodniku tłumaczymy każdy wskaźnik po ludzku, podajemy progi obowiązujące w 2026, pokazujemy, co dokładnie je psuje i jak krok po kroku przyspieszyć stronę, żeby przeszła testy Google i lepiej konwertowała.

Czym są Core Web Vitals (po ludzku)

Core Web Vitals to trzy metryki, którymi Google standaryzuje pojęcie „dobrej strony" z punktu widzenia użytkownika. Co ważne — nie mierzą po prostu „czasu ładowania w sekundach", tylko to, jak człowiek realnie odbiera szybkość i płynność: czy treść pojawia się szybko, czy strona od razu reaguje na dotyk i czy nic nie „skacze" pod palcem. Google zbiera te dane od prawdziwych użytkowników Chrome (raport CrUX), więc to nie teoria z laboratorium, lecz to, czego doświadczają Twoi klienci.

Trzy wskaźniki to: LCP (jak szybko widać główną treść), INP (jak szybko strona reaguje na kliknięcia) i CLS (czy układ jest stabilny). Razem tworzą obraz „page experience", który Google bierze pod uwagę przy układaniu wyników.

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

LCP mierzy, po jakim czasie pojawia się największy widoczny element w oknie przeglądarki — zwykle zdjęcie nagłówkowe, baner albo duży blok tekstu. To moment, w którym użytkownik czuje, że „strona się załadowała". Cel: poniżej 2,5 sekundy.

Typowy zabójca LCP to ciężkie zdjęcie: nagłówek ważący 2,5 MB w formacie JPG zamiast 250 KB w WebP albo AVIF to gotowy LCP powyżej 4 sekund. Do tego dochodzi wolny hosting, brak cache i blokujące zasoby (skrypty, czcionki) ładowane przed treścią.

INP — Interaction to Next Paint (responsywność)

INP to najnowszy z trzech wskaźników — w 2024 roku zastąpił dawny FID. Mierzy opóźnienie między działaniem użytkownika (kliknięcie, dotknięcie, wpisanie) a wizualną reakcją strony, i to w całej sesji, a nie tylko przy pierwszej interakcji. Mówiąc prościej: jak szybko strona „odpowiada", gdy w nią klikniesz. Cel: poniżej 200 ms.

INP to obecnie najczęściej niespełniany wskaźnik — szacuje się, że 43% stron nie przechodzi progu 200 ms. Powód jest niemal zawsze ten sam: zablokowany główny wątek przeglądarki przez zbyt ciężki JavaScript — rozbudowane buildery, nadmiar wtyczek, czaty, narzędzia analityczne i zewnętrzne skrypty pracujące w tle.

CLS — Cumulative Layout Shift (stabilność układu)

CLS ocenia, jak bardzo elementy „skaczą" podczas ładowania. Znasz to uczucie, gdy chcesz kliknąć przycisk, a w ostatniej chwili doładowuje się reklama albo baner i klikasz coś innego? To właśnie wysoki CLS. Cel: poniżej 0,1 (im bliżej zera, tym lepiej).

Najczęstsze przyczyny: obrazy i iframe bez zadeklarowanej szerokości i wysokości, czcionki podmieniające się po załadowaniu, treści wstrzykiwane dynamicznie (reklamy, bannery cookie) bez zarezerwowanego miejsca.

Progi 2026 — tabela wartości

Google dzieli wyniki na trzy strefy. Aby zaliczyć test, strona musi mieścić się w zielonej strefie dla 75% rzeczywistych użytkowników:

Czy Google naprawdę „karze" wolne strony?

Formalnie Google nie nakłada osobnej „kary" za wolną stronę — to nie filtr jak za spam. Ale efekt bywa podobny, i to z dwóch powodów.

Po pierwsze, Core Web Vitals to potwierdzony czynnik rankingowy w ramach „page experience". Gdy dwie strony mają porównywalnie dobrą treść, szybsza i stabilniejsza dostaje przewagę. Przy konkurencyjnych frazach ta przewaga decyduje o tym, czy jesteś w TOP 3, czy na drugiej stronie wyników.

Po drugie — i ważniejsze biznesowo — wolna strona traci ludzi. Użytkownicy uciekają, zanim treść się załaduje, co podnosi współczynnik odrzuceń i obniża konwersję. Badania pokazują, że strony spełniające wszystkie trzy progi notują nawet 24% niższy współczynnik rezygnacji. Google widzi, że użytkownicy szybko wracają do wyników (tzw. pogo-sticking), i to pośrednio obniża pozycję. Innymi słowy: wolna strona karze się sama, a Google tylko to wzmacnia.

Jak zmierzyć Core Web Vitals

PageSpeed Insights

Darmowe narzędzie Google: wklejasz adres URL i dostajesz wyniki LCP, INP i CLS — osobno dla wersji mobilnej i desktopowej. Na górze widzisz dane polowe (od realnych użytkowników), niżej diagnostykę laboratoryjną z konkretną listą „co poprawić". To pierwsze miejsce, do którego warto zajrzeć.

Raport Core Web Vitals w Search Console

Pokazuje całą witrynę naraz: ile adresów jest „dobrych", ile „wymaga poprawy", a ile „słabych", pogrupowanych według problemu. Idealne do priorytetyzacji — widzisz, które typy podstron ciągną wynik w dół.

Lighthouse / DevTools

Wbudowane w Chrome — przydatne do szybkiego testu w trakcie pracy, ale pamiętaj: to dane laboratoryjne, a ranking opiera się na danych polowych.

Jak poprawić LCP — krok po kroku

• Optymalizuj obrazy — zamień JPG/PNG na WebP lub AVIF i kompresuj. To zwykle największy pojedynczy skok.
• Wymiaruj i ładuj priorytetowo obraz LCP (np. atrybut fetchpriority="high"), a resztę odłóż na loading="lazy".
• Włącz cache serwerowy i przeglądarki (np. LiteSpeed Cache, WP Rocket na WordPress).
• Użyj CDN, żeby pliki ładowały się z serwera blisko użytkownika.
• Dobry hosting — tani, przeciążony serwer to wysoki czas odpowiedzi (TTFB) i automatycznie gorszy LCP.
• Ogranicz blokujące zasoby — minifikuj CSS/JS, usuń nieużywany kod, ładuj czcionki z font-display: swap.

Jak poprawić INP — krok po kroku

INP to przede wszystkim walka z nadmiarem JavaScriptu blokującego główny wątek:

• Ogranicz wtyczki i skrypty zewnętrzne — każdy czat, popup, widżet i piksel kosztuje responsywność.
• Odraczaj i dziel JavaScript (defer, code splitting), żeby nie ładował się cały naraz.
• Ładuj ciężkie skrypty leniwie — np. czat dopiero po interakcji użytkownika.
• Ogranicz animacje i ciężkie efekty, które obciążają wątek przy każdej akcji.
• Wybieraj lekki motyw zamiast rozdmuchanego buildera generującego tony kodu.

Jak poprawić CLS — krok po kroku

• Deklaruj wymiary — każdy <img>, wideo i iframe z jawną szerokością i wysokością (lub aspect-ratio).
• Rezerwuj miejsce na elementy doładowywane: reklamy, banery cookie, treści dynamiczne.
• Używaj font-display: swap i preload czcionek, żeby uniknąć przeskoku tekstu.
• Nie wstawiaj treści nad widoczną zawartością po załadowaniu (np. banery przesuwające układ).

WordPress, wtyczki i hosting

Większość polskich firm działa na WordPressie i to tam najczęściej rodzą się problemy z Core Web Vitals. Nie dlatego, że WordPress jest wolny — tylko dlatego, że łatwo go „obrosnąć" wtyczkami i ciężkim builderem.

Jeśli zastanawiasz się nad samą platformą sklepu pod kątem wydajności, porównaliśmy opcje we wpisie WooCommerce vs Shopify. A jeśli planujesz budżet na szybką, dobrze zoptymalizowaną stronę, sprawdź ile kosztuje strona internetowa w 2026 oraz nasz przejrzysty cennik.

Najczęstsze błędy przy optymalizacji

• Optymalizacja „na lab" — gonienie wyniku 100/100 w Lighthouse, gdy liczą się dane polowe od realnych użytkowników.
• Ignorowanie mobile — większość ruchu jest z telefonów, a to tam wyniki są najgorsze.
• Instalowanie kolejnych wtyczek „przyspieszających" — czasem dokładają więcej kodu, niż usuwają.
• Poprawiam i sprawdzam od razu — dane CrUX aktualizują się w oknie 28 dni; poczekaj 3–4 tygodnie na realny obraz.
• Skupianie się na jednym wskaźniku — trzeba zaliczyć wszystkie trzy naraz.

Jak robimy to u nas

Strony i sklepy budujemy z myślą o Core Web Vitals od pierwszego dnia, a nie jako poprawkę na końcu. Lekki kod, obrazy w WebP/AVIF, cache, sensowny hosting i minimum zbędnych skryptów to u nas standard — nie płatny dodatek. Efekt: strony, które ładują się szybko, dobrze konwertują i nie tracą pozycji przez wydajność. Wszystko w ramach do 6 miesięcy — szybko, dobrze i taniej niż konkurencja.

Szybkość to nie dodatek, tylko element projektu — zobacz, co wchodzi w standard naszej profesjonalnej strony www, zanim zaczniesz optymalizować gotową witrynę.

FAQ — najczęstsze pytania o Core Web Vitals