WordPress zużywa dużo CPU? Jak znaleźć przyczynę i ograniczyć obciążenie

100% CPU oznacza wykorzystanie przydzielonego limitu obliczeniowego w danym momencie, ale sposób raportowania zależy od hostingu. Wykres może pokazywać zasoby całego konta albo pojedynczego procesu. Krótki skok podczas importu może być spodziewany, a powtarzające się obciążenie połączone z błędami 5xx wymaga diagnostyki.

Zapisz godzinę początku i końca skoku, wartość CPU, pamięć RAM, liczbę procesów oraz komunikat hostingu o limicie. Sprawdź, czy w tym samym czasie strona przestała się ładować, panel administratora zwolnił albo pojawił się problem z koszykiem i zamówieniami. Panel hostingu mierzy zasoby konta; sam WordPress nie dostarcza równoważnego wykresu CPU serwera.

Oddziel przeciążenie pojedynczego procesu od przeciążenia całego konta. Jeśli panel hostingu pokazuje nazwę procesu lub skryptu PHP, zachowaj ją do dalszego porównania. Jeśli widzisz wyłącznie wykres zbiorczy, szukaj zdarzeń z tego samego przedziału czasu.

Zapisz wykresy, logi i aktywność sklepu przed zmianą konfiguracji, aby później móc ocenić efekt. Zanotuj przedział przeciążenia, CPU, RAM, błędy serwera i liczbę żądań, a następnie zachowaj kopię tych danych wraz ze strefą czasową.

Tabela wskazuje, gdzie szukać danych dla zauważonego objawu. Jeden trop potwierdź drugim źródłem, na przykład logiem PHP lub harmonogramem zadania.

Porównuj czasy zapisane w tej samej strefie. Hosting, WordPress i usługi zewnętrzne mogą używać różnych ustawień czasu, dlatego rozbieżność zegarów może ukryć związek między żądaniem a skokiem.

Access log zapisuje żądania obsłużone przez serwer, ale jego format określa, czy wpis zawiera User-Agent i inne pola. W Apache format Common Log Format zapisuje adres klienta oraz linię żądania, a format combined dodaje między innymi User-Agent; hosting może stosować własny format. Dokumentację Apache dotyczącą pól logu sprawdzono w październiku 2026 roku.

Zestawiaj częstotliwość żądań z typowym ruchem, szczególnie dla wyszukiwania, koszyka, logowania, `wp-admin/admin-ajax.php` i API REST. Sam User-Agent nie potwierdza tożsamości bota, bo nagłówek można podrobić. Porównaj go z adresem IP, tempem żądań i ścieżkami odwiedzanych adresów.

Sprawdź, czy skok pokrywa się z importem produktów, synchronizacją magazynu, generowaniem mapy strony, kopią zapasową albo zadaniami wtyczek. WP-Cron to mechanizm WordPressa uruchamiający zaplanowane zdarzenia, zwykle podczas odwiedzin strony. Dokumentacja WordPressa opisuje jego działanie; stan sprawdzony w październiku 2026 roku.

Jeśli masz WP-CLI, `wp cron event list` wyświetli zaplanowane zdarzenia, a `wp cron test` sprawdzi mechanizm uruchamiania WP-Cron. Lista zdarzeń pokazuje m.in. nazwę hooka i czas kolejnego uruchomienia. Nie usuwaj zadań, których pochodzenia nie znasz. Dokumentację WP-CLI sprawdzono w październiku 2026 roku.

Ograniczaj ruch regułą dopasowaną do potwierdzonego wzorca i sprawdź, czy nie zablokujesz klientów, integracji ani robotów wyszukiwarek. Zalecamy najpierw ograniczyć nadmiarowe żądania do konkretnego kosztownego endpointu, ponieważ szeroka blokada może odciąć prawidłowych użytkowników. Jeśli logi wskazują na kosztowne żądania sklepu, optymalizacja szybkości sklepu WooCommerce może objąć diagnozę i wdrożenie zmian.

Query Monitor wiąże zapytania SQL, błędy PHP i wywołania HTTP z komponentem obsługującym konkretne żądanie. Po instalacji i aktywacji zaloguj się jako administrator, odtwórz problematyczną operację i sprawdź panele Queries, PHP Errors oraz HTTP API Calls. Przy REST API wykonaj żądanie z użytkownikiem uprawnionym do podglądu danych Query Monitor.

Query Monitor pokazuje dane bieżącego ładowania strony i nie zapisuje historii pomiarów. Panel Queries by Component grupuje zapytania według wtyczki, motywu lub WordPressa, a panel PHP Errors pokazuje komunikaty z danego ładowania. Narzędzie nie wskaże samo w sobie przyczyny skoku, którego nie uda się odtworzyć podczas pomiaru. Dokumentację Query Monitor sprawdzono w październiku 2026 roku.

Wtyczki i motywy testuj na stagingu, wyłączając jeden komponent naraz i odtwarzając ten sam scenariusz. Przed próbą wykonaj kopię plików oraz bazy. Nie wyłączaj dodatków płatniczych, magazynowych ani wysyłkowych na działającym sklepie, bo możesz przerwać przyjmowanie zamówień lub synchronizację.

Wolne zapytania, powtarzające się błędy PHP i brak trafień w cache wskazują różne obszary do sprawdzenia, ale pojedynczy objaw nie dowodzi przyczyny wysokiego CPU. Query Monitor grupuje zapytania i pokazuje błędy dla bieżącego żądania, a wykres hostingu potwierdza obciążenie konta.

Tabela łączy objaw z pomiarem i kolejnym krokiem diagnostycznym. Wybierz jeden trop, a potem sprawdź go na stronie lub operacji, która wywołuje problem.

Cache ogranicza ponowne generowanie odpowiedzi dla powtarzalnych żądań do publicznych stron. Gdy odpowiedź jest już zapisana, serwer może ją zwrócić bez ponownego uruchamiania części kodu PHP. Cache nie zatrzyma pętli zadań, ciężkiego importu ani kosztownych operacji administratora. W WooCommerce sprawdź, czy koszyk, sesje i składanie zamówienia są wyłączone z cache.

Ograniczaj CPU przez usunięcie potwierdzonego źródła kosztownych żądań lub zadań, a po każdej zmianie sprawdź pomiar i funkcje sklepu. Wprowadzaj jedną zmianę naraz, aby dało się powiązać efekt z konkretnym działaniem.

• Ogranicz nadmiarowy ruch, jeśli access logi potwierdzają jego źródło.
• Napraw albo przełóż zadanie cykliczne, import lub kopię, jeśli skok pokrywa się z harmonogramem.
• Popraw zapytanie lub ustawienie wtyczki wskazane przez logi i test na stagingu.
• Włącz cache dla publicznych stron, które mogą korzystać z zapisanej odpowiedzi, i wyklucz koszyk oraz checkout.
• Zaktualizuj albo zastąp komponent po teście zgodności i wykonaniu kopii.

Po wdrożeniu zmiany sprawdź wykres CPU, liczbę żądań i czas odpowiedzi. W sklepie przetestuj wyszukiwanie, koszyk, płatność i utworzenie zamówienia. Poprawa wykresu nie potwierdza, że wszystkie procesy sklepu działają poprawnie.

Zmiana hostingu ma uzasadnienie, gdy pomiary pokazują regularne przekraczanie limitów mimo usunięcia potwierdzonych problemów kodu i ruchu. Pojedynczy pik po dużej operacji nie wystarcza do takiej decyzji. Sprawdź limity procesów, RAM, czasu wykonania i jednoczesnych żądań oraz ustal, czy hosting wskazuje proces odpowiedzialny za przekroczenie.

Tabela pomaga rozpoznać, czy najpierw poprawić kod, czy porównać parametry serwera. Zgromadź wykresy i logi z okresu problemu przed rozmową z dostawcą.

Perspektywa KC Mobile: decyzję o hostingu opieramy na powtarzalnym wzorcu w wykresach i logach. Gdy obciążenie występuje tylko przy określonym żądaniu, zwiększenie zasobów może odsunąć problem bez usunięcia jego przyczyny.

Jeśli sklep WooCommerce wymaga analizy wydajności i bezpiecznego wdrożenia zmian, diagnostyka wydajności sklepu WooCommerce może obejmować ustalenie źródła obciążenia i poprawę konfiguracji. Przekaż wykonawcy wykresy i logi z tego samego przedziału, aby można było powiązać zmianę z konkretnym objawem.

Naprawa działa, gdy podobny ruch w tych samych godzinach powoduje niższe obciążenie bez błędów w zamówieniach i zadaniach sklepu. Porównaj okres przed zmianą z okresem po niej, używając tych samych wykresów hostingu i filtrów logów; jeśli ruch wyraźnie się różni, uwzględnij to w ocenie.

Przez kilka dni kontroluj CPU, RAM, błędy 5xx, logi PHP, formularze i przebieg zamówienia. Sprawdź też, czy importy i zaplanowane zadania zakończyły się poprawnie. Kolejność pomiarów szybkości strony opisuje poradnik przyspieszania WordPressa.

• Wolny WordPress i słaby INP? Zdiagnozuj opóźnienia interakcji
• Jak CDN może poprawić wydajność Twojego sklepu internetowego
• Gzip i Brotli - jak włączyć kompresję strony WWW i sprawdzić efekt?
• Cache na stronie www: jak działa i kiedy przyspiesza ładowanie