Twoja strona na WordPressie ładuje się wolno? Wiele osób od razu myśli: „potrzebuję lepszego hostingu”. To bywa prawda, ale równie często hosting jest niewinny, a bottleneck siedzi w motywie, wtyczkach, mediach albo w braku sensownego cache.
Ten tekst jest checklistą diagnostyczną, nie katalogiem wtyczek „do przyspieszenia”. Zanim cokolwiek zainstalujesz, zmierz. Potem zmień jedną rzecz. Potem zmierz ponownie.
Mit: nowy hosting rozwiąże wszystko
Zmiana serwera może poprawić TTFB, jeśli stary plan dusił PHP albo MySQL. Jeśli jednak homepage ciągnie nieoptymalne zasoby, droższy VPS tylko drożej serwuje ten sam bałagan.
Najczęstsze przyczyny, które widzimy na audytach:
- Zbyt wiele wtyczek generujących zapytania do bazy przy każdym requestcie.
- Obrazy bez kompresji, bez nowoczesnych formatów i bez zarezerwowanych wymiarów (CLS).
- Brak page cache albo cache skonfigurowany tak, że omija zalogowanych i koszyk, a front i tak leci „na żywca”.
- Zewnętrzne skrypty: czcionki, tag manager, chaty, pixele reklamowe ładowane synchronicznie w
<head>. - Page builder, który buduje DOM z setek wrapperów i inline CSS na każdą sekcję.
W jednym sklepie WooCommerce pod Black Friday TTFB wyglądał przyzwoicie na hostingu, a LCP padał przez hero slider z pięcioma pełnymi JPEG-ami i carousel JS. Wymiana hostingu nic by nie dała; pomogło wycięcie slidera i jeden AVIF z fetchpriority="high".
Najpierw zmierz, potem ruszaj
Bez baseline’u każda optymalizacja to zgadywanie. Minimum:
- PageSpeed Insights albo WebPageTest na URL produkcyjnym, profil mobile.
- Odczyt TTFB osobno (curl z
-walbo zakładka Timing w DevTools). - Porównanie zalogowany vs wylogowany, jeśli masz page cache.
- Query Monitor na stagingu albo krótko na produkcji poza szczytem - liczba zapytań SQL i wolne hooki.
Patrz na LCP, INP i CLS osobno. LCP zwykle wskazuje media lub wolny HTML. INP - główny wątek zablokowany skryptami. CLS - brak wymiarów, banery wjeżdżające po hydracji. Inna klasa problemu, inne lekarstwo.
Jeśli chcesz iść głębiej w media i critical CSS, zobacz też przewodnik po przyspieszaniu WordPressa.
Ogranicz zapytania do bazy danych
Niektóre motywy i wtyczki generują zbędne zapytania. Cache wyników w object cache (Redis/Memcached) albo przynajmniej w transientach odciąża MySQL:
function get_cached_posts() {
$cached_posts = wp_cache_get( 'my_cached_posts' );
if ( false === $cached_posts ) {
$query = new WP_Query( [
'posts_per_page' => 5,
'post_status' => 'publish',
'no_found_rows' => true,
] );
$cached_posts = $query->posts;
wp_cache_set( 'my_cached_posts', $cached_posts, '', HOUR_IN_SECONDS );
}
return $cached_posts;
}no_found_rows pomija SQL_CALC_FOUND_ROWS, gdy nie paginujesz. Na listingu kategorii z ciężkim meta_query różnica bywa zauważalna.
Typowy antywzorzec: pętla po produktach, a w środku kolejne get_post_meta i WP_Query na related. WordPress cache’uje meta przy standardowym query, ale related query odpala się N razy. Lepiej zebrać ID i zrobić jedno zapytanie, albo użyć object cache na fragment HTML.
Obrazy: waga, format, priorytet
Duże, nieprzycięte uploady to klasyczny powód wolnego LCP. Sam Smush nie wystarczy, jeśli motyw serwuje pełny rozmiar w miejscach, gdzie wystarczy 800 px szerokości.
add_filter( 'wp_generate_attachment_metadata', function ( $metadata ) {
if ( function_exists( 'wp_smushit' ) ) {
wp_smushit( $metadata['file'] );
}
return $metadata;
} );W 2026 rozsądny baseline to AVIF/WebP z fallbackiem, srcset/sizes zgodne z layoutem oraz loading="lazy" poza LCP. Element LCP dostaje fetchpriority="high" i nie powinien być lazy.
Sprawdź też CDN: jeśli origin w PL, a większość ruchu siedzi w DE/NO, latency na statykach widać w TTFB assetów, nawet gdy HTML jest szybki.
Cache: page, object, opcode - trzy różne rzeczy
Ludzie mówią „włączyłem cache”, mając na myśli jedną wtyczkę page cache. Tymczasem:
- Opcode cache (OPcache) przyspiesza PHP na serwerze. To podstawa hostingu, nie wtyczka.
- Object cache trzyma wyniki zapytań i transienty w Redis/Memcached. Pomaga dynamicznym widokom, koszykowi, dashboardowi.
- Page cache serwuje gotowy HTML anonimowym użytkownikom. Największy zysk na blogu i landingach.
Nie masz jeszcze wtyczki page cache? Same ob_gzhandler to tylko kompresja odpowiedzi, nie pełny cache strony:
function start_output_buffering() {
if ( ! is_admin() ) {
ob_start( 'ob_gzhandler' );
}
}
add_action( 'init', 'start_output_buffering' );Na WooCommerce page cache musi omijać koszyk, checkout i konto. Złe reguły powodują, że klient widzi cudzy koszyk albo „pusty” koszyk po dodaniu produktu - to już nie performance, to incydent.
Wtyczki: mniej znaczy szybciej, ale mierz
Lista „wyłącz połowę wtyczek” jest popularna i czasem prawdziwa. Lepiej jednak wyłączać po jednej i mierzyć Query Monitor / TTFB. Czasem winowajcą jest jedna integracja ERP odpalająca remote HTTP w init, a nie „zbyt wiele wtyczek” jako abstrakcja.
Szukaj wtyczek, które:
- ładują CSS/JS globalnie zamiast tylko na potrzebnych ekranach,
- odpalają cron co minutę bez sensu,
- piszą logi na dysk przy każdym requeście,
- wołają zewnętrzne API synchronicznie przy renderze.
Autoload options w wp_options to osobny temat: napuchnięty autoload potrafi dodać dziesiątki milisekund do każdego requestu. Warto sprawdzić rozmiar autoload osobnym zapytaniem SQL na stagingu.
Core Web Vitals i SEO - związek praktyczny
Wolna strona boli UX, ale też zbiera sygnały z CrUX. Jeśli LCP w polu jest słabe miesiącami, poprawki „na laboratorium” bez poprawy mediów i TTFB nie przeniosą się do raportu Search Console.
Praktyczna kolejność napraw, którą stosujemy przy optymalizacji szybkości:
- Zabić oczywiste LCP (hero, fonty, blocking CSS).
- Ustabilizować TTFB (PHP workers, object cache, wolne query).
- Oczyścić third-party JS pod INP.
- Dopiero wtedy fine-tuning critical CSS i preloadów.
Fonty, third-party i główny wątek
Nawet przy dobrym TTFB strona może „wisić” na INP, gdy główny wątek dusi się skryptami. Klasyczny zestaw: Google Fonts synchronicznie, dwa tag managery, chat, heatmapa, pixel retargetingu. Każdy z nich konkuruje o CPU na słabym Androidzie.
Praktyka: self-hostuj podzbiór fontów (wagi, których naprawdę używasz), ładuj GTM defer/po interakcji tam gdzie biznes pozwala, a chat odpalaj po idle albo po geście. Nie optymalizuj „na laboratorium” wyłączając wszystko, czego marketing nie odpuści - zmierz wpływ każdego skryptu osobno w Coverage i w Performance panelu.
Preload LCP image pomaga tylko wtedy, gdy URL w preload to ten sam plik, który trafia do <img>. Preload złego wariantu z srcset marnuje bajty i nic nie daje LCP.
Hosting: kiedy jednak zmienić plan
Są sygnały, że problem siedzi po stronie serwera, nie motywu:
- TTFB powyżej sekundy na pustym motywie twenty-* z wyłączonymi wtyczkami.
- PHP workers wyczerpane w panelu hosta przy umiarkowanym ruchu.
- Wolne zapytania MySQL na prostych
SELECTbez meta_query. - Brak OPcache albo object cache przy dynamicznym sklepie.
Wtedy migracja ma sens. Ale najpierw zrób test „pustego” WordPressa na tym samym planie. Jeśli twenty-theme leci szybko, a produkcja nie - wracasz do aplikacji. Jeśli oba są wolne - rozmawiasz z hostem albo zmieniasz infrastrukturę.
Na polskim rynku często widzimy LiteSpeed + LSCache albo Nginx + FastCGI cache. Oba działają, byle reguły wykluczeń WooCommerce były poprawne. Źle skonfigurowany cache daje spektakularne liczby w Lighthouse i koszmar w supportcie zamówień.
Po migracji hosta powtórz te same URL-e co w baseline. Sam fakt „przenieśliśmy na SSD” nic nie mówi, jeśli LCP nadal zabija ten sam hero. Zachowaj HAR albo WebPageTest before/after pod tym samym profilem mobilnym.
Checklist na jedno popołudnie
- Zmierz mobile LCP/TTFB na homepage i jednym URL produktowym.
- Policz wtyczki i wypisz te ładujące assety globalnie.
- Sprawdź wagę hero i czy ma wymiary w HTML.
- Potwierdź, że page cache trafia anonimów (nagłówki HIT/MISS).
- Na stagingu włącz Query Monitor i zrób zrzut najcięższych zapytań.
- Sprawdź listę skryptów third-party i fontów w Network.
- Porównaj TTFB pustego motywu vs produkcji na tym samym hoście.
- Wprowadź jedną zmianę, zmierz, zapisz wynik.
Podsumowanie
Jeśli strona jest wolna, nie zakładaj od razu, że to wina hostingu. Sprawdź wtyczki, media, warstwy cache i realny TTFB. Małe, mierzone zmiany w kodzie i konfiguracji zwykle dają więcej niż kolejna „wtyczka przyspieszająca” dołożona do już ciężkiego stosu. Zapisuj wyniki pomiarów w ticketcie albo notatce wdrożeniowej - bez liczb każda kolejna „optymalizacja” zaczyna się od zera. Nawet prosty zapis TTFB i LCP przed i po jednej zmianie wystarczy, żeby uniknąć regresji przy kolejnym deployu wtyczek.
Gdy potrzebujesz audytu na produkcji (CrUX, LiteSpeed/Redis, page builder, WooCommerce), napisz przez formularz kontaktowy. Przygotuj URL, hosting i listę wtyczek - tego wystarczy, żeby zacząć od pomiaru zamiast od zgadywania.
