Как отключить WordPress Heartbeat API на админке и сайте

Heartbeat API в WordPress часто всплывает не как отдельная проблема, а как причина лишней нагрузки: в админке растёт число AJAX-запросов, редактор подтормаживает, на слабом хостинге появляются лишние обращения к admin-ajax.php. Полностью выключать его не всегда разумно: часть функций редактора, автосохранение и уведомления в панели завязаны на этот механизм.

Поэтому задача обычно не в том, чтобы «убить всё», а в том, чтобы отключить Heartbeat там, где он не нужен, и оставить его в местах, где он реально помогает. Ниже — рабочие варианты для админки, фронтенда и отдельных экранов.

Когда Heartbeat API действительно мешает

Проблема заметна по конкретным симптомам. Если в панели администратора постоянно идут запросы к admin-ajax.php, а в DevTools видно повторяющиеся вызовы с действием heartbeat, это нормальное поведение Heartbeat. Ненормальным оно становится, когда сайт работает на ограниченных ресурсах или когда открыто много вкладок с редактором и списками записей.

Типичные признаки

• в админке заметно дёргается интерфейс при редактировании записей;
• на сервере растёт число коротких AJAX-запросов;
• на shared-хостинге появляются пики CPU без видимой причины;
• в редакторе блоков автосохранение работает, но нагрузка слишком высокая для текущего проекта.

Если сайт маленький и нагрузка не критична, лучше не трогать Heartbeat без причины. Если же вы уже упираетесь в лимиты хостинга, ограничение частоты или отключение на части страниц — нормальная техническая мера.

Как диагностировать источник нагрузки

Сначала убедитесь, что проблема именно в Heartbeat, а не в другом AJAX-механизме. Для этого откройте инструменты разработчика в браузере, перейдите на вкладку Network и отфильтруйте запросы по admin-ajax.php. Если среди них регулярно повторяется действие heartbeat, вы нашли источник.

На сервере полезно посмотреть логи доступа. Если есть доступ к shell, можно быстро проверить частоту обращений:

grep "admin-ajax.php" /var/log/nginx/access.log | tail -n 50

Если логов много, ищите повторяющиеся запросы с коротким интервалом. Это не доказывает, что виноват только Heartbeat, но помогает отделить его от тяжёлых запросов плагинов или темы.

Что лучше: отключить полностью или ограничить частоту

В большинстве случаев безопаснее не отключать Heartbeat глобально, а ограничить его там, где он не нужен. Для сравнения:

Если вам нужен предсказуемый результат, лучше использовать код и ограничить Heartbeat только в админке или только на фронтенде. Для большинства проектов этого достаточно.

Пошаговое решение через код

Самый практичный вариант — подключить небольшой сниппет в functions.php дочерней темы или, что надёжнее, в mu-plugin. Так код не потеряется при смене темы.

Вариант 1: отключить Heartbeat на фронтенде

Этот вариант подходит, если вам не нужны публичные AJAX-проверки, а основная нагрузка идёт именно с сайта для посетителей. Админка при этом остаётся без изменений.

add_action( 'init', function () {
	if ( ! is_admin() ) {
		wp_deregister_script( 'heartbeat' );
	}
} );

Этот способ простой, но не всегда идеальный: если какой-то плагин на фронтенде ожидает Heartbeat, он может начать вести себя нестабильно. Поэтому после внедрения обязательно проверьте ключевые страницы.

Вариант 2: ограничить частоту Heartbeat в админке

Если полностью отключать не хочется, можно увеличить интервал между запросами. Это снижает частоту обращений без потери базовой функциональности.

add_filter( 'heartbeat_settings', function ( $settings ) {
	$settings['interval'] = 60;
	return $settings;
} );

Значение 60 — это не универсальная норма, а рабочая отправная точка. Для редакторов с активной совместной работой лучше оставить более частый интервал, а для обычной админки можно поднять его выше.

Вариант 3: отключить Heartbeat на конкретных экранах админки

Это самый аккуратный сценарий. Например, можно убрать Heartbeat со страниц списка записей, но оставить его в редакторе, где автосохранение полезно.

add_action( 'admin_enqueue_scripts', function ( $hook ) {
	$disabled_screens = array( 'edit.php', 'upload.php' );

	if ( in_array( $hook, $disabled_screens, true ) ) {
		wp_deregister_script( 'heartbeat' );
	}
} );

Здесь важно понимать, что значение $hook зависит от конкретного экрана. Если вы не уверены, сначала выведите его в лог или проверьте на тестовом сайте.

Как проверить, что решение сработало

После внедрения не ограничивайтесь субъективным ощущением «стало быстрее». Проверьте результат по нескольким признакам:

• в Network стало меньше повторяющихся запросов к admin-ajax.php;
• на страницах, где Heartbeat отключён, больше не видно действия heartbeat;
• редактор и автосохранение продолжают работать там, где вы их оставили;
• в логах сервера снизилось число коротких AJAX-обращений.

Если вы ограничивали частоту, сравните интервал между запросами до и после изменения. Если полностью отключали — убедитесь, что не пропали функции, которые зависят от Heartbeat в вашей конфигурации.

Частые ошибки и как их исправить

Отключили Heartbeat везде и сломали редактор

Это самая частая ошибка. Пользователь видит, что нагрузка снизилась, но потом обнаруживает проблемы с автосохранением или уведомлениями в панели. Исправление простое: не отключайте скрипт глобально, если не проверили, какие экраны и плагины его используют.

Добавили код в родительскую тему

После обновления темы сниппет пропадает. Если решение нужно надолго, используйте дочернюю тему или mu-plugin. Для технических правок это надёжнее и чище.

Путают Heartbeat с обычным AJAX плагинов

Если на сайте много AJAX-функций, отключение Heartbeat не уберёт все запросы. Сначала смотрите, что именно уходит в admin-ajax.php, и только потом меняйте код. Иначе можно потратить время на не ту проблему.

Ставят слишком агрессивный интервал

Если увеличить интервал слишком сильно, часть интерфейса в админке может стать менее отзывчивой. Для рабочих сайтов лучше тестировать изменения поэтапно: сначала 30–60 секунд, потом смотреть на поведение редактора и панели.

Практические советы по безопасности и производительности

Heartbeat API сам по себе не является уязвимостью, но он создаёт дополнительную точку нагрузки. На слабом хостинге это может стать заметно быстрее, чем любая «косметическая» оптимизация. Если вы уже чистите сайт от дублей, лишних скриптов и тяжёлых запросов, Heartbeat логично рассматривать в том же наборе технических правок.

• не отключайте его на боевом сайте без теста на staging;
• если используете кэш-плагины, проверьте, не конфликтует ли их логика с админскими AJAX-запросами;
• не правьте ядро WordPress — используйте фильтры и действия;
• если нужен быстрый контроль без кода, можно посмотреть в сторону плагинов для технической оптимизации, например Clearfy Pro, но перед установкой проверяйте, что именно он меняет в вашей конфигурации.

Если задача сводится к снижению нагрузки в админке, начните с ограничения частоты. Полное отключение оставляйте как крайний вариант для узких сценариев, где вы точно понимаете последствия.