WordPress Heartbeat API — встроенный механизм периодических AJAX-запросов, который позволяет странице админки обмениваться данными с сервером почти в реальном времени. Он участвует в системных функциях и может использоваться плагинами. Поэтому совет «просто отключить Heartbeat» часто решает симптом, но создаёт новые проблемы.
Если в логах много запросов к wp-admin/admin-ajax.php, правильная последовательность другая: определить action, понять частоту и источник, измерить реальную стоимость запроса, а затем ограничивать только лишнюю активность.
Как работает Heartbeat API
Официальная документация WordPress описывает Heartbeat как polling API. После загрузки страницы клиент запускает периодический tick, собирает данные и отправляет их на сервер. Интервал может находиться примерно в диапазоне от 15 до 120 секунд. Серверный обработчик получает данные через AJAX, формирует ответ и возвращает JSON.
Это не cron и не фоновая задача в привычном смысле. Heartbeat возникает из открытой страницы браузера. Если пять редакторов держат несколько вкладок админки, количество запросов растёт вместе с числом вкладок.
Почему admin-ajax.php сам по себе ничего не доказывает
admin-ajax.php используется не только Heartbeat. Через него работают формы, фильтры, поиск, обновление виджетов, плагины статистики и множество кастомных функций. Поэтому высокий процент запросов к этому URL ещё не означает, что виноват именно Heartbeat.
В DevTools Network, access log или APM нужно смотреть payload и параметр action. Для Heartbeat это обычно heartbeat. Если нагрузку создаёт другой action, изменение heartbeat interval не даст результата.
Когда Heartbeat действительно создаёт заметную нагрузку
- много редакторов одновременно работают в админке;
- открыто много вкладок редактирования;
- плагин добавляет тяжёлую обработку в heartbeat hooks;
- сервер уже работает близко к лимиту CPU/PHP workers;
- запрос выполняет тяжёлые SQL-запросы или внешние API-вызовы;
- интервал искусственно уменьшен сторонним кодом.
Сам факт одного короткого heartbeat-запроса раз в минуту обычно менее важен, чем один плагин, который на каждом tick запускает большой запрос к базе.
Почему полное отключение может быть плохой идеей
Heartbeat используется для функций совместного редактирования и уведомлений, а плагины могут добавлять собственные данные через события heartbeat-send, heartbeat_received и heartbeat-tick. Жёсткое отключение во всей админке способно нарушить ожидаемое поведение редактора или расширений.
Перед отключением нужно проверить autosave, блокировку записи при одновременном редактировании, WooCommerce-экран, конструкторы и плагины, которые работают в реальном времени. Особенно осторожно — на сайтах, где несколько сотрудников редактируют контент параллельно.
Безопаснее сначала увеличить интервал
WordPress предоставляет фильтр heartbeat_settings. Он позволяет изменить интервал, не вырезая API полностью.
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60;
return $settings;
} );
Значение нужно выбирать по тестам. 60 секунд часто используют как умеренный пример, но универсального числа нет. Если плагин ожидает более частый обмен, слишком большой интервал ухудшит его работу.
Настраивайте по экрану, а не глобально
Лучший вариант — не применять одно правило ко всему WordPress. На экране редактирования записи Heartbeat может быть полезнее, чем на странице настроек, где пользователь просто читает таблицу. Поэтому оптимизацию стоит привязывать к контексту админки и тестировать по ролям.
Если нагрузка идёт только из frontend-функции конкретного плагина, изменение backend-интервала тоже не решит задачу. Нужно найти место, где скрипт подключается, и понять, зачем ему Heartbeat.
Как найти тяжёлый обработчик
- Отфильтровать запросы
admin-ajax.phpв access log. - Разделить их по
action. - Замерить время ответа и частоту.
- Временно отключить подозрительный плагин на staging.
- Проверить SQL через Query Monitor или APM.
- Посмотреть hooks
heartbeat_receivedиheartbeat_nopriv_receivedв кастомном коде.
Если после отключения одного расширения heartbeat падает с 800 мс до 80 мс, проблема не в самом API, а в обработчике этого расширения.
Не путайте Heartbeat и WP-Cron
Heartbeat запускается открытым браузером, WP-Cron — посещениями сайта и расписанием событий, а Action Scheduler обслуживает отдельные фоновые очереди WooCommerce и плагинов. У этих механизмов разные причины нагрузки и разные способы диагностики.
Если проблема связана с очередями магазина, полезнее проверить WP-Cron и Action Scheduler в WooCommerce, а не менять Heartbeat.
Что смотреть на сервере
Для PHP-FPM важны количество занятых workers, среднее время запроса, slow log и пики CPU. В nginx/Apache — частота admin-ajax.php, коды ответов и время обработки. В MySQL — медленные запросы и блокировки.
Если каждый heartbeat быстрый, но их слишком много, помогает увеличение интервала и уменьшение числа ненужных вкладок. Если запросов мало, но каждый занимает секунды, нужно профилировать PHP/SQL.
Можно ли кэшировать admin-ajax.php
Обычный page cache здесь не подходит: AJAX-ответ может зависеть от пользователя, nonce, сессии и текущего состояния. Агрессивное CDN-кэширование admin-ajax.php способно вернуть чужой или устаревший ответ. Оптимизировать нужно вычисления внутри action, а не маскировать их page cache.
Практический чек-лист
- подтверждён именно action=heartbeat, а не другой AJAX action;
- измерены количество запросов и время ответа;
- проверены PHP-FPM, CPU и MySQL;
- найдены плагины и hooks, которые добавляют обработку;
- интервал меняется только после замера;
- на staging проверены autosave и редактирование;
- не включено опасное кэширование admin-ajax;
- после обновлений WordPress и плагинов метрики проверяются повторно.
Что делать, если admin-ajax перегружает production
Если сайт уже тормозит, не начинайте с удаления Heartbeat-скрипта из ядра. Сначала ограничьте диагностическое окно: соберите 10–30 минут логов, сгруппируйте actions и найдите самые дорогие запросы. После этого можно точечно изменить интервал, код плагина или собственный handler.
Для сложных случаев полезен отдельный аудит и доработка WordPress: профилирование PHP, SQL и JavaScript обычно быстрее показывает источник нагрузки, чем случайное отключение системных функций. Если требуется кастомная логика, её лучше реализовать через нормальные WordPress hooks, а не изменять core.
Когда оптимизация Heartbeat реально окупается
Она особенно полезна на редакционных сайтах, WooCommerce с большим штатом менеджеров, LMS и проектах со сложной админкой. Но эффект нужно считать по метрикам: сколько PHP-seconds и запросов к базе экономится в час. Если доля Heartbeat мала, приоритет лучше отдать медленным шаблонам, REST/AJAX handler-ам, базе данных или внешним API.
A.S Groups может провести техническую диагностику WordPress, найти источник нагрузки admin-ajax.php, оптимизировать Heartbeat и плагины без потери редакторских функций. Для проекта с постоянными доработками можно начать со страницы WordPress-разработчика.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.