WordPress Heartbeat Control
Reduce or disable the WordPress Heartbeat API to eliminate recurring AJAX polling overhead.
Metrics
This technique does not move LCP.
This technique can move up to 67% of TBT's share of the Lighthouse score.
This technique does not move CLS.
This technique does not move FCP.
This technique does not move SI.
This technique does not move TTFB.
Overview
The WordPress Heartbeat API sends an AJAX request to wp-admin/admin-ajax.php every 15–60 seconds from every browser tab where a WordPress page is open. It powers features like post lock notifications, autosave, and the dashboard activity feed. On the frontend, the Heartbeat fires even on regular pages when a user is logged in — contributing to periodic main-thread interruptions and unnecessary server load. Controlling its frequency or disabling it on the frontend can meaningfully reduce background resource consumption.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: LCP, CLS, FCP, SI, TTFB.
The Problem
Each Heartbeat request executes a full PHP bootstrap cycle — loading WordPress, authenticating the user, running hooks — generating a 200–600 ms server round-trip and a brief main-thread busy period when the response is processed in the browser. On a shared server with 50 logged-in users, this produces 50 simultaneous PHP processes every 15 seconds purely for Heartbeat — consuming server CPU that should be handling real page requests. In the browser, the periodic AJAX response processing contributes to Total Blocking Time when it coincides with user interaction.
Performance Impact
TBT
10–30%
eliminates periodic main-thread interruptions from AJAX response processing for logged-in users
INP
Indirect
fewer background AJAX cycles mean the main thread is more available when users interact
Risk: Low
disabling Heartbeat on admin pages breaks post autosave and concurrent edit locking — disable on frontend only
How it works
01
Understand where Heartbeat runs
Heartbeat runs in three contexts: the WordPress admin dashboard, the post editor, and the frontend for logged-in users. Each has different value: autosave in the editor is important; Heartbeat on the frontend provides no user-facing value and is safe to disable entirely.
02
Disable Heartbeat on the frontend
Use the
heartbeat_settingsfilter or thewp_enqueue_scriptsaction to dequeue the Heartbeat script on non-admin pages. This is the safest optimization — no admin functionality is affected.03
Throttle Heartbeat in the admin
The default Heartbeat interval is 15–60 seconds. Increasing it to 120 seconds via the
heartbeat_settingsfilter halves the server load impact while retaining all functionality — including autosave, which still fires at the original interval independently.04
Disable entirely on non-editor admin pages
Heartbeat on the dashboard, plugin list, or media library pages provides no meaningful benefit. Detect the current admin page via the
$pagenowglobal and disable Heartbeat on all admin pages exceptpost.phpandpost-new.php.
Code Example
// Default WordPress behavior:
// - Heartbeat active on frontend for logged-in users
// - Interval: 15–60 seconds
// - Fires on every open tab<?php
// Disable Heartbeat on the frontend entirely
add_action('init', function() {
if (!is_admin()) {
wp_deregister_script('heartbeat');
}
});
// Throttle Heartbeat in the admin to 2 minutes
add_filter('heartbeat_settings', function($settings) {
$settings['interval'] = 120; // seconds
return $settings;
});Add to your theme’s functions.php or a site-specific plugin. The 120-second interval keeps autosave and post locking functional while cutting server polling by 50–75%.
Limitations
- Disabling Heartbeat in the post editor disables autosave — editors relying on autosave for draft recovery will lose that safety net.
- Disabling Heartbeat on any admin page disables concurrent post locking notifications — two users could edit the same post simultaneously without seeing a warning.
- Some plugins use the Heartbeat API for their own real-time features (e.g., WooCommerce stock updates, form entry notifications). Audit active plugins before disabling globally.
Common Mistakes
Disabling Heartbeat globally including the post editor
Always preserve Heartbeat on post.php and post-new.php for autosave. The only safe global disable is on the public-facing frontend for non-admin users.
Using a plugin to disable Heartbeat when a filter is sufficient
Heartbeat control requires two lines of PHP. Adding a dedicated plugin for this creates an unnecessary dependency. Implement via functions.php or a site-specific mu-plugin.