Core Web Vitals - kompletny przewodnik po metrykach wydajności Google (2026)

Czym są Core Web Vitals

Core Web Vitals (CWV) to zestaw trzech metryk, którymi Google mierzy doświadczenie użytkownika na stronie. Nie chodzi o abstrakcyjną “szybkość”, tylko o trzy konkretne rzeczy: jak szybko użytkownik widzi główną treść, jak szybko strona reaguje na kliknięcie i czy elementy nie przeskakują podczas ładowania.

Krótka historia. W 2018 roku Google próbował mierzyć wydajność przez PageSpeed Score, ale to była metryka syntetyczna, oderwana od doświadczenia użytkownika. W maju 2020 Google ogłosił inicjatywę Web Vitals z trzema metrykami: LCP, FID i CLS. W czerwcu 2021 CWV oficjalnie stały się sygnałem rankingowym w ramach aktualizacji Page Experience. W marcu 2024 FID (First Input Delay) został zastąpiony przez INP (Interaction to Next Paint), bo FID mierzył tylko pierwsze kliknięcie użytkownika i ignorował resztę sesji. INP mierzy reakcję na wszystkie interakcje w trakcie wizyty, co znacznie lepiej oddaje rzeczywistość korzystania ze strony.

Stan na 2026: trzy metryki to LCP, INP i CLS. Na horyzoncie pojawiają się eksperymentalne metryki: Visual Stability Index (mierzy stabilność layoutu w całej sesji, nie tylko podczas ładowania) i Engagement Reliability (spójność interakcji bez frustrujących przeszkód). Nie wchodzą jeszcze w skład CWV, ale warto je obserwować, bo Google jasno sygnalizuje kierunek rozwoju.

Trzy metryki i ich progi

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

LCP mierzy czas renderowania największego widocznego elementu strony. W sklepie internetowym to zwykle zdjęcie hero na stronie głównej lub główne zdjęcie produktu.

Najczęstsze przyczyny złego LCP w e-commerce: nieskompresowane zdjęcia produktów (2-5 MB per plik), wolny TTFB z powodu taniego hostingu współdzielonego, render-blocking CSS i JavaScript z wtyczek, kaskadowe ładowanie zasobów (HTML > CSS > obraz tła).

Więcej szczegółów w osobnym artykule: LCP - co to jest i jak poprawić.

INP (Interaction to Next Paint) - responsywność

INP mierzy czas od interakcji użytkownika (kliknięcie, dotknięcie, naciśnięcie klawisza) do momentu, gdy przeglądarka wyrenderuje odpowiedź wizualną. Bierze pod uwagę wszystkie interakcje w trakcie wizyty i raportuje wartość bliską najgorszemu wynikowi (percentyl 98.).

W sklepach internetowych problemem są: ciężkie skrypty third-party (czaty, narzędzia remarketingowe, piksele konwersji), event handlery blokujące main thread, dynamiczne renderowanie filtrów bez debounce’a. Typowy scenariusz: klient klika “dodaj do koszyka” i nic nie dzieje się przez 400 ms, bo przeglądarka przetwarza skrypt analytics.

CLS (Cumulative Layout Shift) - stabilność wizualna

CLS mierzy, jak bardzo elementy strony przeskakują podczas ładowania i interakcji. Wartość 0 oznacza brak przesunięć. Każde przesunięcie elementu daje wynik proporcjonalny do rozmiaru elementu i dystansu przesunięcia.

Typowe przyczyny w e-commerce: obrazy bez zadeklarowanych wymiarów (width/height), dynamicznie ładowane bannery reklamowe wpychające treść w dół, niestabilne embedy (mapy, widgety opinii, porównywarki cen), webfonty powodujące FOUT (Flash of Unstyled Text) i lazy-loaded elementy bez placeholderów rezerwujących miejsce w layoucie.

CLS to metryka, która szczególnie irytuje użytkowników mobilnych. Klasyczny scenariusz: klient próbuje kliknąć przycisk “kup teraz”, a w tym momencie ładuje się banner i przycisk przesuwa się o 200 pikseli w dół. Klient klika w banner zamiast w przycisk. Frustracja gwarantowana.

Lab data vs field data

To kluczowe rozróżnienie, które wielu właścicieli sklepów myli.

Lab data (dane laboratoryjne) to wyniki z Lighthouse, PageSpeed Insights w trybie symulacji, Chrome DevTools. Test wykonuje się w kontrolowanych warunkach: stałe łącze, stały procesor, ta sama lokalizacja. Wyniki są powtarzalne i przydatne do debugowania, bo możesz uruchomić test, zmienić coś, uruchomić ponownie i porównać. Ale Google ich nie używa do rankingu.

Field data (dane terenowe) to pomiary od prawdziwych użytkowników, zbierane przez przeglądarkę Chrome i agregowane w Chrome User Experience Report (CrUX). Google bierze pod uwagę percentyl 75. - czyli wynik, który osiąga lub przekracza 75% wizyt. To te dane decydują o ocenie CWV w kontekście rankingu. Dane zbierane są w oknie 28-dniowym, więc odzwierciedlają długoterminową wydajność, nie jednorazowy test.

Praktyczna implikacja: możesz mieć Lighthouse score 95 i nadal nie zdawać CWV w danych terenowych, bo Twoi użytkownicy wchodzą na stronę z wolnych połączeń mobilnych w Polsce. Widzimy to regularnie w audytach: klient chwali się wynikiem PageSpeed, ale w GSC cała witryna świeci na czerwono. Dlatego zawsze sprawdzaj sekcję “field data”, a nie “lab data”.

Narzędzia do pomiaru

Google Search Console

Raport Core Web Vitals w GSC pokazuje status wszystkich URL-i Twojej witryny w podziale na mobile i desktop. Grupuje strony według wzorców URL i wskazuje, które metryki wymagają poprawy. Dane oparte na CrUX (field data). Punkt wyjścia do diagnostyki.

PageSpeed Insights

Łączy lab data (Lighthouse) z field data (CrUX) na jednym ekranie. Wpisujesz URL, dostajesz oba zestawy danych plus konkretne rekomendacje. Sekcja “Ocena korzystania ze stron w rzeczywistości” to dane terenowe, “Diagnostyka” to dane laboratoryjne.

CrUX Vis

Nowy zamiennik starego CrUX Dashboard (Looker Studio), który Google wycofał w listopadzie 2025 z powodu problemów ze skalowaniem i częstych awarii. CrUX Vis to lekkie narzędzie do wizualizacji danych CrUX per origin lub per URL. Pokazuje trendy historyczne, rozkład wyników w trzech progach i pozwala porównywać wydajność między stronami. Jeśli natkniesz się na poradnik linkujący do starego dashboardu Looker Studio - ten już nie działa. CrUX Vis jest teraz jedynym oficjalnym narzędziem do wizualizacji danych CrUX bez pisania SQL.

CrUX History API

Zwraca 25 tygodni historii metryk dla danego URL-a lub originu. Przydatne do monitorowania trendów po wdrożeniu optymalizacji. Darmowe, wymaga klucza API z Google Cloud Console.

CrUX via BigQuery

Dla tych, którzy potrzebują surowych danych. Dataset chrome-ux-report w Google BigQuery zawiera dane od 2017 roku. Free tier pokrywa większość zapytań, powyżej tego ~5 USD/TB.

Przykładowe zapytanie SQL, które porównuje LCP Twojej domeny z medianą w Polsce:

SELECT
  origin,
  p75_lcp,
  p75_inp,
  p75_cls
FROM (
  SELECT
    origin,
    MAX(IF(metric = 'largest_contentful_paint',
      p75, NULL)) AS p75_lcp,
    MAX(IF(metric = 'interaction_to_next_paint',
      p75, NULL)) AS p75_inp,
    MAX(IF(metric = 'cumulative_layout_shift',
      ROUND(p75, 3), NULL)) AS p75_cls
  FROM
    `chrome-ux-report.country_pl.202602`
  CROSS JOIN
    UNNEST(metrics) AS metric_record,
    UNNEST([metric_record.name]) AS metric,
    UNNEST([metric_record.percentiles.p75]) AS p75
  WHERE
    origin = 'https://twojadomena.pl'
  GROUP BY origin
)

web-vitals.js

Biblioteka JavaScript od Google, którą instalujesz na swojej stronie. Mierzy CWV w czasie rzeczywistym i wysyła dane do Twojego systemu analytics. Waga: ~2 kB gzip. Daje pełną kontrolę nad danymi, bez ograniczeń CrUX (np. minimum 1000 wizyt/28 dni).

Chrome DevTools

Panel Performance w DevTools pokazuje dokładnie, co dzieje się na stronie milisekunda po milisekundzie. Przydatny do identyfikacji konkretnych problemów (który skrypt blokuje main thread, co powoduje layout shift). Dane laboratoryjne, ale z najwyższą granularnością.

Wpływ na ranking

Dużo szumu, mało konkretu. Fakty:

CWV to jeden z wielu sygnałów w ramach Page Experience. Google oficjalnie mówi, że treść jest ważniejsza. CWV działają bardziej jako tie-breaker: jeśli dwie strony mają podobną treść i autorytet, wygra ta z lepszymi CWV.

Ale to nie znaczy, że można temat ignorować. Wpływ na konwersję jest realny i mierzalny niezależnie od Google:

• Vodafone poprawił LCP o 31% i zanotował wzrost sprzedaży o 8%
• Amazon od lat cytuje regułę: +100 ms opóźnienia = -1% sprzedaży
• Badania Deloitte: 0,1 s poprawa szybkości = +8,4% konwersji w retail

Nawet jeśli CWV bezpośrednio nie przesuną Cię o 10 pozycji, to poprawa wydajności przełoży się na konwersję. A to z kolei uzasadnia budżet na optymalizację lepiej niż jakikolwiek argument o rankingu.

Matematyka jest prosta. Jeśli sklep robi 500 tys. zł miesięcznie i poprawa LCP daje choćby 3% wzrost konwersji, to 15 tys. zł miesięcznie więcej. Koszt optymalizacji CWV zwraca się w ciągu tygodni, nie miesięcy.

Jak poprawić Core Web Vitals

Poprawa LCP

1. Kompresja i format obrazów. Konwersja do WebP/AVIF, atrybuty width i height, srcset dla responsywnych rozmiarów. W większości platform e-commerce da się to zautomatyzować.
2. Preload kluczowego obrazu. Tag <link rel="preload"> w head dla obrazu hero, żeby przeglądarka nie czekała na parsowanie CSS.
3. Poprawa TTFB. Szybszy hosting, cache na poziomie serwera (Redis, Varnish), CDN dla statycznych zasobów.
4. Eliminacja render-blocking resources. Krytyczny CSS inline, reszta asynchronicznie. Defer dla JavaScriptu, który nie jest potrzebny do pierwszego renderowania.

Poprawa INP

1. Audyt skryptów third-party. Każdy piksel, czat i widget to potencjalny blokujący main thread. Mierz wpływ każdego z osobna.
2. Rozbijanie długich tasków. Używaj requestIdleCallback lub scheduler.yield() do dzielenia ciężkich operacji na mniejsze kawałki.
3. Debounce event handlerów. Filtry produktów, wyszukiwarka live, nieskończone przewijanie - wszystko to powinno mieć debounce.
4. Web Workers. Przenieś ciężkie obliczenia (sortowanie, filtrowanie) poza main thread.

Poprawa CLS

1. Wymiary dla obrazów i video. Zawsze deklaruj width i height lub używaj CSS aspect-ratio.
2. Rezerwacja miejsca na reklamy i embedy. Kontener o stałych wymiarach, zanim treść dynamiczna się załaduje.
3. Font-display: swap z preloadem. Preloaduj webfonty i ustaw font-display: swap, żeby tekst nie migał.
4. Unikaj dynamicznego wstawiania treści powyżej viewportu. Bannery cookies, komunikaty o darmowej dostawie - wstawiaj je jako overlay lub na dole.

Uwagi per platforma

Każda platforma e-commerce ma swoje specyficzne problemy i rozwiązania:

• WooCommerce/WordPress - rozbudowane ekosystemy wtyczek to główny problem. WP Rocket lub LiteSpeed Cache rozwiązują większość problemów z LCP i CLS. Przy INP kluczowe jest ograniczenie liczby wtyczek ładujących JS na frontendzie.
• Shopify - ograniczony dostęp do serwera, nie zmienisz TTFB. Za to Shopify automatycznie konwertuje obrazy do WebP. Problem: motywy z ciężkim JavaScriptem i aplikacje third-party demolujące INP.
• Magento/Adobe Commerce - najcięższy stack, ale i największe możliwości optymalizacji. Motyw Hyva (oparty na Alpine.js zamiast RequireJS) potrafi zredukować LCP o 50-70%.
• PrestaShop - często problem z CLS przez moduły ładujące bannery bez wymiarów. Cache: moduły PageCache lub Varnish na poziomie serwera.
• IdoSell - platforma SaaS z ograniczeniami analogicznymi do Shopify. CDN i kompresja obrazów obsługiwana centralnie, ale motywy bywają ciężkie.
• Shoper - automatyczna kompresja obrazów i CDN, ale ograniczone możliwości optymalizacji kodu motywu. Problemy z CLS przy dynamicznych sekcjach strony głównej.

Najczęściej zadawane pytania

Czy Core Web Vitals wpływają na pozycję w Google? Tak, ale jako jeden z wielu sygnałów. Nie oczekuj skoku o 20 pozycji po samej optymalizacji CWV. Wpływ jest realny, ale treść, linki i autorytet domeny ważą więcej.

Skąd Google bierze dane do oceny CWV? Z Chrome User Experience Report (CrUX) - danych zbieranych od użytkowników Chrome, którzy wyrazili na to zgodę. Wymagany percentyl 75. dla wszystkich trzech metryk. Jeśli Twoja strona nie ma wystarczająco dużo ruchu z Chrome, Google nie będzie miał danych field i CWV po prostu nie wejdą do oceny.

Czy wynik z PageSpeed Insights = moja ocena CWV? Nie do końca. PSI pokazuje dwa zestawy danych. Sekcja “Ocena korzystania ze stron w rzeczywistości” to dane field (te się liczą). Wynik Lighthouse poniżej to dane lab (przydatne do debugowania, ale nieużywane do rankingu).

Jak szybko po optymalizacji zmienią się wyniki CWV? CrUX zbiera dane z 28-dniowego okna. Po wdrożeniu zmian czekaj minimum 4-6 tygodni na pełne odzwierciedlenie w danych terenowych. W GSC aktualizacja raportu może trwać jeszcze dłużej.

Co jeśli moja strona nie ma danych field w CrUX? Potrzebujesz minimum ok. 1000 wizyt z Chrome w ciągu 28 dni, żeby origin miał dane w CrUX. Mniejsze strony mogą nie mieć danych. W takim przypadku Google nie używa CWV do rankingu (ani na plus, ani na minus). Możesz mierzyć CWV samodzielnie przez web-vitals.js.

Czy CWV to te same wyniki na mobile i desktop? Nie. Google ocenia je oddzielnie. Strona może mieć dobre wyniki na desktopie i słabe na mobile. Ponieważ Google stosuje mobile-first indexing, wyniki mobilne mają większe znaczenie.