WP-Cron i cron serwerowy rozwiązują podobny problem, ale działają inaczej. Domyślnie WP-Cron jest sprawdzany i inicjowany przy ruchu do witryny, natomiast cron systemowy wykonuje zadania według harmonogramu serwera. Przy małej stronie WP-Cron często wystarcza, ale przy zadaniach wymagających większej przewidywalności warto rozważyć uruchamianie zadań WordPressa z crona serwerowego.
Najważniejsze pytanie nie brzmi więc „który cron jest szybszy?”, lecz jak często zadania muszą się uruchamiać, co się stanie przy małym ruchu, jak długo trwa pojedyncze zadanie i jakie ograniczenia nakłada hosting.
Jak działa WP-Cron?
WP-Cron nie jest klasycznym demonem systemowym działającym stale w tle. WordPress sprawdza zaplanowane zdarzenia podczas obsługi ruchu do witryny i wtedy inicjuje wykonanie zadań, których termin już minął. Mechanizm ten jest częścią WordPressa i służy do planowania zdarzeń w aplikacji.
Ma to ważną konsekwencję: jeżeli nikt nie odwiedza strony przez dłuższy czas, zadanie może zostać wykonane później niż wskazuje jego planowany czas.
WP-Cron nie gwarantuje więc uruchomienia dokładnie o 02:00:00. Traktuj zaplanowaną godzinę jako moment, po którym zadanie staje się gotowe do wykonania.
Jak działa cron serwerowy?
Cron systemowy uruchamia polecenia według harmonogramu niezależnego od wizyt użytkowników. Może na przykład co kilka minut wywołać mechanizm WordPressa odpowiedzialny za zadania, dzięki czemu strona nie musi czekać na kolejne wejście użytkownika.
Na hostingu współdzielonym użytkownik zwykle zarządza zadaniami przez panel, a nie przez pełny systemowy `crontab`. Zakres dostępnych poleceń, minimalny interwał i liczba zadań zależą od operatora.
Sam cron serwerowy nie zastępuje WP-Cron jako systemu zdarzeń WordPressa. Najczęściej służy do regularnego uruchamiania mechanizmu, który następnie wykonuje zdarzenia zapisane przez WordPress i wtyczki.
WP-Cron a cron serwerowy — najważniejsze różnice
| Kryterium | WP-Cron | Cron serwerowy |
|---|---|---|
| Wyzwalanie | Zależne od ruchu i działania WordPressa | Według harmonogramu serwera |
| Mały ruch | Zadania mogą się opóźniać | Harmonogram działa niezależnie od wejść |
| Dokładność | Nie gwarantuje wykonania dokładnie o wskazanej sekundzie | Zależy od harmonogramu i ograniczeń crona operatora |
| Konfiguracja | Działa domyślnie w WordPressie | Wymaga utworzenia zadania po stronie hostingu/serwera |
| Awaria aplikacji | Może nie uruchomić zadania, jeśli WordPress nie działa prawidłowo | Cron może wystartować, ale samo zadanie WordPressa nadal może zakończyć się błędem |
Kiedy WP-Cron zwykle wystarcza?
Dla niewielkiej strony firmowej lub bloga, na którym zaplanowane zadania nie muszą wykonywać się co do minuty, domyślny WP-Cron może być wystarczający.
Przykładowo kilkuminutowe opóźnienie publikacji zaplanowanego wpisu może nie mieć znaczenia, jeśli serwis ma regularny ruch i nie wykonuje krytycznych automatyzacji.
Nie warto zmieniać konfiguracji tylko dlatego, że „cron serwerowy jest bardziej profesjonalny”. Najpierw ustal, czy występuje realny problem z terminowością lub obciążeniem.
Kiedy cron serwerowy ma większy sens?
Warto go rozważyć, gdy:
- strona ma mały lub nieregularny ruch, a zadania powinny wykonywać się regularnie,
- działają importy, synchronizacje lub automatyczne publikacje,
- WooCommerce i jego rozszerzenia wykonują zaplanowane procesy w tle,
- backup lub integracja zewnętrzna ma uruchamiać się według przewidywalnego harmonogramu,
- chcesz uniezależnić inicjowanie zadań od wejść użytkowników.
Cron serwerowy poprawia przewidywalność samego uruchomienia, ale nie gwarantuje, że zadanie zakończy się szybko ani poprawnie.
Czy trzeba wyłączyć domyślny WP-Cron?
Jeżeli zewnętrzny cron regularnie uruchamia zadania WordPressa, często wyłącza się automatyczne wyzwalanie WP-Cron przy ruchu, aby nie inicjować tego samego mechanizmu dodatkowo z wejść użytkowników.
WordPress udostępnia do tego stałą DISABLE_WP_CRON. Po jej ustawieniu automatyczne uruchamianie WP-Cron przy żądaniach strony zostaje wyłączone.
Nie ustawiaj jednak DISABLE_WP_CRON przed skonfigurowaniem działającego mechanizmu zastępczego. W przeciwnym razie zaplanowane zdarzenia mogą przestać być regularnie uruchamiane.
Jak często uruchamiać cron serwerowy?
Nie ma jednego poprawnego interwału dla wszystkich stron. Harmonogram powinien wynikać z tego, jak szybko zadania muszą reagować i jakie limity nakłada hosting.
Jeśli chcesz przygotować lub sprawdzić pięciopolowe wyrażenie cron, możesz skorzystać z generatora cron.
Jeżeli cron uruchamia WordPress co 5 minut, zdarzenie gotowe chwilę po poprzednim przebiegu może zacząć się dopiero przy kolejnym wywołaniu. Z kolei bardzo częste uruchamianie nie przyspieszy zadania, które samo trwa kilka minut.
Przed ustawieniem interwału sprawdź:
- minimalną częstotliwość dozwoloną przez operatora,
- typowe czasy wykonywania zadań,
- czy kolejne uruchomienie może nastąpić przed zakończeniem poprzedniego,
- czy aplikacja ma własny mechanizm blokady lub kolejki.
Przykład potwierdzonego parametru: dla planu Start Web Hosting dhosting.pl zapisane dane potwierdzają dostępność crona i minimalny interwał 1 minuty. Nie przesądza to o czasie wykonania ani wydajności samego zadania. Sprawdź aktualne warunki planu (link partnerski).
Cron nie naprawi wolnego zadania
Jeżeli import trwa 20 minut, przejście z WP-Cron na cron serwerowy nie sprawi automatycznie, że potrwa 2 minuty. Nadal działają limity CPU, pamięci, PHP workers, czasu wykonania, I/O i IOPS.
Zewnętrzny harmonogram rozwiązuje przede wszystkim problem kiedy zadanie zostaje zainicjowane. Nie rozwiązuje automatycznie problemu jak drogie jest jego wykonanie.
Jeżeli zadanie regularnie przeciąża konto, sprawdź limity hostingu oraz PHP workers.
WooCommerce, kolejki i zadania w tle
WooCommerce i wiele jego rozszerzeń korzysta z Action Scheduler — osobnej kolejki zadań działającej obok mechanizmu WP-Cron. Domyślnie jej przetwarzanie jest inicjowane m.in. przez WP-Cron, dlatego regularny cron serwerowy może poprawić terminowość startu, ale nie naprawi rosnącej kolejki, błędnego zadania ani braku zasobów.
Dlatego przy problemie typu „zadania WooCommerce się opóźniają” nie wystarczy sprawdzić wyłącznie sam harmonogram crona. Trzeba również ustalić, czy kolejka Action Scheduler rośnie, czy zadania kończą się błędem i czy hosting zapewnia wystarczające zasoby do ich wykonania.
Cron a backupy, importy i ciężkie operacje
Automatyczne uruchomienie ciężkiego zadania w nocy nie oznacza, że zadanie jest bezkosztowe. Backup, import lub generowanie plików może intensywnie używać CPU i dysku także wtedy, gdy witrynę odwiedza mniej użytkowników.
Jeżeli kilka zadań startuje o tej samej porze, ich obciążenie może się sumować. Warto więc rozdzielić harmonogramy zamiast ustawiać wszystkie procesy np. dokładnie o północy.
Przy zadaniach dyskowych przydatne jest rozróżnienie opisane w poradniku o I/O i IOPS.
Cron a staging
Po skopiowaniu produkcji na staging mogą zostać również skopiowane ustawienia zadań, integracji i automatyzacji. Jeżeli środowisko testowe zacznie wykonywać te same procesy co produkcja, może wysłać wiadomości, uruchomić import albo połączyć się z zewnętrznym API.
Dlatego na stagingu trzeba osobno sprawdzić aktywne zadania i integracje. Sam fakt, że adres strony jest testowy, nie wyłącza automatyzacji.
Więcej o tym ryzyku opisuje poradnik o stagingu WordPress.
Co sprawdzić w ofercie hostingu?
Przy wyborze hostingu zapytaj:
- czy możesz tworzyć własne zadania cron,
- jaki jest minimalny dozwolony interwał,
- ile zadań cron można utworzyć,
- czy dostępne jest PHP CLI i jaka wersja PHP jest używana przez cron,
- czy cron może wywoływać lokalny skrypt bez publicznego żądania HTTP,
- czy obowiązują limity czasu wykonania lub równoległości,
- gdzie można zobaczyć wynik, log albo błąd zadania.
Samo „cron: tak” nie wystarcza do oceny funkcji. Dwa hostingi mogą udostępniać cron, ale mieć zupełnie inne ograniczenia częstotliwości, liczby zadań i dostępnych poleceń.
Gotowe pytanie do operatora
Czy w tym pakiecie mogę uruchamiać zadania WordPressa z crona serwerowego? Proszę podać minimalny interwał, limit liczby zadań, dostępną wersję PHP CLI oraz sposób sprawdzania logów i błędów. Czy zadanie może lokalnie uruchamiać PHP/WordPress bez publicznego wywołania HTTP i czy obowiązują dodatkowe limity czasu wykonania lub równoległości?
WP-Cron czy cron serwerowy — co wybrać?
WP-Cron wystarcza, gdy zadania nie wymagają dużej precyzji, a strona ma regularny ruch. Cron serwerowy jest bardziej użyteczny, gdy chcesz przewidywalnie inicjować zadania niezależnie od odwiedzin.
Nie traktuj jednak crona serwerowego jako rozwiązania problemów wydajnościowych. Jeżeli zadanie jest ciężkie, blokuje PHP albo dobija do limitów, trzeba diagnozować samo zadanie i zasoby hostingu.
W praktyce dobry hosting powinien nie tylko pozwalać utworzyć cron, ale też jasno określać jego interwał, limity i sposób diagnostyki.