Core Web Vitals to zestaw trzech metryk, które Google używa do mierzenia doświadczenia użytkownika na stronie. Od 2021 roku są oficjalnym sygnałem rankingowym — strony z dobrymi Core Web Vitals mają przewagę w wynikach wyszukiwania nad stronami z złymi wynikami (przy porównywalnej jakości treści).
Trzy metryki to: LCP (szybkość ładowania), INP (responsywność na interakcje) i CLS (stabilność wizualna). W tym poradniku wyjaśniam co każda z nich mierzy, jakie są progi Google, jak je sprawdzić i — najważniejsze — jak je poprawić.
Trzy metryki Core Web Vitals
| Metryka | Co mierzy | Dobry | Wymaga poprawy | Słaby |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Czas załadowania największego elementu widocznego | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP (Interaction to Next Paint) | Czas reakcji na interakcję użytkownika | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Stabilność wizualna (ile elementów „skacze”) | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Google ocenia CWV na podstawie danych terenowych (Field Data) — rzeczywistych pomiarów od prawdziwych użytkowników Chrome (raport CrUX). Nie na podstawie pojedynczego testu laboratoryjnego — ale statystyk z 28 dni od realnych odwiedzin. To oznacza: musisz poprawić doświadczenie 75% użytkowników (p75), żeby wynik był „dobry”.
LCP — Largest Contentful Paint (szybkość ładowania)
Co to mierzy
LCP mierzy czas, w którym największy element widoczny na ekranie (above the fold) zostaje w pełni załadowany. Najczęściej to:
- Hero image — duże zdjęcie na górze strony
- Blok tekstu — nagłówek H1 + pierwszy paragraf (jeśli brak dużego obrazka)
- Wideo poster — miniatura wideo
- Background image w CSS
Cel: ≤ 2,5 sekundy. Użytkownik powinien zobaczyć główną treść w 2,5 sekundy od kliknięcia w link.
Jak poprawić LCP
- Obniż TTFB — serwer musi odpowiedzieć szybko. Page cache (LiteSpeed, WP Rocket), CDN, Redis, szybszy hosting.
- Zoptymalizuj obrazek LCP — kompresja, WebP/AVIF, prawidłowy rozmiar (nie 4000px na slot 800px). Dodaj atrybut
fetchpriority="high"do obrazka hero. - Nie lazy-loaduj obrazka LCP — lazy loading opóźnia ładowanie. Obrazek hero powinien mieć
loading="eager"(lub brak atrybutu loading — eager jest domyślne). - Usuń render-blocking CSS/JS — krytyczny CSS inline w <head>, reszta defer/async. Minifikacja + concat.
- Preload ważnych zasobów —
<link rel="preload" as="image" href="hero.webp">w <head>. Przeglądarka zaczyna pobierać obrazek natychmiast. - Używaj
<img>zamiast CSSbackground-imagedla elementu LCP — przeglądarka wcześniej odkrywa<img>w HTML niż background w CSS.
INP — Interaction to Next Paint (responsywność)
Co to mierzy
INP mierzy czas od kliknięcia/tapnięcia przez użytkownika do momentu, gdy przeglądarka pokaże wizualną odpowiedź. Np. klikasz przycisk „Dodaj do koszyka” → ile czasu mija zanim zobaczysz jakąkolwiek zmianę na ekranie (animacja, zmiana tekstu, potwierdzenie).
INP zastąpił FID (First Input Delay) w marcu 2024. Różnica: FID mierzył tylko pierwsze kliknięcie. INP mierzy wszystkie interakcje i bierze najgorszą (p75). To trudniejsza metryka.
Cel: ≤ 200 ms. Strona powinna reagować na kliknięcia w mniej niż 200 milisekund.
Jak poprawić INP
- Zmniejsz JavaScript — każdy JS blokuje main thread. Mniej kodu = szybsza reakcja. Audyt: PageSpeed Insights → „Reduce JavaScript execution time”.
- Rozbij długie zadania (Long Tasks) — zadania JS dłuższe niż 50 ms blokują interakcje. Rozbij na mniejsze chunki z
setTimeout(),requestIdleCallback()lubscheduler.yield(). - Defer/async niepotrzebny JS — ładuj trzecie-stronne skrypty (analytics, chat, reklamy) po załadowaniu strony:
<script defer>lub dynamicznie poDOMContentLoaded. - Unikaj dużych re-renderów DOM — kliknięcie, które wymusza przebudowanie 5000 elementów DOM, będzie wolne. Minimalizuj DOM (max 1500 elementów), unikaj layout thrashing.
- Ogranicz wtyczki WordPress z ciężkim JS — Elementor, Slider Revolution, czat-boty, pop-up tools dodają setki KB JavaScript. Usuń zbędne lub zastąp lekkimi alternatywami.
- Web Workers — przenieś ciężkie obliczenia do Web Worker (osobny thread), żeby nie blokować main thread.
CLS — Cumulative Layout Shift (stabilność wizualna)
Co to mierzy
CLS mierzy ile elementów na stronie „skacze” (przesuwa się) podczas ładowania. Znasz ten problem: czytasz artykuł, nagle ładuje się reklama i tekst przesuwa się o 300 pikseli w dół. Albo klikasz przycisk, ale w ostatniej chwili ładuje się obrazek i klikasz coś innego. To jest layout shift — i CLS go mierzy.
Cel: ≤ 0,1. Im niższy CLS, tym stabilniejsza strona wizualnie.
Jak poprawić CLS
- Podaj wymiary obrazkom — zawsze dodawaj
widthiheightdo tagów<img>(lub CSSaspect-ratio). Przeglądarka rezerwuje miejsce zanim pobierze obrazek = brak skoku. - Podaj wymiary ramkom embed/iframe — wideo YouTube, mapy Google, widgety — zawsze z
width/heightlubaspect-ratio: 16/9. - Nie wstawiaj treści dynamicznej „nad” istniejącą — bannery cookies, powiadomienia, reklamy powinny mieć zarezerwowane miejsce lub pojawiać się poniżej fold (nie przesuwając tekstu).
- Używaj
font-display: swapdla custom fontów — zamiast niewidocznego tekstu (FOIT) podczas ładowania fontu, wyświetl tekst w fallback foncie i zamień po załadowaniu (mały shift, ale lepszy niż brak tekstu). - Unikaj dynamicznego wstawiania reklam bez zarezerwowanego slotu — Google Ads (AdSense): ustaw minimalne wymiary kontenera (
min-height) zanim reklama się załaduje. - Animacje — używaj
transformzamiast zmianytop/left/width/height. Transformacje nie powodują layout shift.
Jak mierzyć Core Web Vitals
Dane terenowe (Field Data) — to, co Google NAPRAWDĘ używa
- PageSpeed Insights (pagespeed.web.dev) — na górze: „Discover what your real users are experiencing” = dane terenowe z CrUX. To jest oficjalny wynik Google.
- Google Search Console → „Core Web Vitals” (raport) — pokazuje ile stron ma dobry/wymaga poprawy/słaby CWV. Najlepsza przeglądowa diagnoza.
- CrUX Dashboard (datastudio) — wizualizacja historycznych danych CWV (trendy w czasie).
Dane laboratoryjne (Lab Data) — do diagnozy problemów
- PageSpeed Insights — dolna sekcja „Diagnose performance issues” = dane laboratoryjne (symulacja). Dają sugestie co naprawić.
- Chrome DevTools → Performance — nagraj sesję, zobacz timeline z LCP, layout shifts, long tasks. Najbardziej szczegółowe.
- Chrome DevTools → Lighthouse — F12 → Lighthouse → „Performance” → Run audit. Symulacja mobilna z wynikami CWV.
- Web Vitals Extension (Chrome) — wyświetla LCP/INP/CLS w czasie rzeczywistym na każdej stronie.
Core Web Vitals a ranking w Google — ile to wpływa?
Core Web Vitals to jeden z wielu sygnałów rankingowych — nie jedyny i nie dominujący. Google oficjalnie mówi: „treść jest ważniejsza niż CWV”. Strona ze świetną treścią i słabymi CWV może nadal rankować wyżej niż strona z doskonałymi CWV i słabą treścią.
Ale: przy porównywalnej jakości treści, CWV to tiebreaker. Dwie strony o identycznej treści, linkach i autorytecie — ta z lepszymi CWV wygra. Dlatego CWV warto optymalizować — to darmowa przewaga konkurencyjna.
Dodatkowo: Google wyświetla badge „Page experience” w mobilnych SERP (zielona ikonka) dla stron z dobrymi CWV — co zwiększa CTR.
CWV w WordPress — typowe problemy i rozwiązania
LCP za wysoki (> 2,5 s)
Najczęstsze przyczyny na WordPress: brak page cache, niezoptymalizowane obrazki, wolny hosting, render-blocking CSS/JS od motywu/wtyczek. Rozwiązanie: LiteSpeed Cache + ShortPixel WebP + optymalizacja TTFB.
INP za wysoki (> 200 ms)
Najczęstsze przyczyny: Elementor (ładuje 300+ KB JS), ciężkie slidery (Slider Revolution), czat-boty (Tidio, LiveChat), pop-up wtyczki (OptinMonster, Popup Maker), Google reCAPTCHA. Rozwiązanie: defer skryptów, usunięcie zbędnych wtyczek, lazy load dla czat-bota (załaduj dopiero po scroll/klik).
CLS za wysoki (> 0,1)
Najczęstsze przyczyny: obrazki bez wymiarów, reklamy AdSense bez zarezerwowanego slotu, custom fonty bez font-display, lazy loading obrazków above the fold (pojawiają się z opóźnieniem = shift). Rozwiązanie: width/height na każdym <img>, min-height na kontenerach reklam, font-display: swap w @font-face.
Najczęściej zadawane pytania
Jak szybko Google zauważy poprawę CWV?
Dane CrUX (Field Data) zbierają się przez 28 dni. Po naprawie: musisz poczekać ~4 tygodnie, aż nowe dane zastąpią stare. PageSpeed Insights pokaże poprawę po tym czasie. Search Console: raport aktualizuje się co kilka dni, ale pełna zmiana widoczna po ~28 dniach.
Czy CWV mierzy mobile czy desktop?
Google używa danych mobilnych do rankingu (Mobile-First Indexing). PageSpeed Insights pokazuje oba (przełącznik Mobile/Desktop), ale dla SEO liczy się mobile. Optymalizuj pod mobile w pierwszej kolejności.
Co jeśli moja strona nie ma danych terenowych (Field Data)?
Nowe strony (mało ruchu) nie mają wystarczających danych w CrUX. PageSpeed Insights pokaże wtedy: „Field data not available” i tylko dane laboratoryjne. Google w takim przypadku nie używa CWV jako sygnału (bo nie ma danych). Dane pojawiają się, gdy strona ma wystarczający ruch w Chrome (~kilka tysięcy odwiedzin/mc).
Czy wtyczka „Performance” naprawi CWV?
Nie ma jednej wtyczki, która „naprawi wszystko”. Ale kombinacja: cache plugin (LiteSpeed/WP Rocket) + image optimizer (ShortPixel) + asset optimizer (Autoptimize lub wbudowane opcje cache plugina) rozwiązuje 80% problemów CWV na WordPress. Reszta to audyt konkretnych wtyczek (które ładują ciężki JS) i optymalizacja motywu.
FID vs INP — co się zmieniło?
FID (First Input Delay) mierzył opóźnienie TYLKO pierwszej interakcji. Był łatwy do „oszukania” (strona reagowała szybko na pierwsze kliknięcie, ale potem była wolna). INP (Interaction to Next Paint) mierzy WSZYSTKIE interakcje i bierze najgorszą (p75). Jest trudniejszy do poprawienia, ale lepiej oddaje rzeczywiste doświadczenie użytkownika. FID został zastąpiony INP jako Core Web Vital w marcu 2024.
Podsumowanie
Core Web Vitals = trzy metryki doświadczenia użytkownika, które Google używa jako sygnał rankingowy: LCP ≤ 2,5 s (szybkość), INP ≤ 200 ms (responsywność), CLS ≤ 0,1 (stabilność). Mierzysz: PageSpeed Insights (dane terenowe = oficjalne), Google Search Console (raport zbiorczy). Naprawiasz: cache + CDN + optymalizacja obrazków (LCP), mniej/defer JS (INP), wymiary na obrazkach/iframach (CLS). CWV nie zastąpi dobrej treści — ale przy równej jakości treści, daje przewagę w rankingu.
