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