When it comes to WordPress® performance, we often focus on the big metrics: page load speed, database query optimization, and asset minification. However, there is a silent pulse running in the background of every WordPress installation that can, under the right conditions, bring even a robust server to its knees.
This pulse is the WordPress Heartbeat API.
Introduced in WordPress 3.6, the Heartbeat API provides a way for the browser to communicate with the server in real-time while a user is logged into the dashboard. It manages essential features like session concurrency, auto-saving posts, and post locking, ensuring that two editors don’t accidentally overwrite each other’s work.
While these features are vital for a collaborative environment, the Heartbeat API’s default behavior isn’t always optimized for high-concurrency sites. If left unmanaged, it can lead to exhausted server resources and impacts on site stability.
Anatomy of a Heartbeat Request
The Heartbeat API functions by sending a POST request to admin-ajax.php at regular intervals (usually every 15 to 60 seconds). The journey of a single “pulse” looks like this:
- Browser Trigger: The JavaScript on the client side initiates a request.
- Server Contact: The request hits
admin-ajax.php. - WordPress Bootstrap: Even though it’s a background request, WordPress must perform a full bootstrap—loading the core, active plugins, and the theme—to process the request.
- Response: The server sends back data (like the “post locked” status) to the browser.
The critical issue here is that Heartbeat requests are uncacheable. Because they are POST requests sent to the administrative backend, they bypass standard page caching. Every single pulse requires a dedicated PHP worker to process.
On a site with a single editor, this is negligible. The math changes rapidly when it’s a site with 50 concurrent users, whether they are editors in a newsroom or students in a learning management system. Fifty users with the dashboard open can generate hundreds of uncacheable requests per minute, saturating the server’s capacity.
Diagnosing the Impact
Identifying a “Heartbeat Storm” starts with the server logs. If your access logs are filled with repetitive POST requests to /wp-admin/admin-ajax.php with the action heartbeat, the API is likely the culprit.
Beyond logs, this overhead manifests as a drain on PHP workers. PHP workers are the engines that process the PHP code on your site. Since a worker is “occupied” for the duration of every Heartbeat pulse, a high volume of these background tasks leaves fewer workers available to serve actual frontend traffic to your visitors.
Programmatic Throttling: The heartbeat_settings Filter
You do not necessarily need to disable the Heartbeat API entirely.Doing so would break useful features like auto-save. Instead, another approach is to throttle the interval.
By default, the “pulse” happens every 15 seconds when you are editing a post. You can use the heartbeat_settings filter to change this interval to the maximum allowed (60 seconds), significantly reducing the load.
/**
* Throttle the Heartbeat API to 60 seconds.
*/
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60; // Set to the maximum allowed 60 seconds
return $settings;
});
Contextual Control
In some cases, you may want to disable the Heartbeat API on specific parts of the site where it serves no purpose. For instance, there is rarely a need for the heartbeat to run on the frontend of the site for non-administrative users.
You can selectively deregister the script based on the screen or the user’s capabilities:
/**
* Disable Heartbeat on the frontend unless a user is editing a post.
*/
add_action( 'init', function() {
if ( ! is_admin() ) {
wp_deregister_script( 'heartbeat' );
}
});
Architecting for Stability
Managing the Heartbeat API is a key component of site reliability engineering for WordPress. By slowing down the background pulse, you ensure that your server’s resources—specifically its PHP workers—are prioritized for the most important task: serving your content to your audience.
Standardizing these throttles in your theme or a core functionality plugin allows for a more predictable server load, preventing administrative activity from ever becoming a bottleneck for site performance.