WordPress Cron — jak działa WP-Cron, dlaczego spowalnia stronę i jak go zastąpić systemowym cronem

Opublikowano: 20 marca 2026 · Autor: Marcin Szewczyk-Wilgan

WordPress ma wbudowany mechanizm planowania zadań w tle — WP-Cron. Odpowiada za publikowanie zaplanowanych postów, sprawdzanie aktualizacji, wykonywanie kopii zapasowych, wysyłkę newsletterów i dziesiątki innych operacji. Problem w tym, że WP-Cron nie jest prawdziwym cronem — nie działa ciągle, lecz uruchamia się tylko wtedy, gdy ktoś odwiedzi stronę. To oznacza dwa scenariusze: na stronach z małym ruchem zadania się opóźniają, a na stronach z dużym ruchem — każde ładowanie strony obciąża serwer dodatkowym sprawdzaniem bazy danych. Rozwiązanie jest proste i zalecane nawet przez oficjalną dokumentację WordPress: wyłączyć WP-Cron i zastąpić go systemowym cronem.

Jak działa WP-Cron

WP-Cron to „wirtualny cron" — emulacja systemowego crona zaimplementowana w PHP. Został zaprojektowany w czasach, gdy WordPress działał głównie na shared hostingu bez dostępu do systemowego crontab.

Mechanizm triggeringPrzy każdym ładowaniu strony WordPress sprawdza w tabeli wp_options (klucz „cron") listę zaplanowanych zadań. Jeśli jakiekolwiek zadanie jest „due" — uruchamia je. To oznacza, że WP-Cron nie działa w tle — jest triggerowany przez ruch na stronie.
Brak gwarancji czasuJeśli nikt nie odwiedzi strony między 14:00 a 17:00, zadanie zaplanowane na 14:00 uruchomi się dopiero o 17:00 — przy pierwszej wizycie. Oficjalna dokumentacja WordPress potwierdza: „nie możesz być w 100% pewien, kiedy zadanie się uruchomi — możesz być pewien, że w końcu się uruchomi."
Co WP-Cron obsługujePublikowanie zaplanowanych postów, sprawdzanie i instalowanie aktualizacji, codzienne kopie zapasowe (wtyczki backupowe), wysyłka zaplanowanych maili i newsletterów, czyszczenie transientów, generowanie raportów, synchronizacja z API zewnętrznych usług — każda wtyczka może rejestrować własne zadania cron.

Problemy WP-Cron z wydajnością

WP-Cron został zaprojektowany jako pragmatyczne rozwiązanie dla ograniczonych środowisk hostingowych. Na nowoczesnych stronach z ruchem, cache i wymaganiami wydajnościowymi — staje się problemem.

Duży ruch

Obciążenie przy każdym ładowaniu

Każde wyświetlenie strony triggeruje sprawdzenie bazy danych pod kątem zadań cron. Na stronie z 10 000 wizyt dziennie to 10 000 dodatkowych zapytań SQL. Jeśli brakuje wolnych procesów PHP-FPM, cron czeka w kolejce, blokując odpowiedź dla użytkownika. To mierzalny wpływ na TTFB.

Mały ruch

Zadania się nie uruchamiają

Blog z kilkunastoma wizytami dziennie — zaplanowany post na 8:00 rano nie opublikuje się, jeśli pierwszy odwiedzający pojawi się o 12:00. Kopie zapasowe, sprawdzanie aktualizacji, synchronizacja — wszystko czeka na wizytę. To niewiarygodne dla operacji krytycznych czasowo.

Cache

Konflikt z cache stron

Wtyczki cache serwują strony statycznie, omijając PHP. Jeśli większość żądań trafia do cache — WP-Cron nie jest triggerowany. Zadania się kumulują i uruchamiają nagle, gdy ktoś trafi na niecache'owaną stronę — powodując spike obciążenia serwera.

Bezpieczeństwo

Publiczny endpoint

Plik wp-cron.php jest publicznie dostępny. Boty mogą go wywoływać wielokrotnie, wymuszając powtarzane sprawdzanie i uruchamianie zadań. To zużywa zasoby serwera i może prowadzić do duplikowania operacji — np. podwójnej wysyłki maili czy wielokrotnych backupów.

Rozwiązanie: wyłączenie WP-Cron i konfiguracja systemowego crona

Oficjalna dokumentacja WordPress (Plugin Handbook) zaleca wyłączenie WP-Cron i zastąpienie go systemowym cronem. To operacja prosta, bezpieczna i dająca natychmiastowy efekt. Oto procedura krok po kroku:

Krok 1: Wyłączenie WP-CronDodaj w pliku wp-config.php (przed linią „That's all, stop editing!"): define('DISABLE_WP_CRON', true); — to wyłącza automatyczny triggering crona przy ładowaniu strony. Uwaga: po tym kroku zaplanowane zadania nie będą się uruchamiać — natychmiast przejdź do kroku 2.
Krok 2: Systemowy cronDodaj zadanie w systemowym crontab serwera (przez SSH lub panel hostingu np. cPanel → Cron Jobs). Typowa konfiguracja: co 15 minut dla stron standardowych, co 5 minut dla aktywnych sklepów WooCommerce. Komenda: */15 * * * * wget -q -O - https://domena.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Krok 3: WeryfikacjaZainstaluj wtyczkę WP Crontrol — pokazuje listę zaplanowanych zadań i ich status. Sprawdź, czy zadania się uruchamiają w oczekiwanych odstępach. Monitoruj przez kilka dni — upewnij się, że zaplanowane posty publikują się na czas, backupy działają, aktualizacje się sprawdzają.
Alternatywa: ALTERNATE_WP_CRONJeśli nie masz dostępu do systemowego crontab (shared hosting bez SSH), możesz użyć define('ALTERNATE_WP_CRON', true); — WordPress uruchomi crona jako osobny proces po załadowaniu strony, zamiast w trakcie. To lepsze niż domyślne zachowanie, ale gorsze niż systemowy cron.

Kiedy optymalizacja WP-Cron ma sens

Nie każda strona wymaga pełnej zamiany WP-Cron na systemowy cron. Oto scenariusze, w których optymalizacja jest kluczowa:

Strony z dużym ruchemKażda strona z ruchu powyżej 1000 wizyt dziennie odczuwa obciążenie WP-Cron. Systemowy cron eliminuje dodatkowe zapytania SQL przy każdym ładowaniu — to może poprawić TTFB o 15–30% przy dużym ruchu.
Sklepy WooCommerceWooCommerce intensywnie korzysta z WP-Cron: przetwarzanie zamówień, wysyłka maili transakcyjnych, aktualizacje stanów magazynowych, raporty. Opóźniony cron = opóźnione maile potwierdzające zamówienie. Systemowy cron co 5 minut to minimum dla sklepów.
Strony z cacheJeśli korzystasz z page cache (co powinieneś) — WP-Cron może nie być triggerowany przez cache'owane żądania. Systemowy cron rozwiązuje ten problem — wywołuje wp-cron.php bezpośrednio, niezależnie od cache.
WordPress MultisiteW instalacjach Multisite WP-Cron musi obsłużyć zadania wielu witryn — obciążenie rośnie proporcjonalnie. Systemowy cron (lub dedykowane rozwiązania jak Cavalcade) to konieczność przy kilkunastu+ witrynach.

Podsumowanie

WP-Cron to pragmatyczne rozwiązanie z ery shared hostingu — ale na nowoczesnych stronach WordPress z ruchem, cache i wymaganiami wydajnościowymi staje się obciążeniem. Wyłączenie WP-Cron i zastąpienie go systemowym cronem to jedna z najprostszych i najbardziej efektywnych optymalizacji WordPressa. Operacja zajmuje kilka minut, jest zalecana przez oficjalną dokumentację i daje natychmiastowy efekt — przewidywalne uruchamianie zadań, mniejsze obciążenie serwera i lepszy TTFB.

W WebOptimo konfiguracja systemowego crona to standardowy element wdrożenia i opieki WordPress. Optymalizujemy harmonogram zadań, monitorujemy ich wykonanie i eliminujemy zbędne wpisy cron pozostawione przez usunięte wtyczki. Skontaktuj się z nami lub sprawdź ofertę opieki WordPress i administracji serwerem.

Najczęstsze pytania o WordPress Cron

WP-Cron to wbudowany mechanizm WordPress do planowania zadań — publikowanie postów, backupy, aktualizacje, maile. Nie jest prawdziwym cronem — uruchamia się tylko przy ładowaniu strony przez użytkownika.

Każde ładowanie strony triggeruje sprawdzenie bazy danych pod kątem zadań cron. Na stronach z dużym ruchem to tysiące dodatkowych zapytań SQL. Konflikt z cache — strony cache'owane omijają PHP, więc cron się nie uruchamia.

Dodaj define('DISABLE_WP_CRON', true); w wp-config.php. Po wyłączeniu natychmiast skonfiguruj systemowy cron — inaczej zaplanowane zadania przestaną działać.

W crontab serwera (SSH lub panel hostingu) dodaj zadanie wywołujące wp-cron.php co 5–15 minut. Komenda: */15 * * * * wget -q -O - https://domena.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Tak — pod warunkiem konfiguracji systemowego crona jako zastępstwa. To podejście jest zalecane przez oficjalną dokumentację WordPress. Systemowy cron jest bardziej niezawodny i nie obciąża strony.

Porozmawiajmy o wydajności Twojej strony WordPress

Skonfigurujemy systemowy cron i zoptymalizujemy zaplanowane zadania. Bez zobowiązań — konkretna propozycja po analizie.

Telefon

+48 608 271 665

Pn–Pt, 8:00–16:00

E-mail

kontakt@weboptimo.pl

Odpowiadamy w ciągu 24h

Firma

WebOptimo

NIP: 6391758393