Wysokie zużycie CPU na WordPressie najczęściej wynika z kilku powtarzalnych przyczyn. To brak bądź błędna konfiguracja cache, obciążające wtyczki, kosztowne zapytania do bazy czy ruch botów i prób logowania brute-force. Żeby to naprawić, trzeba szybko ustalić, co dokładnie generuje obciążenie, a następnie wdrożyć konkretne działania.
W dalszej części przejdziemy przez konkretną ścieżkę działań. Od szybkich testów, które w kilka minut wskazują winowajcę, przez analizę logów i zapytań, aż po praktyczne poprawki w konfiguracji WordPressa, cache, bazy danych i serwera. Sprawdzisz jak szybko obniżyć CPU „na teraz”, ale też zabezpieczysz stronę przed powrotem problemu przy kolejnym skoku ruchu.
Z tego artykułu dowiesz sie:
Kiedy CPU rośnie?
CPU, czyli procesor, to „silnik” serwera odpowiedzialny za wykonywanie obliczeń. W przypadku WordPressa CPU pracuje głównie wtedy, gdy serwer musi uruchomić kod PHP, przetworzyć logikę wtyczek i motywu, wykonać zapytania do bazy danych oraz wygenerować gotowy HTML (albo JSON w API). Im więcej pracy do wykonania na jedno żądanie i im więcej żądań w jednostce czasu, tym szybciej rośnie zużycie CPU.
CPU na WordPressie
W momencie gdy użytkownik otwiera stronę na WordPressie, serwer przechodzi przez sekwencję kroków, gdzie każdy z nich może podnosić CPU, zwłaszcza gdy strona jest generowana dynamicznie.
- Serwer odbiera zapytanie
Program serwera (np. Nginx, Apache, LiteSpeed) przyjmuje prośbę przeglądarki typu „wyświetl stronę” i sprawdza, czy może od razu zwrócić gotowy plik czy musi uruchomić WordPressa. - PHP uruchamia WordPressa
Jeśli nie ma gotowej wersji w pamięci podręcznej, serwer uruchamia PHP. Wówczas ładuje WordPressa, a razem z nim motyw i wtyczki. To często najbardziej „kosztowny” moment, bo im więcej wtyczek i logiki, tym więcej pracy. - Pobieranie informacji z bazy danych
Baza danych dostaje zapytania i pobiera potrzebne informacje. - Strona jest gotowa do wyświetlenia
Na podstawie danych WordPress generuje wynik, czyli najczęściej HTML (to, co widzisz na ekranie). Czasem dochodzą obliczenia, np. w przypadku sklepów internetowych, filtrowanie i sortowanie wyników, wyliczanie cen, koszyka, dostępności, rabatów. - Cache i kompresja
Zwykle pomaga bo serwer podaje gotową stronę i nie uruchamia WordPressa (PHP + baza).
Jak sprawdzić obciążenie serwera?
Wykresy i statystyki w panelu pomagają zobaczyć, kiedy serwer ma największe obciążenie i co je powoduje. To ważne przy diagnozowaniu spowolnień, analizie ruchu podczas akcji sezonowych i testach obciążeniowych. Jeśli masz usługę w cyber_Folks, pokażemy Ci co sprawdzać i gdzie szukać.
Sprawdź wykresy i statystyki serwera
- Zaloguj się do panelu direct_Admin dla swojej usługi w cyber_Folks.
- Przejdź do sekcji Statystyki serwera / Wykresy i statystyki (nazwy mogą się minimalnie różnić w zależności od wersji panelu).
- Odczytaj wykresy dotyczące m.in.:
- zużycia CPU (procesora),
- zużycia pamięci,
- ewentualnie liczby procesów / obciążenia w czasie.

Na co patrzeć:
- czy obciążenie rośnie skokowo (piki) czy utrzymuje się stale,
- o jakich godzinach pojawiają się piki (np. po publikacji, kampanii, w nocy – cron/backup),
- czy wzrost CPU idzie w parze ze wzrostem pamięci.
Wskazówka
Skorzystaj z robo_Folksa. W prawym dolnym rogu panelu znajdziesz jego ikonkę. To Twój asystent AI. Wpisz np. polecenie: „Pokaż statystyki mojego serwera”, a po chwili dostaniesz czytelne podsumowanie najważniejszych parametrów i obciążenia.

Jeśli masz VPS albo serwer dedykowany
Jeśli korzystasz z serwera VPS lub dedykowanego w cyber_Folks, udostępniliśmy dla użytkowników dodatkowe narzędzie, pomagające szybko ustalić, co dokładnie generuje obciążenie CPU na Twojej stronie. Działa ono na bazie statystycznej analizy logów serwera WWW. Wskazuje m.in. łączną liczbę wywołań serwisu w danym dniu, czas CPU zużyty przez żądania, udział robotów indeksujących, rozkład typów wywołań (GET/POST/HEAD), kody odpowiedzi (200/301/404/500), najbardziej obciążające adresy URL oraz IP źródłowe.
Narzędzie jest dostępne tylko na platformach wirtualnych i serwerach dedykowanych i uruchamia się je w konsoli po zalogowaniu na użytkownika admin, poleceniem tld-cpucheck.pl z parametrami: data i domena, np.: tld-cpucheck.pl 2025.03.11 twojadomena.pl
Więcej o sprawdzaniu obciążenia procesora (cpu) serwisu www znajdziesz w naszej pomocy.
Wysokie zużycie CPU? Plan naprawczy
Wysokie zużycie CPU na WordPressie zwykle wynika z tego, że serwer musi wykonać za dużo pracy w PHP i bazie danych w krótkim czasie. Oznacza to również podwójny problem SEO. Strona ładuje się wolniej, pogarszają się wskaźniki Core Web Vitals i doświadczenie użytkownika. Równocześnie rośnie ryzyko błędów 5xx oraz spadków w indeksacji, gdy boty Google trafiają na przeciążony serwer.
Ten wpis może Cię zainteresować. Szybkość strony. Jak docierać do większej liczby klientów.
Brak lub błędnie ustawiony cache
Cache strony to mechanizm, przechowujący gotową odpowiedź (zwykle HTML) dla danego adresu i jego wariantu. Cache może zostać zbudowany przy pierwszym żądaniu lub przez preloading, a kolejne pasujące wejścia mogą być obsługiwane bez uruchamiania WordPressa, o ile cache nie jest omijany (np. przez logowanie, koszyk, specyficzne cookies lub parametry URL).
Jak cache wpływa na CPU?
Cache strony zmienia sposób procesu obsługi wizyty użytkownika na stronie. Jego obecność sprawia, że po wejściu na witrynę zamiast każdorazowo uruchamiać PHP i wykonywać zapytania do bazy danych, serwer podaje już gotowy wynik na żądanie.
Co jeśli nie ma cache?
WordPress jako aplikacja dynamiczna nie podaje gotowego pliku strony, jeśli nie ma cache. Musi uruchomić cały proces od początku. To oznacza uruchomienie PHP, załadowanie rdzenia WordPressa, motywu, wtyczek i wykonanie całej logiki hooków oraz filtrów. Pozostaje jeszcze odpytanie bazy danych. Każdy z tych kroków wymaga czasu procesora. PHP wykonuje kod, przetwarza dane, buduje wynik HTML, a WordPress często generuje dodatkowe obciążenie przez rozbudowane wtyczki, ciężkie zapytania (np. do wp_postmeta i wp_options) oraz funkcje działające w tle.
Bez cache nawet zwykła strona z kilkoma podstronami potrafi „zjadać” CPU, bo przy większym ruchu serwer wykonuje ten sam zestaw operacji setki lub tysiące razy, zamiast raz wygenerować stronę i serwować ją wielokrotnie jako gotowy wynik.
Co zrobić?
Rekomendujemy skorzystanie z Redisa, technologii dzięki jakiej Twój WordPress będzie mógł w pełni wykorzystać swój mechanizm cachowania obiektowego. Redis pozwala znacznie zmniejszyć obciążenie bazy danych i jeszcze bardziej przyspieszyć wczytywanie strony.
Dostęp do serwera Redis jest domyślnie włączony na hostingu dla WordPress w cyber_Folks. Wybierajac hosting WordPress w cyber_Folks, korzystasz z bardzo wydajnego serwera LiteSpeed wraz z komercyjnym pluginem LS Cache. To dlatego Twój WordPress zaczyna pojawiać się w przeglądarce szybciej, niż Ty mrugniesz okiem!
Polecany wpis. REDIS w WordPress. Co to jest i jak działa Object Cache w WordPressie?
Ataki brute force
Automatyczne próby masowego logowania, to jedna z częstszych przyczyn wysokiego CPU na WordPressie. Boty wysyłają zmasowane żądania do Twojej witryny. W praktyce najczęściej są to próby brute-force na wp-login.php, wykorzystanie xmlrpc.php, skanowanie popularnych ścieżek w poszukiwaniu podatności oraz agresywne crawlery, które pobierają dużą liczbę URL-i w krótkim czasie.
Jak wpływa to na CPU?
Atak brute-force ma bezpośrednie powiązanie z CPU, bo zamienia stronę logowania w generator obciążenia. Każde żądanie, które trafia do WordPressa, może uruchamiać PHP, ładować wtyczki i wykonywać zapytania do bazy. Próby logowania są szczególnie kosztowne, bo dochodzi obsługa mechanizmów uwierzytelniania i zabezpieczeń. Przy agresywnym crawlowaniu serwer musi dynamicznie generować wiele stron jednocześnie, a gdy cache jest omijany lub nie obejmuje danego typu treści, CPU rośnie skokowo.
Jak to wygląda od strony serwera?
- skok liczby żądań do wp-login.php / xmlrpc.php;
- rosnąca liczba procesów PHP-FPM/Apache;
- wolniejsza strona dla realnych użytkowników;
- czasem błędy 5xx, gdy serwer dobija do limitów zasobów.
Co zrobić, aby obniżyć CPU?
- ustaw limity prób logowania
Po ustalonej liczbie błędnych prób zalogowania, ustaw blokadę czasową. - stosuj dwuskładnikowe uwierzytelnianie (mechanizm 2 FA)
2FA nie zmniejsza samej liczby prób logowania tak mocno jak limity i CAPTCHA, ale ogranicza ryzyko przejęcia strony. - blokada/ograniczenie XML-RPC
Jeśli nie korzystasz z aplikacji mobilnej, ograniczenie bądź blokada pliku na starcie odcina część hurtowego ruchu. - stosuj WAF/CDN
WAF (Web Application Firewall) i CDN to warstwa „przed” Twoją stroną, która przechwytuje ruch i może go filtrować oraz cache’ować. CDN przechowuje statyczne zasoby (a czasem też całe strony), a WAF blokuje podejrzane żądania i automaty.
Ten wpis może Cię zainteresować. Jak zatrzymać ataki brute-force na WordPressie?
Duża liczba wtyczek
Wtyczki upraszczają życie, ale nie pozostają bez znaczenia dla kondycji strony. Wtyczki dodają daną funkcję do witryny na WordPressie, ale jednocześnie dodają określony kod, ustawienia i integracje.
Jak wtyczki wpływają na CPU?
Kilka wtyczek nie ma większego wpływu na CPU, ale jeśli masz ich zainstalowanych kilkadziesiąt – to każda z nich dorzuca swoje procesy i zapytania. Więcej wtyczek oznacza więcej pracy dla php na każdym żądaniu. WordPress musi je załadować, a część z nich wykonuje logikę w tle, dodaje hooki/filtry, generuje dodatkowe zapytania do bazy, ładuje własne pliki, a czasem wykonuje ciężkie zadania cykliczne. Efekt to dłuższy czas generowania strony i większe zużycie CPU, zwłaszcza gdy nie działa cache albo ruch jest większy.
Co zrobić?
- Szybki audyt używanych wtyczek
Zrób przegląd aktualnie zainstalowanych wtyczek. Może się okazać, że część z nich jest już dawno przez Ciebie nieużywana bądź funkcje poszczególnych zazębiają się, generując niepotrzebne obciążenie. W tym celu przejdź do swojego WordPressa. Listę znajdziesz w menu po lewej stronie (wtyczki). Usuń te, jakich już nie używasz.
2. Usuń duplikaty wtyczek o zazębiających się funkcjach
Duplikaty funkcji to sytuacja, w jakiej masz kilka wtyczek robiących tę samą (lub bardzo podobną) rzecz. Z punktu widzenia WordPressa to oznacza, że przy każdym wejściu uruchamia się więcej kodu niż potrzeba, często wykonują się podwójne zapytania do bazy, ładują się dodatkowe pliki CSS/JS, a niektóre wtyczki potrafią też uruchamiać równolegle zadania w tle (cron). Efekt jest prosty. CPU rośnie, a Ty nie dostajesz proporcjonalnie większej wartości.
3. Usuń wtyczki, nie tylko zdezaktywuj
Sam proces dezaktywacji wtyczki często zostawia tabele w bazie, rekordy w wp_options, zadania cron. Jeśli nie używasz danej wtyczki, usuń ją całkowicie. Sama dezaktywacja może pozostawiać:
- tabele w bazie,
- rekordy w wp_options (autoload),
- zadania cron.
Przenieś część rzeczy poza WordPress (tam gdzie to ma sens)
To jeden z najskuteczniejszych sposobów na obniżenie CPU, bo przesuwasz zadania z warstwy PHP/WordPressa do warstwy, która obsługuje je szybciej i taniej zasobowo. WordPress świetnie nadaje się do zarządzania treścią, ale nie musi być miejscem, w jakim realizujesz każdą techniczną funkcję serwera.
| OBSZAR | Jak odciąża CPU? | Co zrobić? | Efekt |
|---|---|---|---|
| Przekierowania jako reguły serwera zamiast wtyczki | Redirect wykonuje się zanim uruchomi się WordPress, więc nie ma kosztu PHP i bazy danych (szczególnie przy dużej liczbie 301/302). | Przenieś przekierowania do .htaccess (Apache/LiteSpeed) lub konfiguracji Nginx. Wtyczkę zostaw tylko do pojedynczych przypadków lub zarządzania, ale nie jako główny mechanizm. | Mniej uruchomień PHP → niższe CPU i stabilniejsza strona przy skokach ruchu. |
| Blokady botów i brute-force – WAF/CDN lub reguły serwera | Boty są zatrzymywane „na wejściu”, więc nie uruchamiają WordPressa, nie mnożą procesów PHP i nie generują zapytań do bazy. | Włącz WAF/CDN, ustaw rate limiting i reguły ochrony dla wp-login.php, xmlrpc.php oraz agresywnych wzorców ruchu. Dodatkowo dodaj blokady po stronie serwera (jeśli potrzebne). | Ograniczenie sztucznego ruchu, CPU spada, strona nie zwalnia przez ataki. |
| Cache i kompresja na poziomie serwera | Page cache pozwala podawać gotowy HTML bez PHP, a kompresja (gzip/brotli) jest efektywniejsza na poziomie serwera niż w PHP. | Włącz cache w warstwie serwera (np. LiteSpeed Cache/LSCache, Nginx FastCGI cache) lub w hostingu. Dopilnuj, żeby strony publiczne były cachowane, a dynamiczne (koszyk, konto) wyłączone. Kompresję ustaw w konfiguracji serwera lub CDN. | Mniej uruchomień PHP → niższe CPU i stabilniejsza strona przy skokach ruchu. |
Zadbaj o zadania CRON
Domyślnie WordPress nie korzysta z prawdziwego crona systemowego tylko z domyślnego wp-cron. Sprawdza zaplanowane zadania podczas wejścia użytkownika na stronę. To wygodne na mniejszych stronach, ale przy większym ruchu może oznaczać wyzwanie. Część odwiedzin uruchamia przy okazji zadania w tle – publikacje, wysyłki, synchronizacje, czyszczenie danych, importy, generowanie miniatur.
Gdy zadań jest dużo albo są ciężkie, użytkownik nie dostaje tylko HTML strony. Dostaje stronę plus “bonus” w postaci pracy administracyjnej systemu.
Co zatem zrobić?
Najczęściej warto wyłączyć pseudo-cron WordPressa i zastąpić go cronem systemowym uruchamianym co kilka minut. Sprawdź jak poprawnie wyłączyć WP-Cron i uruchomić CRON systemowy w WordPressie?
Nowe zadanie?
Jeśli potrzebujesz stworzyć nowe, dodatkowe zadanie, w cyber_Folks pomoże Ci w tym robo_Folks. Nie musisz być osobą techniczną. Wystarczy proste polecenie, a asystent AI zrobi to za Ciebie.


Dzięki temu zadania wykonują się przewidywalnie, niezależnie od ruchu użytkowników. Dodatkowo ciężkie operacje należy rozdzielić według typu i godzin działania: backupy, importy feedów, synchronizacje z ERP, generowanie raportów i sprzątanie danych powinny być planowane świadomie.
Uporządkuj bazę danych
Baza danych bardzo rzadko psuje się nagle, ale bardzo często powoli obrasta danymi, które nic już nie wnoszą. Najczęściej są to rewizje wpisów, wygasłe transients, osierocone rekordy w postmeta, stare logi, spam, dane po usuniętych wtyczkach i rozrośnięte wp_options. To nie jest jeden duży błąd, ale dodatkowa warstwa, zajmująca miejsce. Jak w magazynie, gdzie między potrzebnymi skrzynkami stoją kartony po starych dostawach. Niby da się pracować, ale wszystko trwa dłużej.
Podziel dane na 3 grupy
Zrób przegląd bazy. Usuń zbędne rzeczy.
- potrzebne
To treści, zamówienia, użytkownicy i aktywne ustawienia. - tymczasowe
To cache, transienty, sesje i kolejki. - martwe
To ślady po nieaktywnych pluginach, osierocone meta rekordy i stare logi.
Taki podział pozwoli uporządkować Ci pracę, zmniejszyć ryzyko, że usuniesz coś, co nadal steruje działaniem strony.
Co usuwać z bazy WordPressa w pierwszej kolejności?
Na początek wyczyść rewizje wpisów, wygasłe transienty i osierocone rekordy w postmeta. To zazwyczaj tutaj baza rośnie najszybciej, ale bez realnego wpływu na działanie strony. Rewizje mnożą kolejne wersje treści, transients miały być tymczasowe, a osierocone metadane zostają po wpisach, produktów lub stronach, które już nie istnieją. Każdy z tych elementów osobno rzadko robi duży problem, ale razem zwiększają rozmiar tabel i koszt codziennych operacji.
Osobno sprawdź dane po usuniętych wtyczkach i tabelę wp_options. Wiele pluginów zostawia po sobie opcje, logi, własne tabele i rekordy techniczne. Szczególnie wp_options warto przejrzeć dokładnie, bo część wpisów ładuje się przy każdym requestcie. Jeśli są zbędne, WordPress wykonuje dodatkową pracę przy każdej odsłonie.
Na końcu usuń stare logi, spam, kosz, sesje i dane robocze. To nie są zwykle główne źródła wysokiego CPU, ale porządkują bazę i zmniejszają jej objętość. Działaj etapami, nie hurtowo.
Zanim cokolwiek skasujesz, zrób backup i sprawdź, czy dane nie są nadal używane.
Patent na wysokie zużycie CPU
Wysokie zużycie CPU na WordPressie rzadko wynika z jednego błędu. Zwykle to suma kilku problemów. Od niewłaściwie ustawionego cache, przez zbyt ciężkie wtyczki, po nieuporządkowaną bazę, zadania cron uruchamiane domyślne, nie systemowo. W artykule pokazaliśmy zarys najczęstszych przyczyn i kierunek działań, które pomagają odzyskać wydajność strony. Nie trzeba zaczynać od dużej przebudowy. Najpierw ustal, co naprawdę generuje obciążenie, a potem krok po kroku poprawić najcięższe elementy.
Jeśli korzystasz z hostingu WordPressa w cyber_Folks, część tych działań zrobisz szybciej dzięki gotowym narzędziom, wsparciu LiteSpeed i pomocy robo_Folksa. A to oznacza mniej czasu na szukanie winowajcy i więcej czasu na rozwój strony, która ma działać szybko nie tylko dziś, ale też wtedy, gdy ruch zacznie naprawdę rosnąć.





Dobre porady bo zauważyłem, że WP pożera coraz więcej zasobów. Dodałbym jeszcze, że warto 404ki zrobić w html’u. Wtedy scrawlujące roboty nie będą za każdym razem odwoływać się do bazy danych – to też odciąży zdecydowanie.