Praktyczna checklista Core Web Vitals dla stron contentowych
Core Web Vitals nagradzają trzy rzeczy: stronę, która szybko maluje główną treść (LCP), nie skacze podczas ładowania (CLS) i reaguje szybko na interakcje (INP). Większość stron pada na małym, przewidywalnym zestawie problemów.
- LCP: rozmiar obrazu hero, preload LCP image, defer render-blocking CSS/JS.
- CLS: zawsze ustawiaj width/height na obrazach, rezerwuj miejsce dla banerów.
- INP: mniej JavaScript, break up długie zadania, usuń zbędne skrypty trzecich stron.
- Dane terenowe (Search Console) ważniejsze niż Lighthouse — mierz realne doświadczenie.
- Na stronie pisanej ręcznie bez buildera większość tych problemów nigdy nie powstaje.
Kilka poprawek, które najbardziej przesuwają LCP, CLS i INP — w kolejności priorytetów, z omówieniem trade-offów, żebyś wiedział gdzie warto włożyć wysiłek.
Largest Contentful Paint (LCP)
- Dostosuj rozmiar obrazu hero. Serwuj nowoczesne formaty (WebP/AVIF), dokładne wymiary i rozsądną jakość. Hero to prawie zawsze element LCP.
- Preload co ważne. Preloaduj obraz LCP i fonty używane powyżej foldu, żeby przeglądarka pobierała je jako pierwsza.
- Zredukuj render-blocking. Defer nie-krytyczny CSS i JS, żeby główna treść nie czekała za nimi.
Cumulative Layout Shift (CLS)
- Zarezerwuj miejsce dla mediów. Zawsze ustawiaj width i height (lub aspect-ratio) na obrazach i embeddach — żadne reflowy gdy się ładują.
- Unikaj późno wstrzykiwanych banerów. Paski cookie i reklamy przesuwające treść w dół to klasyczne CLS — zarezerwuj im miejsce z góry.
- Użyj font-display: swap. I dopasuj metryki fallbacku, żeby swap nie przesuwał layoutu.
Interaction to Next Paint (INP)
INP karze za ciężką pracę na main thread. Największe zyski to wysyłanie mniej JavaScript i rozbijanie długich zadań. Na stronie contentowej winowajcą jest prawie zawsze skrypt trzeciej strony — builder, widget chat, stos analityki — robiący o wiele więcej niż potrzeba.
Większość problemów Core Web Vitals to tak naprawdę jeden problem w trzech odsłonach: strona wykonuje za dużo pracy, żeby pokazać za mało treści.
Mierz, nie zgaduj
Dane terenowe biją dane laboratoryjne. Obserwuj raport Core Web Vitals w Search Console po rzeczywiste liczby i używaj Lighthouse tylko do diagnozy. Poprawiaj metrykę, która naprawdę zawodzi u prawdziwych odwiedzających, nie tę najłatwiejszą do poprawienia w teście.
Na stronie pisanej ręcznie większość tego jest obsługiwana w czasie budowy, bo nigdy nie wysyłamy balastu, który to powoduje. Na istniejącej stronie ta checklista to zazwyczaj jeden-dwa dni skupionej pracy dla dużego, trwałego zysku.
Szybkie odpowiedzi
Obraz hero (zwykle to element LCP) i render-blocking resources. Serwuj hero jako WebP z właściwymi wymiarami + preload link; defer wszystkie nie-krytyczne skrypty i style. Samo to przesuwa LCP o 30–50% na typowej stronie WordPress.
Użyj font-display: optional lub swap z dopasowanymi metrykami fallback (size-adjust, ascent-override, descent-override). Najlepiej: self-host czcionki, eliminujesz zewnętrzne requesty i masz pełną kontrolę nad swapem.
Znacząco utrudnia ich osiągnięcie. Elementor ładuje ~400 KB+ CSS i JS na każdej stronie niezależnie od treści. Można go zoptymalizować do pewnego stopnia (Elementor Pro Experiments, CDN, caching), ale fizyczny limit jest niższy niż dla własnego, lekkiego motywu.
Spodobał się artykuł?
Dołącz do naszego Telegrama — praktyczne notatki o WordPressie, wydajności i widoczności w wyszukiwarkach AI. Bez lania wody.
Subskrybuj na TelegramieMasz projekt na oku?
Wyślij krótki brief — darmowa stała wycena w kilka godzin.