WordPress i Core Web Vitals da się pogodzić bez wtyczki typu all in one. Cache strony, poprawne obrazy i lokalne fonty to trzy elementy, które odpowiadają za większość wyniku LCP i CLS, a każdy z nich można skonfigurować osobno, mniejszym i przewidywalnym narzędziem. Taki stos jest lżejszy, rzadziej konfliktuje z motywem i łatwiej go zdiagnozować, gdy coś przestaje działać.
W skrócie
- Wtyczki all in one łączą cache, minifikację, lazy loading i CDN w jednym panelu, ale ich warstwy często dublują to, co robi już hosting lub motyw.
- Cache strony (pełny HTML) daje największy skok TTFB i LCP; cache obiektowy ma sens dopiero przy zalogowanych użytkownikach lub sklepie.
- Obrazy: WebP lub AVIF, jawne wymiary
widthiheight, brak lazy loadingu na obrazie LCP. - Fonty hostowane lokalnie z
font-display: swapi jednympreloadusuwają zewnętrzne żądania i skoki układu. - Wdrażajcie zmiany pojedynczo i mierzcie po każdej, inaczej nie wiecie, która z nich pomogła.
Dlaczego wtyczki all in one bywają problemem
Największa wada pakietów wydajnościowych to nakładanie się warstw. Typowa instalacja WordPressa w 2026 roku ma już cache po stronie hostingu (LiteSpeed, Nginx FastCGI albo Varnish), kompresję Brotli na serwerze i CDN z własną optymalizacją obrazów. Wtyczka all in one dokłada do tego drugi cache, drugą minifikację i drugi lazy loading, a każda dublująca się warstwa to dodatkowy punkt awarii.
Drugi problem to konflikty z motywem i innymi rozszerzeniami. Agresywne łączenie plików JavaScript potrafi zepsuć suwaki, formularze i skrypty zgód na cookies, a agresywne opóźnianie skryptów zdejmuje z listy również Google Tag Managera. Efekt widać w danych: pomiary wpadają w INP, bo skrypty uruchamiają się dopiero po pierwszej interakcji użytkownika. Więcej o tym, które rozszerzenia realnie spowalniają witrynę, znajdziecie w zestawieniu wtyczek, które pomagają w SEO i tych, które szkodzą.
Trzeci argument to kontrola. W panelu z 80 przełącznikami trudno powiedzieć, która opcja odpowiada za dany efekt. Trzy małe narzędzia, każde z jednym zadaniem, wyjaśniają się same.
Cache strony i cache obiektowy: co dokłada TTFB, a co nie
Cache strony zapisuje gotowy HTML i serwuje go bez uruchamiania PHP ani zapytań do bazy. To ten element obniża TTFB z 600–900 ms do 100–200 ms i bezpośrednio poprawia LCP, bo przeglądarka wcześniej dostaje dokument i wcześniej odkrywa obraz główny.
Kolejność wyboru jest prosta:
- Jeśli hosting ma LiteSpeed, użyjcie LiteSpeed Cache w trybie tylko cache (pozostałe moduły wyłączone). Cache działa wtedy na poziomie serwera, przed PHP.
- Jeśli hosting oferuje Nginx FastCGI cache lub Varnish, włączcie go w panelu i nie instalujcie żadnej wtyczki cache.
- W pozostałych przypadkach wystarczy lekka wtyczka zapisująca statyczne pliki HTML na dysk, na przykład Cache Enabler lub WP Super Cache w trybie expert.
Cache obiektowy (Redis lub Memcached) przechowuje wyniki zapytań do bazy między żądaniami. Dla bloga z anonimowym ruchem daje niewiele, bo strony i tak wychodzą z cache HTML. Sens pojawia się przy WooCommerce, forum, kursach albo dużej liczbie zalogowanych użytkowników, gdzie każde żądanie omija cache strony. Wtedy Redis Object Cache z jedną opcją do włączenia załatwia sprawę.
| Warstwa | Co robi | Wpływ na CWV | Kiedy potrzebna |
|---|---|---|---|
| Cache strony | Serwuje gotowy HTML | TTFB, LCP | Zawsze |
| Cache obiektowy | Trzyma wyniki zapytań SQL | TTFB dla zalogowanych | Sklep, forum, kursy |
| Cache przeglądarki | Nagłówki Cache-Control | Powtórne wizyty | Zawsze, zwykle serwer |
| CDN | Serwuje statyki z bliskiego węzła | LCP dla ruchu spoza kraju | Ruch międzynarodowy |
Obrazy: formaty, rozmiary i sposób ładowania
Obraz główny artykułu jest w większości motywów elementem LCP, więc od jego obsługi zależy najważniejsza metryka. Trzy zasady załatwiają 90% przypadków: nowoczesny format, jawne wymiary i brak opóźniania na pierwszym obrazie.
WordPress od wersji 6.5 potrafi generować WebP i AVIF przy wgrywaniu, o ile serwer ma bibliotekę Imagick lub GD z obsługą tych formatów. Jedna linia w pliku functions.php przełącza domyślny format wyjściowy, bez wtyczki. AVIF jest średnio o 20–30% lżejszy od WebP przy tej samej jakości, ale jego generowanie na słabszych hostingach trwa kilkukrotnie dłużej.
Atrybuty width i height WordPress dodaje sam do obrazów wstawionych przez edytor. Problem pojawia się w obrazach z motywu, sliderach i blokach pobierających grafiki z pól dodatkowych: tam brak wymiarów oznacza skok układu i wzrost CLS. Sprawdźcie to raz w kodzie źródłowym strony i uzupełnijcie w szablonach.
Lazy loading rdzeń WordPressa włącza od wersji 5.5 dla wszystkich obrazów poza pierwszym w treści. Obraz wyróżniający renderowany przez motyw często i tak dostaje loading="lazy", co opóźnia LCP o 300–800 ms. Poprawka to filtr wp_get_attachment_image_attributes, który dla miniatury wpisu ustawia loading="eager" i fetchpriority="high". To ta sama technika, którą opisujemy szerzej w poradniku o przyspieszaniu WordPressa pod CWV.
Fonty lokalne i wstępne wczytywanie
Fonty z Google Fonts to dwa dodatkowe połączenia (fonts.googleapis.com i fonts.gstatic.com), zanim przeglądarka pobierze pierwszy plik. Hostowanie plików WOFF2 na własnej domenie usuwa te połączenia, a dodatkowo zamyka wątek RODO związany z przekazywaniem adresów IP do Google.
Procedura zajmuje kwadrans. Pobieracie pliki WOFF2 tylko dla używanych grubości (zwykle 400 i 700), wgrywacie do katalogu motywu potomnego i deklarujecie w CSS przez @font-face z font-display: swap. Wartość swap pokazuje tekst w foncie systemowym od razu i podmienia go po wczytaniu, co chroni LCP tekstowe. Dokumentację właściwości znajdziecie w MDN Web Docs.
Do tego jeden tag <link rel="preload" as="font" type="font/woff2" crossorigin> dla fontu nagłówków, umieszczony w sekcji head. Preloadujcie maksymalnie dwa pliki: każdy kolejny konkuruje o pasmo z obrazem LCP i zaczyna szkodzić. Jeśli motyw ładuje fonty z Google przez własny mechanizm, wyłączcie to w ustawieniach lub odepnijcie stylem wp_dequeue_style.
CSS i JavaScript: co realnie warto odchudzać
Minifikacja CSS i JS daje zwykle 5–10% oszczędności na rozmiarze i przy Brotli na serwerze jest prawie niewidoczna w metrykach. Nie ma sensu instalować dla niej osobnej wtyczki. Realny zysk daje usuwanie zasobów, nie ich kompresowanie.
Zacznijcie od listy skryptów i stylów ładowanych na pojedynczym wpisie. Najczęstsi kandydaci do odpięcia: style bloków, których wpis nie używa, biblioteki suwaków z motywu, emoji z rdzenia, style formularza kontaktowego na każdej podstronie. Odpięcie robi się przez wp_dequeue_script i wp_dequeue_style warunkowo, na przykład tylko poza stroną kontaktu.
Skrypty zewnętrzne (analityka, czat, mapy) ładujcie z atrybutem defer lub po pierwszej interakcji, ale świadomie i pojedynczo. Automatyczne opóźnianie wszystkiego to najczęstsza przyczyna zepsutych formularzy i mylących odczytów INP. Jeśli INP jest waszym głównym problemem, poświęciliśmy mu osobny tekst o INP w praktyce dla WordPressa.
Kolejność wdrożenia i pomiar po każdym kroku
Zmiany wprowadzajcie pojedynczo, w tej kolejności: cache strony, obraz LCP, fonty, odpinanie zasobów, cache obiektowy (jeśli dotyczy). Po każdym kroku zróbcie trzy pomiary laboratoryjne tej samej podstrony i zapiszcie medianę LCP, CLS i TBT. Google Search Central podkreśla, że do oceny w wyszukiwarce liczą się dane terenowe z raportu CrUX, więc równolegle obserwujcie raport Core Web Vitals w Search Console, który reaguje z opóźnieniem około 28 dni (szczegóły w dokumentacji Google Search Central).
Najprościej prowadzić to w arkuszu: jedna kolumna na krok, jedna na datę, trzy na metryki. Sprawdza się tu ten sam układ, który stosujemy w szablonie audytu treści w Arkuszach Google, tylko z innymi kolumnami. Jeśli do porównania zbieracie też czasy ładowania konkurencji własnym crawlerem, przeczytajcie wcześniej, co wolno przy scrapowaniu danych w Polsce.
Typowe wyniki na średnim hostingu współdzielonym: cache strony obniża LCP o 0,8–1,5 s, poprawka obrazu LCP o kolejne 0,3–0,8 s, fonty lokalne redukują CLS do zera przy tekstowym LCP. Odpinanie zasobów zwykle poprawia TBT i INP, ale wymaga najwięcej testów regresyjnych.
Kiedy jednak wybrać gotową wtyczkę
Pakiet all in one ma sens w trzech sytuacjach. Pierwsza: brak dostępu do plików motywu i do serwera, na przykład na hostingu zarządzanym z zablokowanym FTP. Druga: portfel kilkudziesięciu witryn prowadzonych przez jedną osobę, gdzie jednolity panel ważniejszy jest od optymalnego stosu. Trzecia: sklep WooCommerce z zaawansowanym cache fragmentów i wykluczeniami dla koszyka, gdzie ręczna konfiguracja zajmuje dni.
W takim wypadku wybierzcie jedną wtyczkę, wyłączcie w niej wszystko, co powiela hosting, i włączajcie moduły pojedynczo z pomiarem po każdym. Pełną konfigurację bazową WordPressa pod wyszukiwarki opisaliśmy w tekście o konfiguracji WordPressa dla SEO w 2026.
Najczęstsze błędy
- Dwa cache naraz: wtyczka i serwer, z różnym czasem ważności, co daje losowo nieświeże strony.
- Lazy loading na obrazie wyróżniającym, czyli obraz LCP wczytywany jako ostatni.
- Preload pięciu plików fontów, w tym kursywy, której nikt nie używa.
- Łączenie wszystkich skryptów w jeden plik, przez co zmiana jednej linii unieważnia cache całości.
- Pomiar na stronie głównej, gdy 90% ruchu organicznego wchodzi na wpisy.
FAQ: najczęstsze pytania
Czy WordPress bez wtyczki cache może przejść Core Web Vitals?
Tak, jeśli cache HTML działa na poziomie serwera (LiteSpeed, Nginx FastCGI, Varnish). Wtyczka jest potrzebna tylko wtedy, gdy hosting nie oferuje żadnej z tych warstw. Sama wydajność PHP bez cache rzadko schodzi poniżej 400 ms TTFB na hostingu współdzielonym, więc jakaś forma cache strony jest praktycznie obowiązkowa.
WebP czy AVIF dla obrazów w WordPressie?
WebP jest bezpiecznym wyborem: wsparcie w każdej aktualnej przeglądarce i szybkie generowanie na każdym serwerze. AVIF daje o 20–30% mniejsze pliki, ale wymaga Imagick z obsługą formatu i dłużej się generuje. Jeśli hosting ma Imagick w nowej wersji, AVIF jest lepszy; w innym wypadku zostańcie przy WebP.
Czy cache obiektowy Redis przyspieszy blog?
Dla anonimowego ruchu na blogu praktycznie nie, bo strony wychodzą z cache HTML i baza nie jest odpytywana. Redis pomaga przy zalogowanych użytkownikach, sklepie, forum i przy ciężkim panelu administracyjnym. Włączenie go bez potrzeby nie szkodzi, ale nie zmieni metryk CWV.
Jak sprawdzić, który element strony jest LCP?
W Chrome DevTools w zakładce Performance nagrajcie ładowanie strony i kliknijcie znacznik LCP na osi czasu; narzędzie podświetli element. Ten sam element pokazuje PageSpeed Insights w sekcji diagnostyki. Na wpisach jest to zwykle obraz wyróżniający, na stronach usług często nagłówek H1.
Po jakim czasie zmiany widać w Search Console?
Raport Core Web Vitals w Search Console opiera się na 28-dniowym oknie danych z CrUX, więc pełny efekt poprawek pojawia się po około miesiącu. Pomiary laboratoryjne (Lighthouse, WebPageTest) pokazują zmianę od razu i służą do kontroli po każdym kroku wdrożenia.