LCP poniżej 2,5 sekundy na WordPressie – konkretna instrukcja

Largest Contentful Paint, czyli LCP, to wskaźnik mierzący, kiedy największy widoczny element na stronie pojawi się przed oczami użytkownika. Google traktuje wynik poniżej 2,5 sekundy jako „dobry”, 2,5–4 sekundy jako „wymaga poprawy”, powyżej 4 jako „słaby”. Co więcej – LCP to jeden z głównych sygnałów rankingowych Core Web Vitals, więc jego optymalizacja nie jest opcjonalna, jeśli zależy Ci na widoczności w Google.

Na WordPressie LCP zwykle zabijają trzy rzeczy: nieoptymalizowane obrazy, render-blocking CSS i JS, słaby hosting. Dobra wiadomość – wszystkie trzy da się naprawić bez przepisywania strony od zera.

Najpierw zmierz, nie zgaduj

Zanim zaczniesz cokolwiek zmieniać, zmierz aktualny stan. Trzy narzędzia, których używam standardowo: PageSpeed Insights (dane z laboratorium i z realnych użytkowników), WebPageTest (głębsza diagnoza waterfall) i Chrome DevTools w trybie Lighthouse (szybkie sprawdzenie po lokalnej zmianie).

Spójrz na konkretny element, który PageSpeed wskazuje jako LCP. Najczęściej to bohaterski obraz w nagłówku strony, czasem duży nagłówek tekstowy, sporadycznie blok wideo lub karuzela. Identyfikacja tego elementu jest kluczowa – bo cała dalsza optymalizacja kręci się wokół niego.

Obraz LCP – pierwsza i najważniejsza fala optymalizacji

Jeśli LCP to obraz (co jest najczęstszym scenariuszem), musisz załatwić cztery rzeczy:

• Format nowoczesny – WebP albo AVIF zamiast JPG/PNG, oszczędność 25–50% rozmiaru przy tej samej jakości
• Wymiary dopasowane do rzeczywistości — nie serwuj obrazu 3000×2000 px, jeśli wyświetlasz go w kontenerze 1200×800 px
• Atrybut fetchpriority="high" na tagu img, żeby przeglądarka załadowała go priorytetowo
• Brak lazy loadingu na LCP – loading="lazy" na obrazie LCP zabija Twoje wyniki, ten obraz musi się ładować od razu

W WordPressie najprościej zrobisz to przez wtyczki konwertujące obrazy (ShortPixel, Imagify, Converter for Media) plus drobna ingerencja w motyw potomny, żeby obraz hero miał odpowiednie atrybuty.

Cache i hosting – fundament, którego nie zastąpisz

Najszybszy obraz nic nie da, jeśli serwer odpowiada 1,5 sekundy. Sprawdź TTFB (Time To First Byte) – powinno być poniżej 600 ms, idealnie poniżej 200 ms. Jeśli jest gorzej, problem jest w hostingu albo w braku cache.

Cache strony konfiguruję zwykle przez WP Rocket albo LiteSpeed Cache (jeśli hosting wspiera LiteSpeed Server). Obie wtyczki załatwiają cache strony, minifikację, krytyczny CSS, lazy loading – w jednym miejscu. Dla mniejszych projektów wystarczy darmowy Cache Enabler plus Autoptimize.

Hosting — jeśli jesteś na shared hostingu za 10 zł miesięcznie, nie oczekuj cudów. Realna granica jakości to hostingi WordPressowe (Cyber_Folks, MyDevil, Mikrus, Kinsta dla bardziej wymagających projektów) z PHP 8.2+, OPcache i sensowną ilością zasobów.

CSS i JS blokujące renderowanie

Render-blocking resources to pliki CSS i JS, które przeglądarka musi pobrać i przetworzyć, zanim narysuje cokolwiek na ekranie. Każdy z nich opóźnia LCP. Walczy się z tym na trzy sposoby: usuwając niepotrzebne pliki (wtyczki, których nie używasz), defer/async dla skryptów, które mogą poczekać, oraz krytycznym CSS dla najważniejszych stylów.

Krytyczny CSS to mały kawałek stylów, który wystarczy do narysowania pierwszego widoku strony. Wbudowany w HTML jako inline, ładuje się od razu – bez czekania na zewnętrzny plik CSS. WP Rocket generuje go automatycznie, podobnie LiteSpeed Cache.

Czcionki webowe – cichy zabójca LCP

Jeśli Twój nagłówek (potencjalny LCP) używa Google Fonts ładowanego z zewnętrznego serwera, masz problem. Przeglądarka musi pobrać font, zanim narysuje tekst — to opóźnienie pojawiania się tego nagłówka. Trzy rzeczy do zrobienia: hostuj fonty lokalnie (nie z serwerów Google), użyj font-display: swap, przeładuj kluczowe fonty atrybutem preload.

Wtyczki – mniej znaczy szybciej

Każda aktywna wtyczka to potencjalne dodatkowe zapytanie do bazy, dodatkowe pliki CSS/JS, dodatkowe obciążenie. Zrób przegląd: które wtyczki realnie potrzebujesz, a które instalowałeś „na próbę” trzy lata temu i zostały? Wtyczki typu „social share buttons”, „related posts”, „contact form builders” potrafią dorzucić 200–500 KB do każdej strony.

Wtyczka Query Monitor pomaga zobaczyć, która wtyczka ile pamięci i czasu zżera. To brutalnie odsłania prawdę.

Pomiar po zmianach

Po każdej większej zmianie zmierz ponownie – i nie tylko PageSpeed Insights, ale też dane z realnych użytkowników w Search Console (raport Core Web Vitals). Dane z lab i z field potrafią się różnić, a Google rankuje na podstawie field.

Realny target dla strony firmowej to LCP w okolicach 1,5–2 sekundy. Poniżej 1 sekundy to terytorium dla geeków optymalizacji i da się tam dojść, ale dla większości biznesów nie ma to ekonomicznego sensu.