Dlaczego WordPress jest wolny mimo WP Rocket i Perfmatters?

Zainstalowałeś WP Rocket. Potem dołożyłeś Perfmatters, żeby wyłączyć zbędne skrypty. Strona nadal ładuje się kilka sekund, a test PageSpeed Insights pokazuje czerwone wyniki. Znajome? To jeden z najczęstszych scenariuszy, z jakimi się spotykamy przy przeglądach stron klientów. Właściciel firmy zrobił wszystko zgodnie z poradnikami z internetu, kupił dobrą wtyczkę cache, a strona wciąż jest wolna. Wtedy pojawia się pokusa, żeby dołożyć kolejną wtyczkę – może jakiś dodatkowy optymalizator obrazów, może kolejny plugin do “przyspieszania”. W praktyce to rzadko pomaga. Czasem wręcz szkodzi, bo każda dodatkowa wtyczka to kolejny plik do wczytania i kolejne zapytanie do bazy danych. Zanim dołożysz coś nowego, warto zrozumieć, dlaczego WordPress jest wolny mimo cache – bo przyczyna prawie zawsze leży gdzie indziej niż w samej wtyczce.

Wtyczka cache nie rozwiązuje każdego problemu z szybkością

WP Rocket, Perfmatters, WP Super Cache czy podobne narzędzia robią jedną konkretną rzecz: zapisują gotową, wygenerowaną wersję strony jako statyczny plik HTML, żeby WordPress nie musiał za każdym razem od nowa odpytywać bazy danych i renderować szablonu. To realnie działa – dla strony, która ładuje się wolno tylko dlatego, że każde odwiedziny uruchamiają cały silnik PHP i bazę danych od zera. Problem w tym, że to tylko jeden z wielu możliwych powodów, dla których WordPress wolno się ładuje mimo cache. Cache przyspiesza dostarczanie gotowej strony. Nie naprawia wolnego hostingu. Nie zmniejszy wagi zdjęcia, które ma kilka megabajtów. Nie usunie skryptu czatu, który ładuje się z zewnętrznego serwera i blokuje renderowanie strony. Nie posprząta bazy danych zapchanej rewizjami wpisów sprzed lat.

To trochę jak z autem – możesz wymienić opony na lepsze, ale jeśli silnik ledwo ciągnie, auto i tak nie pojedzie szybciej niż pozwala mu na to reszta mechanizmu. Wtyczka cache to jeden element układanki, nie cała układanka. Kiedy WP Rocket nie pomaga, to zwykle znak, że wąskie gardło znajduje się poza obszarem, na który cache ma wpływ.

Warto też pamiętać, że sama obecność wtyczki cache nie oznacza, że jest poprawnie skonfigurowana. Wiele instalacji WP Rocket działa na ustawieniach domyślnych, bez włączonej minifikacji, bez lazy loadingu obrazów, bez optymalizacji kolejności ładowania skryptów. To już nie jest kwestia dokładania kolejnych narzędzi, tylko dokładnego przejrzenia tego, co już jest zainstalowane.

Jak sprawdzić, co faktycznie spowalnia stronę

Zanim zaczniesz cokolwiek zmieniać, potrzebujesz diagnozy. Zgadywanie kosztuje czas i często prowadzi do instalowania kolejnych wtyczek, które niczego nie naprawiają. Diagnostyka szybkości WordPress zaczyna się od kilku darmowych narzędzi, które pokazują, gdzie dokładnie strona traci czas.

PageSpeed Insights i Core Web Vitals

Pierwszym krokiem jest pagespeed.web.dev. To narzędzie od Google pokazuje wyniki Core Web Vitals WordPress osobno dla urządzeń mobilnych i desktopowych, co jest istotne – strona może działać w porządku na komputerze i być bardzo wolna na telefonie, bo tam liczy się każdy megabajt transferu.

Trzy wskaźniki, na które warto patrzeć:

• LCP (Largest Contentful Paint) – czas do wyświetlenia największego widocznego elementu strony, najczęściej zdjęcia w nagłówku. Dobry wynik to poniżej 2,5 sekundy.
• CLS (Cumulative Layout Shift) – stabilność układu podczas ładowania. Jeśli elementy “skaczą” po ekranie, gdy strona się dogrywa, ten wskaźnik rośnie.
• INP (Interaction to Next Paint) – jak szybko strona reaguje na kliknięcie czy dotknięcie ekranu.

PageSpeed Insights nie tylko podaje liczby – w sekcji diagnostyki pokazuje konkretne przyczyny, na przykład które skrypty blokują renderowanie albo które obrazy są za duże. To jest punkt startowy, nie wyrocznia. Wynik zależy też od tego, jaki serwer w danym momencie testuje Google, więc warto sprawdzić stronę kilka razy.

Zakładka Query Monitor i czas odpowiedzi serwera

Drugie, mniej znane, ale bardzo przydatne narzędzie to wtyczka Query Monitor. W przeciwieństwie do PageSpeed Insights, która patrzy na stronę z perspektywy przeglądarki, Query Monitor pokazuje, co dzieje się po stronie serwera – ile zapytań do bazy danych wykonuje dana strona, które wtyczki je generują i ile czasu to zajmuje. To narzędzie warto zainstalować tymczasowo, sprawdzić wynik i potem wyłączyć, żeby samo nie obciążało strony.

Warto też zwrócić uwagę na wskaźnik TTFB (Time To First Byte) – czas, jaki serwer potrzebuje, żeby w ogóle zacząć wysyłać odpowiedź. Jeśli TTFB przekracza pół sekundy, cache po stronie WordPressa niewiele pomoże, bo problem leży niżej, w samym serwerze.

Hosting współdzielony jako wąskie gardło

To jest przyczyna, którą najczęściej znajdujemy przy przeglądach stron, a jednocześnie najrzadziej ktoś ją podejrzewa w pierwszej kolejności. Hosting współdzielony (shared hosting) oznacza, że wiele stron różnych właścicieli dzieli te same zasoby serwera – moc procesora, pamięć RAM, limity zapytań. Jeśli inna strona na tym samym serwerze akurat generuje duży ruch albo ma błąd, który zjada zasoby, Twoja strona zwalnia razem z nią, mimo że Ty nic nie zmieniłeś. Tanie plany hostingowe – te za kilkanaście złotych miesięcznie – niemal zawsze opierają się na takim współdzielonym modelu. Dla wizytówki z małym ruchem to często wystarczające rozwiązanie. Dla strony firmowej, która ma płatną kampanię reklamową, sklep internetowy albo rosnący ruch organiczny, taki hosting staje się prędzej czy później limitem, którego żadna wtyczka nie ominie.

Jak to sprawdzić bez specjalistycznej wiedzy? Wspomniany wcześniej TTFB jest dobrym wskaźnikiem – jeśli jest wysoki niezależnie od tego, którą podstronę testujesz, i niezależnie od pory dnia, to sygnał, że problem leży w samym serwerze, a nie w konfiguracji WordPressa. Drugi sygnał to panel hostingu – jeśli dostawca pokazuje limity zasobów (CPU, liczba procesów) i widzisz, że regularnie są bliskie maksimum, to potwierdzenie.

Rozwiązaniem nie zawsze musi być drogi serwer dedykowany. Często wystarczy przejście na hosting zarządzany pod WordPressa (managed WordPress hosting) albo VPS z odpowiednią konfiguracją. Kluczowe jest to, żeby zasoby serwera nie były dzielone w sposób, który uzależnia szybkość Twojej strony od tego, co robią zupełnie obce witryny.

Zapytania do bazy danych i zbędne wtyczki

WordPress przy każdym wczytaniu strony (jeśli nie ma jej w cache) wykonuje dziesiątki, a czasem setki zapytań do bazy danych – pobiera treść wpisu, ustawienia motywu, dane wtyczek, menu, widgety. Im więcej aktywnych wtyczek, tym więcej dodatkowych zapytań. Niektóre wtyczki są napisane dobrze i obciążają bazę minimalnie. Inne – szczególnie te przestarzałe albo rzadko aktualizowane – potrafią generować dziesiątki zbędnych zapytań przy każdym odświeżeniu strony.

Drugi problem to sama wielkość bazy danych. WordPress domyślnie zapisuje rewizje każdego wpisu – czyli historię wszystkich wersji tekstu, które kiedykolwiek zapisałeś jako szkic. Po kilku latach prowadzenia bloga baza potrafi mieć tysiące niepotrzebnych rewizji, wpisów w koszu i starych transientów (tymczasowych danych, które wtyczki zapisują, ale rzadko porządnie po sobie sprzątają). Taka rozdęta baza spowalnia każde zapytanie, nawet te najprostsze.

Co warto sprawdzić w praktyce:

• Ile masz aktywnych wtyczek i czy każda z nich jest faktycznie potrzebna – w wielu instalacjach, które przeglądamy, połowa wtyczek to pozostałości po dawno zamkniętych testach albo funkcjach, z których nikt już nie korzysta.
• Czy baza danych była kiedykolwiek czyszczona z rewizji, spamu w komentarzach i wygasłych transientów.
• Czy wtyczki do formularzy, statystyk albo popupów nie działają jednocześnie na każdej podstronie, nawet tam, gdzie nie są potrzebne.

Uporządkowanie tej warstwy często daje większy skok wydajności niż jakakolwiek zmiana ustawień w WP Rocket, bo eliminuje pracę, którą serwer musi wykonać jeszcze zanim cache w ogóle wejdzie do gry.

Obrazy i zasoby, których cache nie skompresuje

Cache przechowuje gotową stronę, ale nie zmniejsza wagi plików, z których ta strona jest zbudowana. Jeśli zdjęcie w nagłówku waży kilka megabajtów, będzie ważyć tyle samo także w wersji z cache. To jeden z najczęstszych powodów, dla których strona z poprawnie skonfigurowanym cache nadal ładuje się wolno na słabszym łączu mobilnym.

Największy wpływ na wynik LCP mają zwykle zdjęcia w formacie JPG lub PNG wgrywane bezpośrednio z aparatu albo z banku zdjęć, bez wcześniejszej kompresji. Nowoczesne formaty, takie jak WebP czy AVIF, potrafią zmniejszyć wagę pliku przy zachowaniu praktycznie tej samej jakości wizualnej. Część wtyczek cache oferuje automatyczną konwersję do WebP, ale trzeba tę funkcję świadomie włączyć – domyślnie często jest wyłączona.

Osobny temat to czcionki. Niestandardowe fonty (Google Fonts albo pliki własne) potrafią znacząco opóźnić wyświetlenie tekstu, jeśli są ładowane w niewłaściwy sposób. Podobnie pliki CSS i JavaScript – jeśli motyw albo wtyczki wczytują ich dziesiątki, każdy z nich to dodatkowe połączenie do serwera, zanim strona w ogóle zacznie się renderować.

Warto też zwrócić uwagę na lazy loading – czyli opóźnione ładowanie obrazów, które nie są widoczne od razu po wejściu na stronę. Dobrze skonfigurowany, potrafi zauważalnie skrócić czas pierwszego wyświetlenia. Źle skonfigurowany – na przykład zastosowany do zdjęcia w nagłówku, które i tak jest widoczne od razu – może wręcz pogorszyć wynik LCP.

Zewnętrzne skrypty: czaty, piksele, analytics

To obszar, który najczęściej umyka uwadze, bo te elementy nie są “częścią WordPressa” w potocznym rozumieniu – są dodawane przez menedżery tagów, widgety albo wtyczki integracyjne. A jednak potrafią mieć ogromny wpływ na szybkość, bo każdy z nich to dodatkowe połączenie z zewnętrznym serwerem, na który Twoja strona nie ma żadnego wpływu.

Typowa lista podejrzanych: widget czatu na żywo, piksel reklamowy Meta, kod remarketingowy Google Ads, kilka narzędzi analitycznych uruchomionych jednocześnie, widżet mapy Google osadzony jako iframe, wtyczki social media pokazujące polubienia w czasie rzeczywistym. Każdy z tych elementów osobno wydaje się mały. Razem potrafią dodać kilka sekund do czasu ładowania strony, szczególnie jeśli są wczytywane w sposób blokujący renderowanie reszty treści.

Sprawdzenie tego nie wymaga zaawansowanej wiedzy technicznej. W narzędziach deweloperskich przeglądarki (zakładka Network, dostępna po naciśnięciu F12) widać listę wszystkich zasobów, jakie ładuje strona, wraz z czasem ich pobierania. Jeśli na liście widnieje kilkanaście domen zewnętrznych, to sygnał, że warto przejrzeć, które z tych integracji są rzeczywiście potrzebne, a które zostały dodane kiedyś “na próbę” i nikt ich później nie usunął.

Rozwiązaniem nie musi być całkowite usunięcie tych narzędzi – czat na żywo czy piksel reklamowy często mają realną wartość biznesową. Chodzi raczej o to, żeby ładowały się z opóźnieniem (dopiero po interakcji użytkownika ze stroną) albo asynchronicznie, zamiast blokować wyświetlenie reszty treści.

CDN jako uzupełnienie, nie zamiennik dobrego hostingu

CDN, czyli sieć dostarczania treści, przechowuje kopie statycznych plików strony – obrazów, arkuszy stylów, skryptów – na serwerach rozmieszczonych w różnych lokalizacjach geograficznych. Dzięki temu użytkownik pobiera te pliki z serwera położonego blisko niego, a nie z jednego centralnego hostingu, gdziekolwiek by on nie był. To realnie skraca czas ładowania, szczególnie dla odwiedzających z innych regionów niż ten, gdzie fizycznie stoi serwer.

Problem pojawia się wtedy, gdy CDN traktowany jest jako lekarstwo na wszystko. Widzieliśmy niejeden projekt, gdzie klient wdrożył CDN licząc, że to rozwiąże problem wolnego hostingu współdzielonego – a wynik poprawił się tylko nieznacznie, bo same zapytania generujące dynamiczną treść (czyli to, co dzieje się po stronie serwera, zanim strona trafi do cache) nadal przechodziły przez ten sam, przeciążony hosting. CDN przyspiesza dostarczanie gotowych plików. Nie przyspieszy generowania strony przez PHP i bazę danych, jeśli to właśnie tam leży wąskie gardło. Dlatego traktujemy CDN jako element układanki, który ma sens dopiero wtedy, gdy hosting i baza danych są już w porządku. W jednym z naszych wdrożeń pokazaliśmy krok po kroku, jak CDN Bunny.net odciąża hosting w sklepie WooCommerce, ale zawsze jako uzupełnienie dobrze skonfigurowanego serwera, nie jako sposób na obejście jego ograniczeń. Dla sklepu z dużym ruchem i wieloma zdjęciami produktowymi to bardzo sensowna inwestycja. Dla małej wizytówki z kilkoma podstronami efekt może być ledwo zauważalny, bo tam wąskie gardło zwykle leży gdzie indziej.

Kiedy potrzebna jest pomoc specjalisty

Część rzeczy opisanych wyżej da się sprawdzić i naprawić samodzielnie – wyczyszczenie bazy z rewizji, skompresowanie kilku zdjęć, opóźnienie ładowania widgetu czatu. To dobry punkt startowy i warto go zrobić, zanim zdecydujesz się na coś więcej.

Są jednak sytuacje, w których diagnostyka wymaga głębszego wejścia w kod strony – na przykład gdy zapytania do bazy generuje konkretna funkcja w motywie, gdy trzeba porównać kilka scenariuszy hostingowych, albo gdy strona ma na tyle złożoną strukturę (sklep, wiele integracji, niestandardowy motyw), że każda zmiana niesie ryzyko zepsucia czegoś innego. W takich przypadkach zgadywanie i kolejne wtyczki testowe kosztują więcej czasu niż jednorazowy, dokładny przegląd.

Jeśli przeszedłeś przez punkty opisane w tym artykule i strona nadal jest wolna, a nie masz pewności, gdzie dokładnie szukać dalej, dobrym krokiem bywa audyt strony, który pokazuje realne przyczyny zamiast domysłów – konkretny raport z tego, co spowalnia stronę i w jakiej kolejności warto to naprawiać.

Diagnostyka szybkości WordPress nie polega na dokładaniu kolejnych narzędzi w nadziei, że jedno z nich w końcu zadziała. Polega na sprawdzeniu, gdzie faktycznie ucieka czas – w hostingu, w bazie danych, w obrazach czy w zewnętrznych skryptach – i naprawieniu tego konkretnego miejsca. WP Rocket i Perfmatters to dobre narzędzia, ale działają tylko na tym, co jest w ich zasięgu. Reszta wymaga spojrzenia na całość strony, nie tylko na ustawienia jednej wtyczki.

Sprawdziłeś już wtyczki cache, a strona nadal jest wolna?
Pokażemy Ci, gdzie dokładnie strona traci czas – hosting, baza danych, obrazy czy zewnętrzne skrypty – i co warto naprawić w pierwszej kolejności. Umów się na bezpłatną konsultację wstępną i porozmawiajmy o Twojej stronie.