Core Web Vitals — jak szybkość strony wpływa na pozycje w Google
Core Web Vitals to zestaw trzech metryk Google (LCP, INP, CLS) mierzących szybkość ładowania, interaktywność i stabilność wizualną strony.
Google powiedział to wprost: szybkość = pozycje
W 2021 roku Google oficjalnie ogłosił Core Web Vitals jako ranking factor. Nie sugestię. Nie „jeden z wielu sygnałów". Oficjalny ranking factor wbudowany w algorytm.
Co to oznacza w praktyce? Dwie strony z identycznym contentem i linkami — szybsza wygrywa.
A w 2026 roku, gdy AI Overview i SGE zmieniają SERP, szybkość jest jeszcze ważniejsza. Google coraz częściej wybiera szybkie strony do swoich snippetów, bo użytkownicy oczekują natychmiastowego dostępu.
Trzy metryki Core Web Vitals
1. LCP — Largest Contentful Paint
Co mierzy: Czas od wejścia na stronę do wyświetlenia największego elementu widocznego na ekranie (hero image, nagłówek, video).
Progi:
- 🟢 Dobry: <2,5 sekundy
- 🟡 Wymaga poprawy: 2,5–4 sekundy
- 🔴 Słaby: >4 sekundy
Dlaczego to ważne: LCP to moment, w którym użytkownik widzi „prawdziwą" stronę. Przed LCP widzi białą stronę lub fragmenty. 53% użytkowników opuszcza stronę, jeśli ładuje się dłużej niż 3 sekundy.
Typowe problemy:
- Duże obrazy hero bez optymalizacji (5 MB PNG zamiast 100 KB WebP)
- Wolny serwer (TTFB >600ms)
- Render-blocking CSS/JS — przeglądarka nie może wyświetlić strony, bo ładuje skrypty
- Third-party scripts (czat, analytics, reklamy) blokujące rendering
- Brak CDN — serwer w USA, użytkownik w Polsce
Jak naprawić:
- Obrazy: WebP/AVIF, lazy loading (poza first viewport), preload hero image, srcset z responsywnymi rozmiarami
- Serwer: TTFB <200ms — rozważ CDN, edge rendering, SSG (Next.js generuje statyczne pliki)
- CSS: Inline critical CSS, async load reszty
- JS: Defer/async, code splitting, usunięcie nieużywanych bibliotek
- Fonty:
font-display: swap, preload dla critical fontów
2. INP — Interaction to Next Paint
Co mierzy: Czas od interakcji użytkownika (kliknięcie, tap, key press) do widocznej reakcji strony. Zastąpił FID (First Input Delay) w marcu 2024.
Progi:
- 🟢 Dobry: <200 milisekund
- 🟡 Wymaga poprawy: 200–500 milisekund
- 🔴 Słaby: >500 milisekund
Dlaczego to ważne: INP mierzy responsywność. Klikasz przycisk — ile czasu mija, zanim cokolwiek się zmieni na ekranie? 200ms to próg, poniżej którego interakcja czuje się „natychmiastowa". Powyżej — czujesz opóźnienie.
Typowe problemy:
- Ciężki JavaScript blokujący main thread
- Event handlers z ciężkimi obliczeniami
- Zbyt wiele re-renderów (React bez memoizacji)
- Third-party scripts (chat widgets, analytics)
- Zbyt głęboki DOM tree (>1500 elementów)
Jak naprawić:
- Mniej JS: Code splitting, tree shaking, usunięcie nieużywanych bibliotek
- Web Workers: Przenieś ciężkie obliczenia z main thread
- React: useMemo, useCallback, React.memo, lazy loading komponentów
- Debounce/throttle: event handlery, scroll listeners
- Third-party audit: Zmierz wpływ każdego zewnętrznego skryptu
3. CLS — Cumulative Layout Shift
Co mierzy: Niestabilność wizualną strony. Ile elementów „przeskakuje" podczas ładowania.
Progi:
- 🟢 Dobry: <0,1
- 🟡 Wymaga poprawy: 0,1–0,25
- 🔴 Słaby: >0,25
Dlaczego to ważne: Najgorsze UX to próba kliknięcia przycisku, który nagle przesuwa się o 200px w dół, bo załadował się baner reklamowy. CLS mierzy dokładnie ten problem.
Typowe problemy:
- Obrazy i video bez zdefiniowanych wymiarów (width/height)
- Dynamicznie ładowane reklamy i embedy
- Web fonty powodujące FOUT/FOIT (flash of unstyled/invisible text)
- Dynamicznie wstrzykiwany content (banery, cookie consent)
- CSS animations zmieniające wymiary elementów
Jak naprawić:
- Zawsze definiuj wymiary:
<img width="800" height="600">lub aspect-ratio w CSS - Rezerwuj przestrzeń: Placeholder dla dynamicznego contentu (reklamy, embedy)
- Font-display: optional lub swap z dobrym fallback fontem
- Avoid insertBefore: Nie wstrzykuj elementów powyżej istniejącego contentu
- Transform animations: Używaj
transformzamiasttop/left/width/height
Jak mierzyć Core Web Vitals?
Narzędzia z realnymi danymi (field data)
Real User Monitoring — dane od prawdziwych użytkowników.
| Narzędzie | Koszt | Co daje |
|---|---|---|
| Google Search Console | Darmowe | CWV report, problematyczne URL-e |
| PageSpeed Insights | Darmowe | CrUX data + Lighthouse lab data |
| CrUX Dashboard | Darmowe | Historyczne dane 28 dni |
| Chrome UX Report | Darmowe | BigQuery, surowe dane |
Narzędzia laboratoryjne (lab data)
Symulowane testy — powtarzalne, kontrolowane warunki.
| Narzędzie | Koszt | Co daje |
|---|---|---|
| Lighthouse (Chrome DevTools) | Darmowe | Pełny raport performance |
| WebPageTest | Darmowe | Waterfall, filmstrip, multi-lokalizacje |
| Chrome DevTools Performance | Darmowe | Flame chart, main thread analysis |
Monitoring ciągły
| Narzędzie | Koszt | Co daje |
|---|---|---|
| Vercel Analytics | Darmowe/Pro | Real-time CWV dla Next.js |
| Sentry Performance | Darmowe/Pro | Error tracking + performance |
| SpeedCurve | Płatne | Continuous monitoring, alerty |
Pro tip: Field data > Lab data. Lighthouse w DevTools daje szybkie odpowiedzi, ale ranking opiera się na field data z CrUX.
Wpływ CWV na pozycje — dane
Badanie SearchPilot (2024) na 500 000 stronach:
- Strony z dobrymi CWV (wszystkie 3 zielone) mają średnio 12% wyższy CTR niż strony ze słabymi CWV
- Poprawa LCP z 4s do 2s koreluje z wzrostem pozycji o 2–5 miejsc na frazy średniej konkurencyjności
- Strony z CLS >0,25 mają 15% wyższy bounce rate niż strony z CLS <0,1
Uwaga: CWV to tiebreaker, nie game changer. Jeśli Twój content jest 10x lepszy od konkurencji, wygrasz mimo wolnej strony. Ale jeśli content jest porównywalny — CWV decyduje.
Jak szybko poprawić CWV? (Quick wins)
5 minut — rezultat natychmiastowy:
- Dodaj
widthiheightdo wszystkich<img>(CLS) - Dodaj
loading="lazy"do obrazów poza first viewport (LCP) - Dodaj
font-display: swapw CSS (CLS)
30 minut — znacząca poprawa:
- Konwertuj obrazy na WebP (LCP — redukcja rozmiaru o 25–35%)
- Przenieś third-party scripts na
deferlubasync(INP) - Inline critical CSS (LCP)
- Preload hero image i critical fonty (LCP)
Kilka godzin — fundament:
- Wdróż CDN (LCP — TTFB)
- Włącz HTTP/2 lub HTTP/3 (LCP)
- Zaudytuj i usuń nieużywane biblioteki JS (INP)
Duża zmiana — architekturalna:
- Migracja na SSG/SSR (Next.js) — LCP <1s standardowo
- Image optimization pipeline (responsive images, AVIF)
- Edge rendering (Vercel, Cloudflare Workers)
CWV a Next.js
Dlaczego Next.js wygrywa z większością stron WordPress/Wix/Squarespace w CWV?
| Mechanizm | Efekt na CWV |
|---|---|
| Static Site Generation (SSG) | LCP: HTML gotowy, zero renderowania na serwerze |
| Automatic code splitting | INP: Ładujesz tylko JS potrzebny na danej stronie |
| Next/Image | LCP + CLS: Automatyczna optymalizacja, WebP, lazy loading, wymiary |
| Next/Font | CLS: Zero layout shift z fontami |
| Edge Runtime | LCP: Rendering blisko użytkownika, TTFB <50ms |
| Streaming SSR | LCP: Progresywne renderowanie — użytkownik widzi content wcześniej |
Typowa strona Next.js z naszymi optymalizacjami: Lighthouse 95–100 na mobile. Bez sztuczek, bez cache, bez CDN premium.
Checklist CWV
LCP (<2,5s)
- Hero image w WebP/AVIF, <200 KB
- Preload hero image
- TTFB <200ms
- Critical CSS inline
- Brak render-blocking JS
INP (<200ms)
- Main thread nie blokowany >200ms
- Third-party scripts defer/async
- Event handlers zoptymalizowane
- Code splitting aktywne
CLS (<0,1)
- Wszystkie obrazy mają width/height
- Fonty z font-display: swap/optional
- Brak dynamicznie wstrzykiwanego contentu above the fold
- Reklamy/embedy z zarezerwowaną przestrzenią
Podsumowanie
Core Web Vitals to nie buzzword — to mierzalny ranking factor z konkretnymi progami. Strona z dobrymi CWV rankuje wyżej, ma niższy bounce rate i wyższy CTR.
Najszybsza droga do zielonych CWV? Nowoczesna technologia (Next.js), optymalizowane obrazy, minimalny JavaScript i CDN.
Chcesz sprawdzić CWV swojej strony? Zamów bezpłatny audyt wydajności — zmierzymy i pokażemy, co poprawić.