Вы когда-нибудь замечали, что ваш сайт на WordPress вдруг начинает тормозить ровно в тот момент, когда вы публикуете пост или кто-то оставляет комментарий?
Я помню случай из практики: клиент жаловался, что его интернет-магазин «вылетает» каждый час. Мы полезли в логи — и обнаружили, что WP-Cron запускает проверку обновлений плагинов, отправляет письма о просроченных заказах и одновременно пытается оптимизировать базу данных. Всё это — в один момент, когда на сайт заходит очередной посетитель.
Знакомая ситуация? Давайте разберёмся, как приручить планировщик задач и не потерять клиентов из-за медленной загрузки.
Почему WP-Cron — это не совсем «крон»
Если вы хоть раз заглядывали в файл wp-config.php, то наверняка видели упоминание WP_CRON. Многие думают, что это аналог системного планировщика в Linux. Но на самом деле это не так.
WP-Cron — это имитация. Он срабатывает не по расписанию, а при каждом посещении сайта. Да-да, каждый раз, когда кто-то заходит на ваш сайт, WordPress проверяет: «А не пора ли мне выполнить какую-нибудь задачу?» И если пора — выполняет её прямо здесь и сейчас.
Представьте, что вы приходите в офис, а ваш сотрудник вместо того, чтобы встретить вас, начинает мыть полы, пылесосить и перекладывать бумаги. Вроде бы полезные дела, но не тогда, когда вам нужно срочно что-то получить от него.
Как работает WP-Cron и в чём его слабость
По умолчанию WordPress использует именно этот механизм. И для маленького блога с парой посетителей в день — это нормально. Но для бизнес-сайта, особенно интернет-магазина, такой подход становится проблемой.
Вот как это выглядит на практике:
- Посетитель заходит на страницу товара.
- WordPress запускает проверку WP-Cron.
- Если накопилось несколько задач (отправка писем, обновление кеша, проверка лицензий), они выполняются последовательно.
- Посетитель ждёт, пока все задачи завершатся.
- Если задач много — сайт «висит» 5-10 секунд.
А теперь представьте, что это происходит в час пик, когда на сайте 100 человек. Каждый из них запускает свой собственный «цикл уборки». В итоге сервер захлёбывается.
Что такое системный cron и почему он выгоднее
Системный cron — это настоящий планировщик задач на уровне сервера. Он работает так:
- Вы задаёте точное время выполнения задачи (например, каждый час в 15 минут).
- Сервер выполняет её строго по расписанию, независимо от того, есть ли посетители на сайте.
- Никто из пользователей не ждёт завершения задачи.
Разница колоссальная: с WP-Cron задачи выполняются «за компанию» с посетителем, а с системным — в фоне, без влияния на скорость загрузки.
Когда WP-Cron ещё можно терпеть
Я не буду говорить, что WP-Cron — абсолютное зло. Есть ситуации, когда его можно оставить:
- У вас сайт-визитка с 50-100 посетителями в день.
- Вы используете минимум плагинов, которые создают фоновые задачи.
- У вас нет критичных по времени процессов (например, не нужно отправлять письма строго раз в 10 минут).
Но если у вас интернет-магазин, каталог с тысячами товаров или сайт с регулярными публикациями — лучше перейти на системный cron.
Как отключить WP-Cron и настроить системный
Процесс настройки состоит из двух шагов. Ничего сложного, но будьте внимательны.
Шаг 1. Отключаем WP-Cron
Добавьте в файл wp-config.php (перед строкой «That’s all, stop editing!») следующую строку:
define('DISABLE_WP_CRON', true);
После этого WordPress перестанет проверять задачи при каждом посещении. Но сами задачи никуда не денутся — они будут ждать выполнения.
Шаг 2. Настраиваем системный cron
Теперь нужно заставить сервер выполнять задачи по расписанию. Если у вас хостинг с панелью управления (например, ISPmanager или cPanel), найдите раздел «Cron tasks» или «Планировщик задач».
Добавьте задачу, которая будет запускать файл wp-cron.php каждые 5-15 минут (зависит от ваших потребностей). Команда выглядит так:
wget -q -O - https://вашсайт.ru/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Или, если у вас доступ к командной строке:
curl -s https://вашсайт.ru/wp-cron.php >/dev/null 2>&1
Важный нюанс: не ставьте слишком частый интервал. Если вы будете запускать cron каждую минуту, а задач нет — это лишняя нагрузка. Для большинства сайтов достаточно 5-10 минут.
Шаг 3. Проверяем работу
После настройки откройте сайт — он должен грузиться быстрее. Чтобы убедиться, что cron работает, можно установить плагин WP Crontrol или Advanced Cron Manager. Они покажут, какие задачи выполняются и когда в последний раз запускался cron.
Какой интервал выбрать для разных типов задач
Не все задачи одинаково важны. Я рекомендую настроить несколько cron-задач с разными интервалами:
Каждые 5 минут:
- Проверка новых комментариев и отправка уведомлений
- Обработка очередей писем (если используете кеширование писем)
- Проверка статусов заказов
Каждые 15-30 минут:
- Автоматическая оптимизация базы данных
- Проверка обновлений плагинов и тем
- Создание резервных копий (если не используете внешний сервис)
Раз в час или реже:
- Генерация отчётов
- Отправка массовых рассылок
- Синхронизация с внешними сервисами
Что делать, если у вас нет доступа к серверу
Бывает, что клиентский хостинг не даёт возможности настроить системный cron. Или вы работаете с дешёвым shared-хостингом, где такая опция платная.
Выход есть: используйте внешние сервисы мониторинга, например, cron-job.org или EasyCron. Они будут «стучаться» на ваш сайт по расписанию и запускать wp-cron.php.
Минус: вы зависите от внешнего сервиса. Если он упадёт — cron не сработает. Но для небольших проектов — отличное решение.
Типичные ошибки при настройке cron
Я видел несколько распространённых ошибок, которые совершают владельцы сайтов:
1. Забывают отключить WP-Cron.
Если вы настроили системный cron, но не отключили WP-Cron — задачи будут выполняться дважды. Один раз — при посещении, второй — по расписанию. Это двойная нагрузка.
2. Слишком частый запуск.
Запуск cron каждую минуту для сайта с 10 посетителями в день — это перебор. Сервер будет тратить ресурсы на проверку, а задач нет.
3. Неправильный путь к wp-cron.php.
Если вы указали неверный URL, cron не сработает, а задачи будут накапливаться. Проверяйте логи.
4. Игнорируют кеширование.
Если у вас включено кеширование, убедитесь, что cron-запросы не попадают в кеш. Иначе задачи могут не выполняться. Обычно это решается добавлением параметра ?doing_wp_cron в URL.
Реальный пример: как мы ускорили интернет-магазин
Расскажу про случай, который упоминал в начале. Клиент — интернет-магазин автозапчастей. Каталог — 15 000 товаров. Посещаемость — около 2 000 человек в день.
Проблема: сайт периодически «зависал» на 10-15 секунд. Мы посмотрели логи — в эти моменты WP-Cron запускал:
- Проверку обновлений для 30 плагинов
- Отправку писем о статусах заказов (около 50 писем раз в час)
- Автоматическое создание резервной копии базы данных (весом 200 МБ)
Представляете? Посетитель хочет купить запчасть, а сервер в это время создаёт бекап.
Что мы сделали:
Результат: средняя скорость загрузки страниц выросла с 4.2 секунд до 1.8 секунд. Отказов стало меньше на 15%.
Когда стоит доверить настройку профессионалам
Настройка cron — это не rocket science, но есть нюансы. Если вы не уверены в своих силах или боитесь что-то сломать — лучше обратиться к специалистам.
Признаки, что пора звать профессионала:
- У вас сложный проект с кастомными плагинами
- Вы не знаете, какие задачи создают ваши плагины
- На сайте уже есть проблемы с производительностью
- У вас нет доступа к серверу или командной строке
В таких случаях проще заплатить за настройку один раз, чем потом разбираться с последствиями.
Что в итоге
Системный cron — это базовая настройка для любого бизнес-сайта на WordPress. Он даёт:
- Скорость. Посетители не ждут выполнения фоновых задач.
- Стабильность. Задачи выполняются строго по расписанию, без сюрпризов.
- Меньше нагрузки. Сервер не захлёбывается в час пик.
Если ваш сайт уже тормозит или вы замечаете странные «подвисания» — начните с проверки cron. Возможно, это именно то, что вас тормозит.
А если нужна помощь с настройкой — обращайтесь. Мы в Wenesis занимаемся оптимизацией WordPress-сайтов и поможем настроить всё правильно, без риска для бизнеса.
Добавить комментарий