WordPress’s Heartbeat API is a mechanism that keeps a persistent connection between the browser and the server while a user has the WordPress admin or a WordPress page open. It fires an AJAX request at regular intervals, by default every 15 to 60 seconds depending on context. On the post editor, it powers autosave and the “someone else is editing this post” lock notification. Outside of those specific use cases, however, the Heartbeat API has no meaningful purpose and simply generates continuous server load for no benefit.
On shared hosting or lower-tier VPS environments, this polling can be a significant source of PHP and MySQL overhead, particularly when many users are logged in simultaneously. Disabling or throttling it is one of the most common performance optimizations for WordPress sites with real traffic.
The Code
This snippet takes a targeted approach rather than disabling Heartbeat everywhere. It removes the script entirely on the frontend, slows its interval in the admin to 60 seconds (from the default 15), and deregisters it on all admin pages except the post editor, where it’s genuinely needed for autosave and post locking.
How It Works
The first block hooks into init at priority 1, before scripts are registered, and calls wp_deregister_script('heartbeat') when is_admin() is false. This covers all frontend page views including the homepage, archives, single posts, and custom post type templates. Logged-in users browsing the front end of the site won’t trigger any heartbeat polling.
The second block uses the heartbeat_settings filter to set the interval to 60 seconds in the admin. This is the maximum allowed value. Reducing the frequency from 15 to 60 seconds cuts polling by 75% in admin contexts where Heartbeat is kept active.
The third block hooks into admin_enqueue_scripts and deregisters Heartbeat on all admin pages except post.php and post-new.php. This means the Dashboard, Settings, Plugins, Media Library, and all other admin screens won’t fire Heartbeat at all. Only the actual post editor retains it, preserving the autosave and post lock features that depend on it.
When to Use This
This snippet is appropriate for almost any WordPress site. The only time you should leave Heartbeat at full strength everywhere is if you’re using a plugin that explicitly depends on Heartbeat for real-time features outside the post editor, for example, some form builders or live chat plugins. Check your plugin documentation before disabling it site-wide.
Measuring the Impact
You can verify the effect by opening your browser’s Network tab while browsing the frontend of your site. Before the snippet, you’ll see periodic POST requests to /wp-admin/admin-ajax.php with the action heartbeat. After the snippet is active, those requests should disappear entirely on the frontend.
// Disable heartbeat on the frontend entirely
add_action( 'init', function() {
if ( ! is_admin() ) {
wp_deregister_script( 'heartbeat' );
}
}, 1 );
// Slow the heartbeat in the admin to reduce server load
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60; // seconds, default is 15
return $settings;
} );
// Keep heartbeat active only on post editing screens
add_action( 'admin_enqueue_scripts', function( $hook ) {
if ( $hook !== 'post.php' && $hook !== 'post-new.php' ) {
wp_deregister_script( 'heartbeat' );
}
}, 1 );