WordPress – одна з найпопулярніших CMS для створення сайтів. Для розміщення сайту на базі WordPress достатньо PHP хостингу з підтримкою MySQL. Проте для повноцінної роботи сайту важливо не лише забезпечити доступність сторінок, а й налаштувати автоматичне виконання регулярних завдань (перевірку оновлень WordPress і плагінів, створення резервних копій, очищення тимчасових даних, надсилання електронних листів і синхронізацію інформації із зовнішніми сервісами) таким чином, щоб це не створювало проблем відвідувачам.

У WordPress для цього передбачений власний механізм планування завдань – WP-Cron. Він дає змогу самому WordPress і встановленим плагінам реєструвати завдання та запускати їх у визначений час або через певні інтервали.

Однак WP-Cron має важливу особливість: він не працює постійно у фоновому режимі, як системний планувальник завдань Cron. Замість цього його запуск зазвичай відбувається під час відвідування сторінок сайту. Через це на сайтах із низькою відвідуваністю заплановані завдання можуть виконуватися із затримкою, а на ресурсах із великим трафіком часті запуски WP-Cron можуть створювати додаткове навантаження на сервер.

Що таке WP-Cron у WordPress

WP-Cron – це вбудований у WordPress механізм планування та запуску завдань.

Його використовують як сам WordPress, так і встановлені плагіни та теми. Наприклад, через WP-Cron можуть запускатися:

• публікація запланованих записів;
• перевірка оновлень WordPress;
• автоматичне очищення тимчасових даних;
• відправка електронних листів за розкладом;
• резервне копіювання;
• синхронізація з API сторонніх сервісів;
• генерація звітів;
• обробка фонових завдань WooCommerce.

Назва WP-Cron походить від сервіса “cron” – системного планувальника завдань. Проте технічно це різні механізми.

Як працює WP-Cron

Головна особливість WP-Cron полягає в тому, що він не працює постійно у фоні. Запуск WP-Cron відбувається кожного разу коли користувач або будь-який бот відкриває сторінку WordPress сайту. Коли на WordPress заходить користувач або бот, сам сайт перевіряє, чи є заплановані cron-завдання, час виконання яких уже настав. Якщо таке завдання є, WordPress намагається його запустити.

Саме ця модель відрізняє WP-Cron від системного cron.

Де WordPress зберігає cron-завдання ?

Інформація про заплановані завдання зберігається вбазі даних WordPress, зокрема в опції cron таблиці wp_options.

Під час роботи WordPress перевіряє ці дані та визначає, які завдання вже мають бути виконані.

На практиці це означає, що механізм запуску запланованих завдань безпосередньо пов’язаний із відвідуванністю WordPress сайту і запитами до нього.

Чому WP-Cron може запускатися із запізненням

Припустімо, що ви запланували публікацію статті на 08:00.

Якщо в цей час ніхто не відкриває сайт, WordPress не обов’язково виконає завдання саме о 08:00.

Якщо перший відвідувач прийде о 11:30, саме тоді WordPress може виявити прострочене завдання та запустити його.

Тобто WP-Cron гарантує не точний час запуску, а лише можливість виконання завдання після настання запланованого часу.

Для звичайного блогу це може бути непомітно. Але для інтернет-магазину або сайту, де важлива своєчасна обробка фонових операцій, затримки можуть стати проблемою.

Чому WP-Cron може уповільнювати WordPress

Сам по собі WP-Cron не означає, що сайт обов’язково буде повільним.

Проблеми виникають залежно від кількості відвідувачів, кількості запланованих завдань, конфігурації сервера та встановлених плагінів.

1. Додаткові перевірки під час запитів

Коли WordPress обробляє запит, він може перевіряти наявність cron-завдань, які потрібно виконати. На невеликому сайті це зазвичай не має великого значення. Але на ресурсах із великою кількістю запитів кількість таких перевірок також збільшується.

Якщо одночасно запускаються важкі cron-завдання, вони можуть створювати додаткове навантаження на:

• PHP;
• PHP-FPM;
• MySQL/MariaDB;
• CPU;
• оперативну пам’ять;
• дискову підсистему.

2. Проблеми на сайтах із низькою відвідуваністю

Парадоксально, але WP-Cron може бути проблемою не лише для великих сайтів.

На сайті з низьким трафіком cron-завдання можуть просто не запускатися вчасно.

Наприклад:

Публікацію записузаплановао на 10:00, але в цей час ніхоть не відвідує сайт через що завдання не публікується вчасно. Коли о 15:00 на сайт заходить пошуковий бот або звичайний користувач, WordPress запускає wp-cron і публікує статтю.

Для контентного сайту це може бути прийнятно. Для автоматизованих бізнес-процесів – вже ні.

3. WP-Cron і кешування сторінок

Сучасні WordPress-сайти часто використовують кешування сторынок.

У такій конфігурації запит користувача може взагалі не доходити до PHP і WordPress – сервер або CDN просто повертає готову HTML-сторінку.

Через це запуск WP-Cron через відвідування стає менш передбачуваним.

Особливо це актуально для сайтів, де більшість сторінок віддається з кешу.

4. Важкі cron-завдання

Проблема може бути не в самому механізмі WP-Cron, а в тому, що саме запускається через нього.

Наприклад, плагін може виконувати:

• імпорт тисяч товарів;
• синхронізацію каталогу;
• генерацію великого звіту;
• масову відправку електронних листів;
• резервне копіювання;
• очищення великої кількості записів.

Якщо таке завдання запускається під час звичайного користувацького запиту, воно потенційно може вплинути на його продуктивність.

Порівняння WP-Cron та системного сервісу Cron

Головна відмінність полягає у способі запуску.

Наприклад, сервер може запускати процес який буде перевіряти наявність запланованих завдань кожні 5 або 15 хвилин і запускати їх якщо такі завдання будуть.

Як вимкнути WP-Cron у WordPress

Якщо ви вирішили використовувати системний планувальних завдань, спочатку потрібно вимкнути автоматичний запуск WP-Cron.

Для цього, відкрийте файл wp-config.php і додайте такий рядок:

define('DISABLE_WP_CRON', true);

будь де між наведеними нижче рядками:

<?php

...
/* That's all, stop editing! Happy publishing. */

Як налаштувати системний планувальних завдань для WordPress

Сучасний хостинг дозволяє налаштувати запуск завдань за розкладом через панель керування. Якщо на вашому хостингу використовується панель керування cPanel або DirectAdmin, тоді все що вам залишається це увійти в панель керування хостингом і налаштувати завдання:

• Обрати розклад за яким запускати завдання.
• Вказати команду яка має запускатись.

Для WordPress команда має бути такого вигляду:

wget -q -O - https://DOMAIN.COM/wp-cron.php?doing_wp_cron >/dev/null 2>&1

(не забудьте замінити DOMAIN.COM на доменне ім’я вашого сайту).

Як часто запускати WordPress Cron

Універсального значення немає. Для звичайного корпоративного сайту або блогу можна почати з запуску завдання кожні 15 хвилин.

Для активного магазину WooCommerce можливо знажобиться встановити запуск завдання кожні 5 хвилин.

А для сайтів із критичними фоновими процесами інтервал може бути ще меншим.

Водночас немає сенсу запускати cron щохвилини лише “для швидкості”. Частота повинна відповідати реальним потребам сайту т.я. чим частіше виконується перевірка, тим більше сайт використовує ресурсів в цілому.

Як перевірити, чи працює WordPress Cron

Після налаштування системного cron важливо перевірити результат.

Один із найзручніших інструментів – плагін WP Crontrol.

За його допомогою можна побачити:

• список запланованих подій;
• час наступного запуску;
• час попереднього запуску;
• частоту повторення;
• коллбек (callback), який виконується;
• можливі проблеми із cron-завданнями.

Після переходу на системний планувальник завдант рекомендується кілька днів перевіряти роботу сайту.

Особливо варто переконатися, що:

• заплановані записи публікуються;
• резервне копіювання працює;
• надсилаються електронні листи;
• WooCommerce виконує свої фонові завдання;
• сторонні інтеграції синхронізуються;
• cron-події не накопичуються.

Кому особливо варто замінити WP-Cron

Інтернет-магазинам WooCommerce

WooCommerce може мати велику кількість фонових завдань.

Для магазинів із високою активністю контрольований запуск cron-завдань особливо важливий.

Сайтам із великим трафіком

Якщо сайт отримує тисячі запитів на день, має сенс прибрати залежність cron від звичайних відвідувань.

Сайтам із агресивним кешуванням

Якщо більшість сторінок віддається з кеша сторінок або CDN, системний cron дозволяє запускати заплановані завдання незалежно від кешу.

WordPress Multisite

На Multisite кількість фонових завдань може збільшуватися разом із кількістю сайтів.

У великих інсталяціях централізований контроль cron стає особливо корисним.

Чи потрібно вимикати WP-Cron на кожному WordPress-сайті?

Коротка відповідь: Ні.

Для невеликого сайту з невеликою кількістю плагінів стандартний WP-Cron часто працює цілком нормально.

Не варто змінювати конфігурацію лише тому, що “WP-Cron повільний”.

Краще оцінити:

• кількість cron-завдань;
• їхню тривалість;
• навантаження на сервер;
• кількість відвідувачів;
• використання кешування;
• вимоги до точності виконання завдань.

Якщо сервер має достатньо ресурсів і проблем із wp-cron немає, заміна може не дати помітного результату.

WP-Cron – корисний і простий механізм, але він не є повноцінною заміною системному cron.

Його головний недолік полягає в тому, що виконання завдань прив’язане до активності сайту.

Для невеликих сайтів це часто не створює проблем. Але для великих WordPress-проектів, WooCommerce-магазинів, сайтів із кешуванням сторінок та сайтів на базі WordPress Multisite системний планувальних завдань може бути значно надійнішим рішенням.

Таким сайтам ми радимо використовувати саме системний cron.

Такий підхід дозволить відокремити виконання фонових завдань від звичайних відвідувань сайту та отримати кращий контроль над тим, коли саме запускаються завдання, а також значно зменшити використання системних ресурсів які надаються в межах вашого тарифу хостингу.