WordPress wolno się ładuje – diagnoza i naprawa wolnego WordPressa w 2026

Zanim cokolwiek zmienisz, zmierz stan wyjściowy. Bez tego nie będziesz wiedział, czy Twoje działania cokolwiek dają. Potrzebujesz trzech narzędzi i 10 minut.

PageSpeed Insights (pagespeed.web.dev) pokaże Ci Core Web Vitals z perspektywy Google. Zwróć uwagę na LCP (Largest Contentful Paint – powinno być poniżej 2,5 s), INP (Interaction to Next Paint – poniżej 200 ms) i CLS. Jeśli LCP przekracza 4 sekundy, problem jest poważny i Google już obniża Ci pozycje.

GTmetrix (gtmetrix.com) daje czytelny waterfall z każdego żądania HTTP. To tutaj zobaczysz, że np. jeden nieoptymalny obrazek zjada 3 sekundy albo że skrypt zewnętrznej czcionki blokuje render na 800 ms. Ustaw lokalizację testu na Londyn lub Frankfurt – będzie najbliżej polskich użytkowników.

Query Monitor to darmowa wtyczka diagnostyczna, bez której nie wyobrażam sobie pracy z WordPressem. Pokazuje liczbę zapytań SQL na stronie, ich czas wykonania, wolne hooki, pamięć zużytą przez wtyczki i skrypty wczytywane na froncie. Zainstaluj, wejdź na problematyczną podstronę zalogowany jako admin i przeanalizuj pasek na górze ekranu. Jeśli widzisz 300+ zapytań SQL lub czas generowania strony powyżej 1,5 s – masz winowajcę. Więcej o tym narzędziu znajdziesz w wpisie o profilowaniu wtyczek.

To numer jeden na liście i niestety najczęściej lekceważona przyczyna. Jeśli płacisz 10-15 zł miesięcznie za hosting typu "unlimited", prawdopodobnie dzielisz serwer z setką innych stron, a Twoje zasoby CPU są ograniczone do ułamka rdzenia.

Objawy: strona jest szybka, gdy testujesz ją sam, ale wolna wieczorem lub przy większym ruchu. W Query Monitor widzisz wysokie wartości "server time" przy każdym requeście. Czas odpowiedzi TTFB (Time to First Byte) przekracza 800 ms, a powinien być poniżej 400 ms.

Test: wyłącz wszystkie wtyczki i zmień motyw na Twenty Twenty-Four. Jeśli TTFB nadal wysokie – problem jest po stronie hostingu, nie Twojej strony.

Rozwiązanie: przejście na hosting SSD z LiteSpeed lub NGINX i dedykowanym CPU. Polecam CyberFolks{rel="noopener sponsored"} (pakiet Business z LiteSpeed) – różnica względem tanich hostingów jest natychmiastowa, TTFB zwykle spada z 900 ms do 200 ms. Nigdy nie wybieraj nazwa.pl ani home.pl – są drogie i powolne, słabsze od tańszej konkurencji. Więcej w artykule o najlepszych hostingach dla WordPressa.

PHP 8.3 jest średnio 20-30% szybszy od 7.4 i nawet 60% szybszy od 7.0. Mimo to połowa stron w internecie nadal działa na starych wersjach, bo administratorzy boją się ruszyć ustawienia w panelu.

Jak sprawdzić: zainstaluj wtyczkę Site Health Status (lub przejdź do Narzędzia, Kondycja witryny). W zakładce Informacje, w sekcji Serwer zobaczysz aktualną wersję PHP. Jeśli to 7.4 lub niższa – masz ciszy ostrzegawczy dzwon.

Jak naprawić: w panelu hostingu (cPanel, CloudPanel, DirectAdmin) jest zakładka "Wybór wersji PHP" lub "PHP Selector". Przełącz na 8.3 (lub 8.2, jeśli masz starszy motyw). Po zmianie natychmiast sprawdź, czy strona działa – w 95% przypadków wszystko jest OK, ale niektóre stare wtyczki (np. porzucone od 2020 roku) mogą rzucać błędy.

Limity PHP do zwiększenia razem z wersją: memory_limit 256M (minimum), max_execution_time 120, upload_max_filesize 64M. Bez tego duże strony będą wywalać błędy 500 przy cięższych akcjach. Jeśli po aktualizacji PHP zobaczysz błąd 500, przeczytaj nasz poradnik o błędzie 500 w WordPressie.

WordPress domyślnie generuje każdą stronę od nowa przy każdym wejściu. To oznacza kilkaset zapytań do bazy danych na jeden request. Cache zamienia to w jedno statyczne HTML i skraca czas ładowania nawet 10-krotnie.

Objawy braku cache: w Query Monitor widzisz 200-500 zapytań SQL na każdej podstronie. GTmetrix pokazuje TTFB powyżej 500 ms nawet przy pustym ruchu. Po kliknięciu w ten sam link dwa razy pod rząd ładuje się tak samo wolno.

Rekomendacja na 2026: jeśli hosting ma LiteSpeed – używaj LiteSpeed Cache (darmowy, najlepszy stosunek mocy do ceny). Jeśli nie – WP Rocket (~50 USD/rok, mniej konfiguracji). Unikaj W3 Total Cache w 2026, jest przestarzały. Szczegóły w przewodniku po WP Rocket oraz artykule o problemach z LiteSpeed Cache.

Częsty błąd: włączenie cache i puszczenie go bez konfiguracji. Musisz ustawić wykluczenia dla koszyka, logowania i kont klientów, inaczej wrzucisz userowi czyjeś dane w wersji statycznej. Dla sklepów WooCommerce to absolutna podstawa – poświęć 15 minut na ustawienie wyjątków.

Klient wrzuca zdjęcie bezpośrednio z iPhone (5 MB, 4032×3024 piksele), WordPress pokazuje je na stronie w rozmiarze 800×600. Przeglądarka i tak musi pobrać oryginał 5 MB, skalować w locie i narysować. Efekt: LCP 6 sekund, użytkownik dawno już wrócił do Google.

Jak to sprawdzić: w GTmetrix przewiń do zakładki Waterfall i posortuj po rozmiarze. Jeśli któryś obrazek waży więcej niż 200 KB – masz problem. Dobrze zoptymalizowany obrazek na stronie internetowej rzadko przekracza 100 KB.

Trzy kroki naprawy:
1. Zainstaluj ShortPixel lub Imagify i puść kompresję na istniejącej bibliotece mediów (tryb "Lossy" jest bezpieczny, różnice są niewidoczne dla oka)
2. Konwertuj do WebP – WordPress 6.5+ obsługuje to natywnie, ShortPixel robi automatycznie
3. Włącz lazy loading dla obrazków poniżej first fold (wtyczka cache zwykle ma tę opcję)

Dodatkowo – zdefiniuj rozmiary obrazków w motywie. Brakujące atrybuty width/height powodują CLS (Cumulative Layout Shift), które Google karze osobno. Więcej praktycznych wskazówek w poradniku o optymalizacji obrazków.

Nie liczy się ile masz wtyczek, tylko co one robią na froncie. Dwie ciężkie wtyczki (np. WPML + Elementor Pro + Slider Revolution) mogą spowolnić stronę bardziej niż 30 lekkich. Kluczowa jest liczba zapytań SQL, wagi JS/CSS i hooków na akcję wp_footer.

Narzędzie diagnostyczne: Query Monitor ma zakładkę "Queries by Component". Pokazuje, ile zapytań SQL generuje każda wtyczka. Jeśli widzisz, że "Yoast SEO Premium" robi 80 zapytań na stronie produktu – wiesz, gdzie szukać. Alternatywnie P3 Plugin Performance Profiler (starsze, ale działa).

Najwięksi winowajcy wydajności (z doświadczenia):
- Slider Revolution – wyłącz jeśli nie używasz sliderów
- WPBakery Page Builder – rozważ migrację na Gutenberg lub Bricks
- Social sharing plugins z ikonami z Twittera – każda ikona to osobny request
- Wtyczki od "related posts" robiące zapytania JOIN – zastąp ręcznym linkowaniem
- Visual Composer w starych wersjach

Procedura: wyłącz wszystkie wtyczki jedna po drugiej i mierz GTmetrix po każdym wyłączeniu. To brutalne, ale w 30 minut znajdziesz czarną owcę. Wyłączone na czas testu wtyczki nie kasują danych – spokojnie wrócisz do nich później. Sprawdź też nasz wpis o profilowaniu wtyczek.

Po dwóch latach działania tabela wp_options rośnie do 10-20 MB, a wp_posts ma 40 tysięcy rekordów zamiast 500, bo WordPress zapisuje rewizje każdego tekstu przy każdym kliknięciu "Zapisz". Efekt: każde zapytanie SELECT trwa dwa razy dłużej.

Szybki pomiar: w Query Monitor, na zakładce Database, zobaczysz czas generowania strony. Powyżej 500 ms przy zapytaniach – baza wymaga czyszczenia. W phpMyAdmin sprawdź rozmiar tabeli wp_options. Jeśli przekracza 5 MB – masz problem z autoloaded options.

Plan sprzątania (30 minut):
1. Wykonaj backup bazy przed czymkolwiek (obowiązkowe)
2. Zainstaluj WP-Optimize lub Advanced Database Cleaner
3. Usuń rewizje starsze niż 30 dni (zachowaj ostatnie 3 na wszelki wypadek)
4. Wyczyść transients (wygasłe i wszystkie nieaktywne)
5. Usuń spam komentarze i posty w koszu
6. Zoptymalizuj (OPTIMIZE TABLE) wszystkie tabele

Trwałe rozwiązanie: dodaj do wp-config.php linię `define('WP_POST_REVISIONS', 5);` – WordPress będzie trzymał maksymalnie 5 rewizji na post, nie setki. Pełny przewodnik w naszym artykule o optymalizacji bazy danych. Dla większych sklepów dodatkowo rozważ Redis Object Cache, który buforuje zapytania w RAM – szczegóły w osobnym wpisie.

Jeśli Twój serwer stoi w Warszawie, a użytkownik wchodzi z Wrocławia, każdy request to 200-300 ms latencji tam i z powrotem. Pomnóż to przez 80 plików na stronie i masz sekundy stracone na samej drodze. CDN rozwiązuje problem, serwując pliki z serwera najbliżej użytkownika.

Rozwiązanie dla 90% stron: Cloudflare darmowy plan. Zajmuje 15 minut na konfigurację (zmiana nameserverów w panelu domen), działa z każdym hostingiem, oferuje SSL, firewall i protokół HTTP/3. Średnia poprawa TTFB dla polskich stron to 30-50%.

Konfiguracja Cloudflare w 10 krokach:
1. Załóż konto na cloudflare.com
2. Dodaj domenę, Cloudflare zaimportuje istniejące rekordy DNS
3. Zmień nameservery u rejestratora na te od Cloudflare (propagacja 4-48 h)
4. Włącz tryb Flexible SSL (lub Full jeśli masz Let's Encrypt)
5. Ustaw Auto Minify dla JS, CSS, HTML
6. Włącz Brotli compression
7. Włącz Always Online
8. Page Rules: cache HTML (opcjonalnie dla prostych stron, NIE dla sklepów/logowania)
9. Wyłącz Rocket Loader (często łamie skrypty)
10. Sprawdź w GTmetrix czy nagłówek CF-Cache-Status pokazuje HIT

Uwaga na Google Fonts i zewnętrzne czcionki: każdy request do fonts.googleapis.com to dodatkowe 150-300 ms. Pobierz czcionki lokalnie (OMGF – Optimize My Google Fonts wtyczka robi to automatycznie) lub użyj font-display: swap. Dla Core Web Vitals to duża różnica – więcej w poradniku o Core Web Vitals.

Avada, Divi, Bridge, The7, Uncode – motywy wielofunkcyjne, które robią wszystko. Niestety "wszystko" oznacza, że ładują framework o wadze 2-3 MB JavaScriptu nawet na stronie "Kontakt", gdzie jest tylko formularz i mapa. Problem narasta z każdą aktualizacją, bo autorzy dokładają kolejne moduły.

Jak to poznasz: w GTmetrix pod zakładką Waterfall widzisz serię plików o nazwach typu "main.min.js", "animations.min.js", "fusion-builder.min.js", sumarycznie 1,5-3 MB samego JavaScriptu. Dla porównania – dobry motyw (GeneratePress, Kadence, Astra) ładuje się z łącznie 40-80 KB JS.

Trzy opcje:
1. Zostań przy ciężkim motywie i optymalizuj – wyłącz nieużywane moduły w panelu motywu (np. Avada ma opcję "Disable Fusion Builder on posts"), użyj Asset CleanUp do wyłączania CSS/JS na konkretnych stronach
2. Migracja na lekki motyw – GeneratePress Premium (59 USD/rok) lub Kadence (129 USD/rok) ładują się natychmiast. Migracja zabiera 20-40 godzin dla średniej strony firmowej
3. Custom theme od agencji – najdroższe, ale daje największą kontrolę. My w KC Mobile robimy zoptymalizowane custom themes na bazie Gutenberg – projekt zaczyna się od 8 000 zł

Przed decyzją: policz, ile kosztuje Cię sekunda wolniejszego ładowania. Google mówi, że konwersja spada o 7% na każde 100 ms opóźnienia – dla sklepu z obrotem 30 tys. zł/mies. to 2 100 zł miesięcznie. Migracja za 10 tys. zł zwraca się w 5 miesięcy. Jeśli nie masz czasu bawić się sam, sprawdź naszą ofertę stron internetowych albo zamów audyt cyfrowy.

Mam dla Ciebie checklistę, którą stosuję u klientów. Przejdź po kolei, nie próbuj wszystkiego naraz, bo nie będziesz wiedział, co dało efekt.

Minuta 0-10: pomiar wyjściowy. Uruchom PageSpeed Insights i GTmetrix na stronie głównej i 2-3 podstronach. Zapisz wyniki (zrzut ekranu). Notuj LCP, TTFB, Total Page Size, liczbę requestów.

Minuta 10-25: diagnostyka Query Monitor. Zainstaluj wtyczkę, wejdź na wolną podstronę zalogowany jako admin, sprawdź czas generowania strony, liczbę zapytań SQL, wtyczkę z największym zużyciem pamięci.

Minuta 25-40: hosting i PHP. Sprawdź wersję PHP (ma być 8.2+), memory_limit (256M+). Jeśli siedzisz na nazwa.pl, home.pl lub innym wolnym hostingu – zaplanuj migrację, to inwestycja, która się zwróci w tydzień.

Minuta 40-55: cache. Zainstaluj LiteSpeed Cache (jeśli hosting ma LiteSpeed) lub WP Rocket. Włącz minimalną konfigurację – cache stron, minify JS/CSS, lazy load obrazków. Dla sklepu ustaw wykluczenia na koszyk, checkout, konto.

Minuta 55-70: obrazki. ShortPixel Free (100 obrazków/miesiąc darmowe) – puść kompresję lossy na całej bibliotece. Konwersja do WebP automatycznie.

Minuta 70-85: baza danych. WP-Optimize – usuń rewizje (zostaw 5 ostatnich), spam, transients, OPTIMIZE TABLE. Backup przedtem!

Minuta 85-90: pomiar końcowy. PageSpeed Insights, GTmetrix – porównaj z pomiarem wyjściowym. Spodziewaj się poprawy 30-60% na standardowej stronie.

Jeśli po tych krokach strona nadal ładuje się wolniej niż 3 sekundy – masz głębszy problem (zły motyw, konflikt wtyczek, wąskie gardło na hostingu). Wtedy warto sięgnąć po specjalistę – umów konsultację w KC Mobile, zrobimy audyt za 0 zł i powiemy konkretnie, co naprawić.

Są sytuacje, kiedy dalsze DIY tylko pogarsza sprawę. Rozpoznaj je wcześnie:

Sygnał 1 – po 3 godzinach prób wynik jest gorszy niż na starcie. Coś zepsułeś w konfiguracji cache albo wyłączyłeś wtyczkę, która była potrzebna. Zrób rollback z backupu (masz backup, prawda?) i zadzwoń po pomoc.

Sygnał 2 – LCP powyżej 5 sekund mimo LiteSpeed + CDN + optymalizacji. To znak, że problem jest fundamentalny – zły motyw, konflikt architektury lub hosting, który kłamie w specyfikacji. Sam tego nie wyczujesz bez narzędzi profilujących.

Sygnał 3 – sklep WooCommerce powyżej 500 produktów z wolnym panelem adm. Panel admina często cierpi na wolne zapytania do wp_postmeta. To wymaga indeksów na bazie i czasem Redis Object Cache – rzeczy, które wymagają dostępu SSH i znajomości MySQL.

Sygnał 4 – Google Search Console zgłasza Core Web Vitals "Poor" na 70%+ podstron. Jeśli tracisz ruch organiczny z tego powodu, każdy dzień zwłoki to stracone leady. Profesjonalny audyt kosztuje 500-1500 zł i zwraca się w miesiąc.

Co oferuje KC Mobile: audyt wydajności WordPress (500-1000 zł, raport 20 stron z konkretnymi akcjami), kompletną optymalizację (1500-4000 zł, wdrożenie wszystkich rekomendacji) lub migrację na nowy hosting wraz z optymalizacją (od 2500 zł). Pomogliśmy kilkudziesięciu firmom wyjść z wolnej strony, średnia poprawa LCP to 55%. Jeśli czujesz, że to już nie Twoja liga – napisz do nas albo sprawdź pozycjonowanie SEO, jeśli problem wydajności blokuje Ci widoczność w Google.