Jak przyspieszyć stronę WordPress — 7 metod od podstaw po zaawansowane

Przy onboardingu nowego klienta zawsze zaczynamy od jednego pytania: „co chcecie poprawić?”. I zawsze pada odpowiedź: „stronę, jest wolna”. Problem w tym, że „wolna” to 10 różnych rzeczy. TTFB 1.2 s od hostingu, LCP 4 s od nieprzeoptymalizowanego hero, INP 500 ms od ciężkiego edytora WYSIWYG — każde wymaga innej interwencji.

Poniżej — proces, który stosujemy, od diagnozy do konkretnego roadmapu. Bez uniwersalnej listy „10 trików”. W prawdziwej optymalizacji 80% efektu daje 2–3 naprawy. Reszta to szlif.

Zanim cokolwiek zmienisz — zmierz

Najczęstszy błąd początkujących: „zainstaluję WP Rocket i zobaczę”. Instalujesz, wyłączasz cache konkurencyjny, coś się psuje, panikujesz, wyłączasz WP Rocket, problem zostaje. Niepotrzebna próba, bo nigdy nie wiedziałeś jaki był punkt odniesienia.

Co mierzymy, zawsze w tej kolejności:

1. TTFB (Time to First Byte) z WebPageTest — pokazuje, czy problem to hosting/PHP/baza, czy front. Jeśli TTFB > 600 ms, nie ma sensu optymalizować frontu — zaczynasz od backendu.
2. LCP, INP, CLS z PageSpeed Insights, test Mobile, throttled. Desktop zwykle wygląda OK, mobile odkrywa prawdę.
3. Rzeczywisty waterfall (DevTools → Network, Slow 4G + 4× CPU). Szukamy: render-blocking CSS, duże obrazy bez width/height, ciężkie JS wtyczek, brak HTTP/2 multiplexing.
4. PHP-level profiling przez Query Monitor (tylko w środowisku developerskim) lub New Relic — ile zapytań do bazy na jedno żądanie, ile zajmuje renderowanie motywu.

Dopiero z tymi 4 liczbami wiemy, w co uderzać.

Pułapka numer jeden: autoload w wp_options

Częsta przyczyna wolnego admin-panelu i wolnego TTFB nawet przy dobrym hostingu: tabela wp_options z autoload='yes' dla wartości o łącznym rozmiarze > 1–2 MB. Każdy request WordPressa ładuje WSZYSTKIE autoload-options do pamięci. Trzy lata nieaktualizowanej wtyczki SEO, która trzyma cache słów kluczowych w options = 500 MB wchodzi do pamięci przy każdym wp-admin view.

Check w 1 komendzie WP-CLI:

wp db query "SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload='yes';"

Jeśli > 1 MB — masz problem. Typowe winowajcy: _transient_* po dezaktywowanych wtyczkach, YITH WooCommerce extensions, stare Revolution Slider sliders.

Fix:

wp option delete _transient_xxx
wp db query "UPDATE wp_options SET autoload='no' WHERE option_name LIKE '_site_transient_%';"

U jednego z naszych klientów (sklep z 8000 produktami) dropliśmy autoload z 4.2 MB do 300 KB — TTFB z 1.3 s do 380 ms. Bez dotykania hostingu.

Jeśli w trakcie diagnozy natrafisz na fatalne błędy PHP albo biały ekran śmierci — najpierw rozwiąż te: osobny artykuł o diagnostyce błędu 500 i białego ekranu WordPress pokazuje typowy przepływ pracy.

Wybór hostingu — to nie marketing

Nie chodzi o „managed vs shared”. Chodzi o cztery konkretne cechy:

• PHP 8.2+, idealnie 8.3 z OPcache (sprawdź php -v i w wp-admin → Narzędzia → Informacje o stronie).
• Serwer HTTP z HTTP/2 lub HTTP/3. Starego Apache2 bez mod_http2 w 2026 nie tolerujemy — LiteSpeed, nginx albo nowszy Apache.
• Object cache — Redis lub Memcached. W WordPressie wp_cache_* domyślnie jest in-process, żadne cache między requestami. Object cache dodaje właśnie ten brakujący warstwę.
• Lokalizacja. Serwer w Warszawie vs. Frankfurcie vs. USA to dla polskich userów różnica 20 / 50 / 150 ms na każdym requeście.

Z polskich hostingów sensownie kalibrują się zenbox (VPS), mydevil (shared z Redis), SeoHost.pl (managed WP). Czego nie polecamy nowym projektom: home.pl, nazwa.pl w podstawowych planach — słaby PHP/brak Redis.

Obrazy — najbardziej przepłacony problem

„Optymalizuj obrazy do WebP” pisze każdy poradnik. W praktyce od WP 6.5 generowanie WebP dla miniatur dzieje się natywnie przy uploadzie. Nie potrzebujesz Imagify’a dla nowego zdjęcia — potrzebujesz go dla 3000 starych PNG-ów w bibliotece mediów.

Co robimy faktycznie:

• Wymuszone rozmiary. Osoba tworząca treść często wkleja obraz 4096 px szeroki do kafelka 320 px. Fix: w functions.php albo mu-plugin:

add_filter('big_image_size_threshold', fn() => 2048);
add_image_size('hero-mobile', 768, 432, true);

• AVIF dla hero (jeszcze lepiej skompresowany niż WebP). ShortPixel Adaptive Images robi to transparentnie, Cloudflare Images też.
• Lazy loading — natywne od WP 5.5. Nie potrzebujesz wtyczki. Sprawdź tylko <img decoding="async" loading="lazy"> w wygenerowanym HTML.
• Preload hero — <link rel="preload" as="image" href="/hero.webp"> w <head>. W motywach custom dodajemy ręcznie; w motywach klasycznych przez hooky wp_head.

Cache — trzy warstwy, nie jedna

WP Rocket to tylko jedna warstwa (output cache po PHP). Szybka strona ma ich trzy:

1. Object cache (Redis/Memcached) — warstwa PHP/baza. Redukuje zapytania SQL. Aktywacja: wp plugin install redis-cache --activate, dodaj do wp-config.php define('WP_REDIS_HOST', '127.0.0.1'); i wp redis enable.
2. Page cache (WP Rocket, LiteSpeed Cache, W3 Total Cache) — gotowy HTML cache’owany na dysku. Invalidation po publikacji wpisu.
3. Edge cache (Cloudflare APO, BunnyCDN, własny Worker). HTML cache na poziomie CDN, 20–50 ms dla userów zamiast 300 ms z origin.

Ostatnia warstwa zmienia wszystko. Dla strony produktowej Devance mamy własny Cloudflare Worker, który cache’uje HTML na edge’u (10 min TTL) z bypass dla ścieżek dynamicznych (/konto, /zamowienie). Efekt: pierwszego requestu użytkownik z Warszawy dostaje w ~40 ms.

Przy WP podobny setup robimy z Cloudflare APO (tylko dla domen w pełni na Cloudflare) albo własnym workerem przed origin.

Reduce, reduce, reduce

Każda aktywna wtyczka to dodatkowy kod do załadowania. Każdy element menu nawigacyjnego to dodatkowe zapytanie. Każdy widget to mały koszt.

Przyjrzeć się warto:

• Heartbeat API — WordPress co 15 s wysyła POST do /wp-admin/admin-ajax.php. Przy otwartym panelu admin = request co 15 s, każdy ~150 ms PHP. Wtyczka Heartbeat Control zmienia to na 60+ s albo wyłącza na froncie.
• WP-Cron. Domyślnie odpala się przy każdym wejściu na stronę (wp-cron.php przez WP-Cron pseudo-scheduler). Na produkcji wyłącz przez define('DISABLE_WP_CRON', true); w wp-config.php i skonfiguruj realny cron systemowy (*/5 * * * * wget -q -O - https://domain.pl/wp-cron.php).
• Revisions. define('WP_POST_REVISIONS', 5); w wp-config.php. Domyślnie WP trzyma wszystkie rewizje do końca świata. U klienta z 500 wpisami × 20 rewizji każdy = 10 000 dodatkowych rzędów w wp_posts.
• Autosave interval. Domyślnie 60 s. Dla zespołu pisarskiego OK, dla blogera solo — define('AUTOSAVE_INTERVAL', 300); (5 min).

Motyw — czasem trzeba boleśnie zmienić

Jeśli masz motyw z puli ThemeForest sprzed 2020 (tysiąc opcji, jquery-migrate, własny Bootstrap 3, 40 shortcodów) — nie zmusisz go do Core Web Vitals. Różnica między ciężkim motywem a nowoczesnym block-themem (Twenty Twenty-Four, Ollie, lekki Kadence) bywa 2 sekundy LCP przy tym samym contencie.

Decyzja trudna, bo wymaga migracji, ale u klientów, którzy poszli na szablon blokowy + ACF, typowy spadek LCP: z 3.5 s do 1.4 s. Jednorazowa inwestycja, długoterminowy zysk.

Szczegółowo o Gutenbergu vs Elementorze: osobny artykuł.

Baza danych — raz na kwartał

WP-Optimize albo WP-CLI:

wp transient delete --all
wp cache flush
wp db optimize

Większy porządek (przy sklepach): archiwacja starych logów pluginów, cleanup porzuconych koszyków w WooCommerce (wp wc tool run clear_expired_sessions).

Pomiar po zmianach — i monitoring od realnych użytkowników

PageSpeed Insights daje wyniki laboratoryjne (z kontrolowanego środowiska) — dobre na start, ale nie pokazują, jak stronę odbierają realni odwiedzający. Po optymalizacji podepnij pomiar od użytkowników (tzw. RUM, Real User Monitoring): Vercel Analytics, własny endpoint z biblioteką web-vitals albo sitespeed.io z własnymi testami syntetycznymi. CrUX (Chrome User Experience Report) zbiera dane od realnych użytkowników Chrome — widać je w PageSpeed jako „Field data” (dane z pola).

Typowy cel dla stron firmowych: LCP < 2,5 s na 75. percentylu mobile. Nie średnia — 75. percentyl. Średnia może być świetna, podczas gdy 25% odwiedzających odczuwa katastrofę.

Jeśli Twoja strona ma PageSpeed mobile < 50 i nie wiesz od czego zacząć — w darmowym audycie pokazujemy konkretne 3 rzeczy, które najbardziej wpłyną na Twoje metryki. Bez „zainstaluj cache” zamkniętych oczu.