Core Web Vitals to trzy wskaźniki wydajności, na których Google oficjalnie opiera część swojego rankingu. Teoria jest prosta — praktyka bywa trudniejsza, bo każdy z nich zależy od innego zestawu czynników. Poniżej konkretna mapa: co mierzyć, gdzie szukać problemu i co realnie poprawia wyniki.
Trzy wskaźniki — co mierzą i jakie są progi
| Wskaźnik | Co mierzy | Dobry wynik |
|---|---|---|
| LCP (Largest Contentful Paint) | Czas do wyrenderowania największego elementu | < 2,5 s |
| INP (Interaction to Next Paint) | Opóźnienie odpowiedzi na interakcję użytkownika | < 200 ms |
| CLS (Cumulative Layout Shift) | Skoki layoutu podczas ładowania | < 0,1 |
Dane „field data” (z prawdziwych urządzeń) są ważniejsze niż wyniki w PageSpeed Insights — Google używa danych z Chrome UX Report, nie symulacji laboratoryjnej.
LCP — największy zysk, często na obrazach
LCP to zwykle hero image lub największy nagłówek w pierwszym ekranie. Najczęstsze przyczyny złego LCP i jak je naprawić:
- Obraz hero bez preload — przeglądarka odkrywa go dopiero po parsowaniu CSS. Rozwiązanie:
<link rel="preload" as="image" href="hero.webp">w sekcji <head> - Zbyt duży plik graficzny — JPEG 2 MB zamiast WebP 120 KB. Rozwiązanie: konwersja do WebP/AVIF, kompresja, odpowiedni srcset
- Slow server TTFB — jeśli serwer odpowiada wolno, LCP nie może być dobry bez względu na optymalizację frontendu. Rozwiązanie: dobry hosting (nie współdzielony), Redis object cache, Cloudflare
- Render-blocking CSS/JS — skrypty blokujące parsowanie dokumentu. Rozwiązanie: defer/async, eliminacja nieużywanego CSS
INP — nowy wskaźnik, który zastąpił FID
INP (Interaction to Next Paint) mierzy opóźnienie każdej interakcji — kliknięcia, tapnięcia, wpisywania — i bierze pod uwagę najgorszą (75. percentyl). Główne przyczyny problemów:
- Długie zadania JavaScript — kod blokujący wątek główny przez więcej niż 50 ms. Narzędzie: Chrome DevTools → Performance → Long Tasks
- Zbyt dużo skryptów analitycznych i marketingowych — każdy Tag Manager trigger to dodatkowy koszt. Warto auditować, które skrypty są naprawdę potrzebne
- Nieoptymalne event handlery — obsługa zdarzeń bez debounce/throttle na intensywnych eventach (scroll, resize)
CLS — skoki layoutu, które frustrują użytkowników
CLS to suma niespodziewanych przesunięć elementów. Użytkownik klika przycisk, a layout skacze — i klika w coś innego. Typowe przyczyny:
- Obrazy i video bez jawnych wymiarów — zawsze podawaj
widthiheightw HTML albo ustawaspect-ratiow CSS - Reklamy i banery wczytywane po fakcie — zarezerwuj miejsce na reklamę zanim się załaduje
- Webfonty powodujące FOUT — zamiana czcionki systemowej na webfont przesuwa tekst. Rozwiązanie:
font-display: optionallub preload czcionki
Gdzie są największe zyski — priorytetyzacja działań
Nie wszystkie optymalizacje dają ten sam efekt. W praktyce:
- Optymalizacja obrazów (format WebP, rozmiary, lazy-loading) — daje 30–60% poprawy LCP w większości projektów WordPress
- Dobry hosting z cache’owaniem (LiteSpeed + Redis lub Cloudflare) — eliminuje TTFB jako problem
- Preload LCP image + preconnect do zewnętrznych zasobów — szybka wygrana bez dużego nakładu
- Audyt i usunięcie zbędnych wtyczek i skryptów — redukuje INP i LCP
- Jawne wymiary obrazów i zarezerwowane miejsca na dynamiczne treści — poprawia CLS
Potrzebujesz audytu Core Web Vitals swojej strony? Napisz do nas — sprawdzimy Twój aktualny wynik i wskażemy konkretne działania z największym wpływem.