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.

Google ogłosił inicjatywę Web Vitals w maju 2020 roku. W czerwcu 2021 Core Web Vitals stały się częścią sygnałów dotyczących jakości strony w wynikach mobilnych, a w lutym 2022 roku wdrożenie objęło także wyniki na komputerach. W marcu 2024 FID (First Input Delay) został zastąpiony przez INP (Interaction to Next Paint), bo FID mierzył tylko pierwszą interakcję użytkownika i ignorował resztę wizyty. INP bierze pod uwagę wszystkie interakcje, dzięki czemu znacznie lepiej pokazuje responsywność strony.

Stan na 2026 rok jest prosty: Core Web Vitals obejmują LCP, INP i CLS. Google może z czasem zmieniać ten zestaw, ale obecnie nie zapowiedziało kolejnej metryki, która miałaby do niego dołączyć.

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 banery 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ę baner i przycisk przesuwa się o 200 pikseli w dół. Klient klika w baner zamiast w przycisk. Frustracja gwarantowana.

Testy laboratoryjne a pomiary rzeczywistych użytkowników

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

Pomiary laboratoryjne to wyniki z Lighthouse, PageSpeed Insights w trybie symulacji i Chrome DevTools. Test wykonuje się w kontrolowanych warunkach: przy założonej prędkości połączenia i wydajności procesora. Wyniki są powtarzalne i przydatne do diagnozowania problemów, bo możesz uruchomić test, wprowadzić zmianę i od razu porównać rezultat. Google nie wykorzystuje jednak wyniku takiej pojedynczej symulacji do oceny Core Web Vitals.

Pomiary rzeczywistych użytkowników pochodzą z kwalifikujących się wizyt w przeglądarce Chrome i są agregowane w Chrome User Experience Report (CrUX). Google ocenia 75. percentyl, czyli wartość, w której mieści się 75% zarejestrowanych wizyt. Dane obejmują ruchome okno 28 dni, dlatego pokazują długoterminowe doświadczenie użytkowników, a nie wynik jednorazowego testu.

Możesz mieć 95 punktów w Lighthouse i nadal nie spełniać progów CWV w danych z rzeczywistych wizyt, bo Twoi użytkownicy korzystają ze słabszych urządzeń i wolniejszych połączeń niż środowisko testowe. Widzimy to regularnie w audytach: klient chwali się wynikiem PageSpeed, ale w GSC cała witryna świeci na czerwono. Dlatego sprawdzaj zarówno sekcję „Ocena korzystania ze stron w rzeczywistości”, jak i wyniki laboratoryjne — służą do innych celów.

Narzędzia do pomiaru

Google Search Console

Raport Core Web Vitals w GSC pokazuje status grup URL-i witryny osobno dla urządzeń mobilnych i komputerów. Wskazuje, które metryki wymagają poprawy, na podstawie danych CrUX z rzeczywistych wizyt. To dobry punkt wyjścia do diagnostyki problemu w skali całego serwisu.

PageSpeed Insights

Łączy wyniki laboratoryjne Lighthouse z danymi CrUX na jednym ekranie. Po wpisaniu URL-a zobaczysz pomiary rzeczywistych użytkowników, o ile są dostępne, oraz wynik bieżącego testu i rekomendacje diagnostyczne.

CrUX Vis

CrUX Vis jest rekomendowanym następcą starego CrUX Dashboardu w Looker Studio. Pokazuje do 40 tygodni historii dla całej domeny w danym protokole, a tam, gdzie Google ma wystarczającą próbkę, także dla pojedynczego URL-a. Dane aktualizują się w poniedziałki, ale każdy punkt obejmuje poprzednie 28 dni — nie jest więc osobnym pomiarem z jednego tygodnia. Możesz przełączać urządzenia, 75. percentyl i rozkład wyników.

CrUX History API

Zwraca do 40 cotygodniowych punktów dla danego URL-a lub całej domeny w danym protokole. Przydaje się do automatycznego monitorowania trendów po wdrożeniu optymalizacji. Wymaga projektu w Google Cloud i klucza API.

CrUX via BigQuery

Dla tych, którzy potrzebują surowych danych, publiczny zbiór chrome-ux-report w Google BigQuery zawiera miesięczną historię od 2017 roku. Pozwala porównywać wiele domen, kraje i typy urządzeń, ale agreguje wyniki dla całej domeny w danym protokole — nie zawiera danych dla pojedynczych URL-i. Korzystanie wymaga projektu Google Cloud i znajomości SQL; niewielkie analizy zwykle mieszczą się w bezpłatnym limicie, ale koszt zależy od ilości przeskanowanych danych.

Najprostsze zapytanie do tabeli metrics_summary pobiera miesięczną historię 75. percentyla LCP, INP i CLS dla całej domeny:

SELECT
  yyyymm,
  origin,
  p75_lcp,
  p75_inp,
  p75_cls
FROM
  `chrome-ux-report.materialized.metrics_summary`
WHERE
  origin = 'https://twojadomena.pl'
ORDER BY
  yyyymm DESC
LIMIT 12

web-vitals.js

Biblioteka JavaScript od Google, którą instalujesz na swojej stronie. Mierzy CWV podczas rzeczywistych wizyt i może wysyłać wyniki do Twojego systemu analitycznego. Dzięki temu nie zależysz od nieujawnionego progu popularności CrUX i możesz analizować własne segmenty, szablony oraz pojedyncze URL-e.

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. Banery 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 banery 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.