Jak czytać raport Core Web Vitals — pole vs lab, co naprawiać najpierw

Core Web Vitals (CWV) to trzy metryki wydajności, które Google używa jako sygnał rankingowy: LCP (ładowanie), INP (interaktywność) i CLS (stabilność wizualna). Problem: większość właścicieli stron nie wie, jak czytać raporty CWV, myli dane laboratoryjne z polowymi i naprawia nie to, co trzeba. Poniżej opisujemy, jak interpretować te dane — żebyś naprawiał rzeczy, które realnie wpływają na pozycje i konwersję.

Pole vs lab — fundamentalna różnica

To jest źródło 90% nieporozumień. Dane CWV pochodzą z dwóch źródeł:

• Dane polowe (field / CrUX) — zebrane od prawdziwych użytkowników w Chrome przez ostatnie 28 dni. To jest prawda o Twojej stronie — jak ją widzą realni użytkownicy na realnych urządzeniach i połączeniach.
• Dane laboratoryjne (lab / Lighthouse) — symulacja na jednym urządzeniu, z jednym połączeniem, w kontrolowanych warunkach. To jest przybliżenie — przydatne do debugowania, ale NIE pokazuje, jak strona działa w realnym świecie.

Kluczowe: Google używa danych polowych (CrUX) jako sygnału rankingowego, NIE laboratoryjnych. Wynik 95 w Lighthouse z laptopa nie znaczy nic, jeśli dane polowe pokazują LCP 4 sekundy na mobile. I odwrotnie — wynik 60 w Lighthouse nie jest problemem, jeśli dane polowe są zielone.

LCP — Largest Contentful Paint

LCP mierzy, kiedy największy element wizualny na stronie (zwykle hero image lub nagłówek H1) jest w pełni załadowany i widoczny. Google chce: <2.5s (dobre), 2.5–4.0s (do poprawy), >4.0s (słabe).

Co najczęściej psuje LCP (z naszych projektów):

• Duże obrazy bez optymalizacji — hero image 2 MB zamiast 200 KB. Rozwiązanie: WebP/AVIF, responsive images (srcset), preload dla LCP image.
• Wolny serwer (TTFB) — jeśli serwer odpowiada po 1.5s, LCP nie może być poniżej 1.5s + czas renderowania. Rozwiązanie: Redis, CDN, lepszy hosting.
• Render-blocking CSS/JS — pliki CSS i JS, które muszą się załadować zanim cokolwiek się wyświetli. Rozwiązanie: critical CSS inline, defer/async dla JS.
• Web fonty — ładowanie fontów z Google Fonts blokuje renderowanie. Rozwiązanie: font-display: swap, self-hosting fontów.

INP — Interaction to Next Paint

INP (od marca 2024 zastąpił FID) mierzy responsywność strony na interakcje użytkownika: kliknięcia, tappy, wpisywanie tekstu. Google chce: <200ms (dobre), 200–500ms (do poprawy), >500ms (słabe).

INP jest najtrudniejszą metryką do optymalizacji, bo zależy od JavaScriptu wykonywanego w przeglądarce. Co najczęściej psuje INP:

• Ciężki JavaScript — Elementor, jQuery, Swiper, Lightbox, Share widgets. Każdy skrypt blokuje main thread. Rozwiązanie: usunięcie zbędnych skryptów, lazy loading, web workers.
• Hydration w React/Next.js — client-side hydration dużych komponentów blokuje interaktywność. Rozwiązanie: Server Components, streaming, partial hydration.
• Event handlery w pętli — addEventListener na setki elementów (np. każdy produkt w katalogu). Rozwiązanie: event delegation.

CLS — Cumulative Layout Shift

CLS mierzy, jak bardzo elementy strony „skaczą" podczas ładowania. Google chce: <0.1 (dobre), 0.1–0.25 (do poprawy), >0.25 (słabe).

Co najczęściej powoduje CLS:

• Obrazy bez wymiarów — brak width/height na <img> powoduje, że przeglądarka nie rezerwuje miejsca. Rozwiązanie: zawsze podawaj width i height (lub aspect-ratio w CSS).
• Reklamy i embedy — AdSense, iFrame YouTube, widgety social media ładują się z opóźnieniem i przesuwają treść. Rozwiązanie: rezerwacja miejsca za pomocą min-height.
• Web fonty bez font-display: swap — tekst renderowany jednym fontem zmienia rozmiar po załadowaniu innego. Rozwiązanie: font-display: swap + dopasowanie fallback fontu.
• Dynamicznie wstrzykiwane banery — consent banery (cookie), alerty, promocje. Rozwiązanie: zarezerwuj miejsce lub użyj overlay zamiast push-down.

Co naprawiać najpierw — priorytetyzacja

Nie naprawiaj wszystkiego naraz. Nasza kolejność priorytetów:

• 1. LCP — ma największy wpływ na pozycję i konwersję. Wolna strona = użytkownik wychodzi. Zacznij od obrazów i TTFB.
• 2. CLS — łatwy do naprawienia (wymiary obrazów, font-display) i daje szybkie efekty w raporcie CrUX.
• 3. INP — najtrudniejszy, bo wymaga zmian w JavaScript. Naprawiaj po LCP i CLS, chyba że INP jest krytycznie zły (>500ms).

Pomiar po zmianach — jak długo czekać

Dane polowe (CrUX) aktualizują się z 28-dniowym oknem kroczącym. To znaczy: po naprawie LCP musisz czekać 2–4 tygodnie, zanim dane polowe pokażą poprawę. W tym czasie monitoruj dane lab (Lighthouse) — jeśli lab poprawione, pole dogoni.

Google Search Console aktualizuje raport CWV z opóźnieniem — zwykle 1–2 tygodnie po aktualizacji CrUX. Nie panikuj, jeśli GSC nadal pokazuje „do poprawy" tydzień po naprawie. Sprawdzaj CrUX bezpośrednio na web.dev/measure lub w Chrome DevTools (Ctrl+Shift+I → Performance → Core Web Vitals).

Czego NIE nadinterpretować: jednorazowy słaby wynik Lighthouse (zależy od obciążenia komputera), różnice 5–10 punktów między testami (normalne), „oportunistyczne" sugestie Lighthouse (nie wszystkie warte wdrożenia). Patrzymy na dane polowe w CrUX i trend tygodniowy — nie na pojedynczy test lab.

Z naszej praktyki — CWV w realnych projektach

Dwa kontrastujące podejścia do CWV w naszych projektach:

• Giełda Biomasy (Next.js 15 + Postgres) — CWV w zielonej strefie na wszystkich kluczowych stronach od dnia 1. LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. To zasługa stacku: SSG dla stron statycznych, ISR dla świeżych ofert, Vercel edge runtime, Next.js Image z automatyczną konwersją do WebP/AVIF. Web Vitals monitorowane są w czasie rzeczywistym poprzez własną tabelę zdarzeń serwerowych. Dla nowego projektu na Next.js to wzorzec do skopiowania — większość optymalizacji daje sam framework.
• Nobobobo i Podsztanga (WordPress + WooCommerce) — CWV wymagało aktywnej pracy. Wyjściowe LCP w okolicach 7-9 sekund (czerwona strefa), wynik PageSpeed mobile poniżej 50/100. Po wdrożeniu Redis Object Cache, kompresji obrazów do WebP, wymianie ciężkich motywów na lekkie i optymalizacji wtyczek — CWV przeszło do akceptowalnej strefy. To pokazuje, że na WordPress można osiągnąć dobre CWV, ale wymaga to świadomych decyzji architektonicznych.
• Trims&Fasteners i Sportywalki — projekty zmigrowane z WordPress + Elementor na Next.js. Powód migracji w obu przypadkach: CWV i wydajność. Po migracji LCP spadło wielokrotnie, INP w zielonej strefie, CLS poniżej 0,1. Decyzja o migracji była opłacalna biznesowo — szybsza strona = lepsza konwersja + lepsze pozycje organiczne.

Wzorzec: Next.js daje CWV w zielonej strefie „za darmo", WordPress wymaga aktywnej pracy. Dla nowych projektów z wymaganiami wydajnościowymi rekomendujemy Next.js. Dla istniejących stron WordPress z dobrym contentem migracja nie zawsze ma sens — często optymalizacja w miejscu wystarcza.

Jeśli potrzebujesz pomocy z optymalizacją wydajności strony — analizujemy CWV i wdrażamy naprawy, które realnie przesuwają dane polowe, a nie tylko wynik Lighthouse.