LCP powyżej 4 sekund na mobile to w raportach PageSpeed Insights najczęstszy powód, dla którego strona na WordPressie nie przechodzi oceny Core Web Vitals. Poprawa LCP w WordPressie rzadko sprowadza się do jednej wtyczki: w praktyce nakładają się na siebie cztery, pięć drobnych przyczyn, z których każda dokłada po kilkaset milisekund.
Ten tekst jest częścią serii o widoczności firm w wyszukiwarkach i asystentach AI. Użytkownik z Map Google lub z odpowiedzi ChatGPT ląduje niemal zawsze na telefonie; jak w ogóle tam trafia, opisujemy w przewodniku o tym, jak lokalna firma pojawia się w wynikach AI.
W skrócie
- Próg „dobrego” LCP to 2,5 s; wynik powyżej 4,0 s Google klasyfikuje jako słaby i liczy go na podstawie danych z realnych urządzeń (CrUX), nie z testu laboratoryjnego.
- W WordPressie za większość opóźnienia odpowiadają cztery rzeczy: obraz nagłówkowy, fonty, CSS i JavaScript motywu oraz czas odpowiedzi serwera (TTFB).
- Najwięcej daje poprawka elementu LCP i TTFB; zmiany w ustawieniach cache i fontach są tańsze, ale dają po 200–500 ms.
- Efekt w Search Console widać dopiero po 28 dniach, bo tyle wynosi okno zbierania danych CrUX.
Jak czytać LCP w danych CrUX i w PageSpeed
Sekcja „Odkryj, czego doświadczają rzeczywiści użytkownicy” pochodzi z Chrome UX Report (CrUX): to 75. percentyl LCP z ostatnich 28 dni, mierzony na prawdziwych telefonach z prawdziwym zasięgiem. Sekcja „Diagnozuj problemy z wydajnością” to pojedynczy test Lighthouse na symulowanym Moto G Power i wolnym 4G.
Do oceny w Search Console liczy się wyłącznie CrUX. Lighthouse służy do znalezienia przyczyny: w sekcji „Element największego wyrenderowania treści” widać, który dokładnie element strony jest elementem LCP, a w podpunktach Lighthouse rozbija czas na cztery fazy: TTFB, opóźnienie ładowania zasobu, czas ładowania zasobu i opóźnienie renderowania.
| Faza LCP | Typowy udział w WordPressie | Gdzie szukać przyczyny |
|---|---|---|
| TTFB (czas do pierwszego bajta) | 600–1500 ms | Hosting, brak cache strony, ciężkie zapytania wtyczek |
| Opóźnienie ładowania zasobu | 300–1200 ms | Obraz ładowany leniwie lub odkrywany dopiero po CSS/JS |
| Czas ładowania zasobu | 400–2000 ms | Za duży plik obrazu, brak WebP/AVIF, brak srcset |
| Opóźnienie renderowania | 200–800 ms | Fonty, blokujący CSS, JavaScript buildera |
Obraz nagłówkowy: format, rozmiar, priorytet ładowania
Elementem LCP na mobile jest w większości motywów WordPress obraz wyróżniający lub tło sekcji hero; trzy pierwsze przyczyny dotyczą właśnie jego.
Przyczyna 1: obraz jest za duży dla ekranu telefonu
Motyw serwuje na telefonie ten sam plik co na monitorze: 1920 px szerokości i 400–900 KB. WordPress od wersji 4.4 generuje atrybut srcset, ale wiele motywów i builderów wstawia obraz hero jako tło CSS (background-image), które srcset nie obsługuje. Rozwiązaniem jest zamiana tła na zwykły znacznik <img> w sekcji hero lub użycie image-set() w CSS. Wagę pliku obniża konwersja do WebP lub AVIF (WordPress 6.5+): typowy zysk to 40–60%.
Przyczyna 2: element LCP ładuje się leniwie
Wtyczki optymalizacyjne dodają loading="lazy" do wszystkich obrazów, także do tego pierwszego, widocznego od razu. Przeglądarka odkłada wtedy jego pobranie do momentu ułożenia strony, co w Lighthouse widać jako długie „opóźnienie ładowania zasobu”. Rdzeń WordPressa pomija pierwszy obraz w treści, ale nie obraz hero z motywu. Wyłączenie leniwego ładowania dla elementu LCP to zwykle jedna opcja w ustawieniach wtyczki lub filtr wp_omit_loading_attr_threshold.
Przyczyna 3: brak priorytetu i wczesnego odkrycia
Nawet prawidłowo wstawiony obraz przeglądarka może odkryć późno, jeśli jego adres pojawia się w CSS lub jest wstrzykiwany przez JavaScript. Atrybut fetchpriority="high" (WordPress dodaje go automatycznie od wersji 6.3, ale tylko do obrazów w treści) oraz znacznik <link rel="preload" as="image"> w sekcji <head> przesuwają pobranie na sam początek. Sam preload skraca LCP na wolnym 4G o 300–700 ms.
Fonty i zapytania blokujące render
Przyczyna 4: fonty z zewnętrznego serwera bez font-display
Fonty z Google Fonts wymagają połączenia z innym hostem, co na sieci komórkowej kosztuje 200–400 ms, zanim pobierze się pierwszy bajt. Jeśli element LCP to nagłówek tekstowy, a font nie ma deklaracji font-display: swap, przeglądarka wstrzymuje wyświetlenie tekstu do momentu pobrania fontu. Rozwiązanie: fonty hostowane lokalnie w formacie WOFF2, ograniczone do dwóch, trzech odmian, z font-display: swap i preloadem tylko odmiany użytej w hero.
Przyczyna 5: CSS wtyczek ładowany na każdej stronie
Typowy WordPress z 25 wtyczkami ładuje w <head> 15–30 arkuszy stylów, z których na stronie głównej wykorzystuje kilka. Każdy arkusz blokuje renderowanie, dopóki nie zostanie pobrany i przetworzony. Wtyczki do cache umieją wygenerować krytyczny CSS (fragment potrzebny do wyświetlenia części widocznej bez przewijania) i odłożyć resztę na później. Szczegóły konfiguracji cache, obrazów i fontów bez wtyczek typu „wszystko w jednym” opisujemy w tekście o WordPressie i Core Web Vitals.
Motyw i buildery stron jako źródło opóźnień
Przyczyna 6: builder renderuje hero przez JavaScript
Elementor, WPBakery i część motywów premium generują sekcję hero z animacjami lub sliderem, którego pierwszy slajd (czyli element LCP) pojawia się dopiero po wykonaniu kilkuset kilobajtów JavaScriptu. Na telefonie ze średniej półki wykonanie tego kodu zajmuje 1–2 s i w całości ląduje w fazie „opóźnienie renderowania”. Najskuteczniejsza poprawka to statyczny obraz zamiast slidera; jeśli slider musi zostać, pierwszy slajd powinien być zwykłym HTML z serwera, a skrypt karuzeli ładowany z opóźnieniem.
Przyczyna 7: nadmiar JavaScriptu wykonywanego przed renderem
Skrypty śledzące, czat, mapa, wtyczka zgody na ciasteczka: każdy wstawiony w <head> bez defer lub async zatrzymuje parser HTML. Wszystko poza krytycznym CSS i preloadem elementu LCP powinno mieć defer, a skrypty marketingowe warto uruchamiać dopiero po pierwszej interakcji użytkownika. Dotyczy to też pikseli reklamowych, które coraz częściej przenosi się na serwer, jak przy konfiguracji Conversions API w Meta Ads; to samo przeniesienie odciąża przeglądarkę na telefonie.
Wtyczki cache: ustawienia, które realnie pomagają
Wtyczka cache nie naprawia LCP sama z siebie. Domyślna instalacja WP Rocket, LiteSpeed Cache czy W3 Total Cache włącza cache strony i minifikację, ale opcje o największym wpływie na LCP trzeba włączyć ręcznie.
- Cache strony dla użytkowników niezalogowanych z czasem życia co najmniej 10 godzin i wstępnym generowaniem (preload) po wyczyszczeniu.
- Krytyczny CSS generowany per typ strony, z odroczonym ładowaniem pozostałych arkuszy.
- Odroczenie JavaScriptu z listą wyjątków dla skryptów, które muszą działać od razu (np. skrypt zgody na ciasteczka, jeśli blokuje inne).
- Wyłączenie leniwego ładowania dla pierwszego obrazu lub jawne wskazanie elementu LCP do preloadu.
- Lokalne hostowanie fontów Google z dodaniem
font-display: swap.
Czas odpowiedzi serwera i hosting
Przyczyna 8: TTFB powyżej 800 ms
Google zaleca TTFB poniżej 800 ms, a na tanim hostingu współdzielonym WordPress z kilkunastoma wtyczkami potrafi odpowiadać po 1,5–2,5 s. Diagnoza jest prosta: wynik komendy curl -o /dev/null -w "%{time_starttransfer}" https://twojadomena.pl/ pokazuje TTFB bez wpływu przeglądarki. Jeśli przekracza 800 ms przy włączonym cache, winny jest zwykle serwer (przeciążony hosting, brak PHP 8.x lub OPcache) albo wtyczka odpytująca zewnętrzne API przy każdym żądaniu.
Przyczyna 9: brak CDN lub cache na krawędzi
Dla ruchu z Polski serwer w Polsce lub Niemczech wystarczy, ale strony z klientami w kilku krajach zyskują na cache HTML w sieci CDN. Cloudflare w planie darmowym potrafi cachować pełne strony HTML dla niezalogowanych użytkowników, co sprowadza TTFB do 50–150 ms niezależnie od lokalizacji. Pełne omówienie warstwy hostingu i konfiguracji serwera pod Core Web Vitals znajduje się w poradniku jak przyspieszyć WordPress pod CWV.
Kolejność poprawek według zysku
Kolejność ma znaczenie, bo poprawki się maskują: preload obrazu nic nie da, jeśli serwer przez 2 s nie wysłał jeszcze HTML.
| Krok | Poprawka | Typowy zysk LCP na mobile | Nakład |
|---|---|---|---|
| 1 | Cache strony + poprawa TTFB (hosting, PHP 8.x) | 500–1500 ms | Niski do średniego |
| 2 | Element LCP: WebP/AVIF, właściwy rozmiar, bez lazy, preload, fetchpriority | 500–1200 ms | Niski |
| 3 | Fonty lokalne + font-display: swap | 200–500 ms | Niski |
| 4 | Krytyczny CSS + odroczenie arkuszy wtyczek | 200–600 ms | Średni (ryzyko błędów w wyglądzie) |
| 5 | Zamiana slidera/animacji hero na statyczny obraz | 300–1000 ms | Średni (decyzja projektowa) |
| 6 | Odroczenie skryptów marketingowych | 100–400 ms | Niski |
Dwa pierwsze kroki zwykle wystarczają, żeby zejść z 4,5 s poniżej 2,5 s w teście laboratoryjnym; w CrUX wynik będzie gorszy o 20–40%, bo realni użytkownicy mają słabsze telefony i zasięg.
Weryfikacja po wdrożeniu
Po zmianach warto sprawdzić w Lighthouse (mobile) trzy rzeczy: czy element LCP jest nadal ten sam, czy jego adres pojawia się w preloadzie i czy faza „opóźnienie ładowania zasobu” spadła poniżej 200 ms. Test warto powtórzyć na kilku typach stron, bo element LCP na każdej bywa inny.
Zmiana w Search Console w raporcie „Podstawowe wskaźniki internetowe” pojawi się po 28 dniach, kiedy okno CrUX w całości obejmie okres po poprawkach. Wcześniej postęp widać w API CrUX z granulacją dzienną. Szczegółowy opis metryk i progów jest w dokumentacji web.dev na temat LCP.
Na koniec warto spojrzeć szerzej niż na sam wskaźnik. Lokalna firma ze stroną ładującą się w 2 s wygrywa nie tylko w Core Web Vitals: użytkownik z Map Google szybciej dociera do telefonu i formularza, a to przekłada się na opinie, o których piszemy w tekście o tym, ile opinii Google potrzebuje lokalna firma, żeby polecały ją asystenty AI. Sama widoczność w tych asystentach to temat przewodnika o lokalnej firmie w wynikach AI, w którym szybkość strony jest jednym z sygnałów wiarygodności.
FAQ: najczęstsze pytania o LCP w WordPressie
Dlaczego LCP w PageSpeed Insights jest inne niż w Search Console?
PageSpeed pokazuje dwie wartości: laboratoryjną (jednorazowy test Lighthouse) i terenową (CrUX, 75. percentyl z 28 dni). Search Console korzysta wyłącznie z danych CrUX, dlatego wynik w konsoli zmienia się z opóźnieniem i jest zwykle gorszy niż test laboratoryjny wykonany na szybkim łączu.
Czy sama wtyczka cache wystarczy, żeby poprawić LCP?
Nie. Cache strony poprawia TTFB, czyli jedną z czterech faz LCP. Jeśli elementem LCP jest obraz o wadze 800 KB ładowany leniwie, cache nie zmieni czasu jego pobrania. Potrzebne są też poprawki obrazu (format, rozmiar, preload) i, w większości motywów, fontów oraz CSS.
Jak sprawdzić, który element strony jest elementem LCP?
W raporcie Lighthouse (PageSpeed Insights, zakładka mobile) sekcja „Element największego wyrenderowania treści” wskazuje konkretny znacznik HTML wraz z rozbiciem czasu na fazy. W Chrome DevTools (zakładka Performance) znacznik LCP pojawia się na osi czasu z podglądem elementu.
Ile trwa, zanim poprawa LCP będzie widoczna w Search Console?
Do 28 dni. CrUX agreguje dane w oknie 28-dniowym, więc dopiero po pełnym cyklu od wdrożenia poprawek wynik odzwierciedla nowy stan. Częściowa poprawa bywa widoczna po 7–10 dniach, gdy nowe pomiary zaczynają dominować w oknie.