WordPress Heartbeat API: What It Is, How It Affects Performance, and How to Control It

The WordPress Heartbeat API is a background communication system that lets your browser talk to your WordPress server at regular intervals while you’re logged in to wp-admin. Most site owners never think about it — but if your admin panel feels sluggish, or your server shows unexplained CPU spikes during editing sessions, the Heartbeat API is worth investigating.

What the WordPress Heartbeat API Does

Heartbeat was introduced in WordPress 3.6. It uses AJAX to maintain a periodic connection between the browser and the server, sending POST requests to wp-admin/admin-ajax.php on a regular interval.

This communication powers several admin features:

• Post lock — the notification that appears when another logged-in user is already editing the same post
• Autosave — the automatic background saving of draft content while you’re in the editor
• Session expiration warnings — the notice that appears before your login session times out
• Real-time inventory updates — with WooCommerce active, stock levels can sync in the admin without a manual refresh

These are genuinely useful features. The issue is how often they fire and what each request costs your server.

Why Heartbeat Can Cause Performance Problems

Each Heartbeat request triggers a PHP process on your server. The default polling frequency is 15 seconds on editor pages and 60 seconds on other admin screens. That’s up to four requests per minute per open browser tab.

A few scenarios where this adds up:

Multiple logged-in editors: If your site has a team of writers all working in the editor simultaneously, you’re generating concurrent AJAX requests from every active session every 15 seconds. On underpowered or shared hosting, this places steady background pressure on server resources.

Multiple open tabs: Each wp-admin tab runs its own Heartbeat instance. A user with five admin tabs open generates five concurrent request streams.

Plugin overhead on every request: All Heartbeat requests pass through admin-ajax.php, which bootstraps WordPress on every call — loading all active plugins and theme functions. Sites with many plugins carry more overhead per request than leaner installs.

Slow hooks attached to Heartbeat: Plugins can attach code to the heartbeat_received action to piggyback on each interval. Poorly written plugin code here can make each Heartbeat request noticeably slow.

How to See Heartbeat Activity

You can observe Heartbeat requests directly in your browser:

1. Open Chrome DevTools (or equivalent) and go to the Network tab
2. Filter by XHR or search for admin-ajax.php
3. Log in to wp-admin and open the post editor
4. Watch requests appear at regular intervals

Each request shows duration and payload size. On a responsive server these complete quickly. On an overloaded server they can take multiple seconds — which makes the editor feel unresponsive and ties up resources that could serve front-end visitors.

The Query Monitor plugin (free, in the plugin repository) also shows admin AJAX timing and can surface slow hooks running during Heartbeat ticks.

Three Ways to Optimize Heartbeat

1. Increase the Interval

Extending the polling interval is the lowest-risk change. WordPress exposes a filter for this:

add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60; // seconds; minimum allowed is 15
    return $settings;
} );

Changing from 15 to 60 seconds reduces Heartbeat frequency by 75%. Autosave becomes less frequent, but posts are still saved when you manually update them, so actual data loss risk is minimal for most workflows.

2. Restrict Heartbeat to Editor Pages

Heartbeat only provides meaningful value on post editing screens. You can disable it on the dashboard, settings pages, plugin list, and other admin areas where its features aren’t active:

add_action( 'init', function() {
    global $pagenow;
    if ( $pagenow !== 'post.php' && $pagenow !== 'post-new.php' ) {
        wp_deregister_script( 'heartbeat' );
    }
} );

This preserves post locking and autosave where they matter while stopping unnecessary polling everywhere else.

3. Disable Heartbeat Entirely

Single-author sites that don’t rely on post locking or background autosave can disable Heartbeat completely:

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

With Heartbeat disabled, posts still save when you click the Update or Publish button, and manual draft saves work normally. The features that stop working are: post locking notifications, background autosave during editing, and session expiration warnings.

Using a Plugin Instead

If you’d rather not modify functions.php, the Heartbeat Control plugin (by WP Rocket, free in the WordPress plugin repository) provides a settings page to configure Heartbeat frequency or disable it per location — dashboard, post editor, or front end — without any code.

WP Rocket (premium caching plugin) also includes Heartbeat controls under Tools → Heartbeat for users who already have it installed.

Does Heartbeat Affect Front-End Visitors?

By default, Heartbeat only runs for logged-in users in wp-admin. Regular site visitors are not affected.

The exception is sites where users log in on the front end — membership sites, WooCommerce stores where customers have accounts, and similar setups. In those cases, Heartbeat can run in the browser session of any logged-in front-end user, and the same optimization approaches apply. You can scope your code using is_admin() checks if you want different behavior for admin vs. front-end sessions.

When Does Heartbeat Actually Matter?

Heartbeat optimization has the most impact in specific situations:

• Shared hosting: Where PHP processes are a finite shared resource and background polling competes with front-end requests
• Editorial sites with multiple simultaneous writers: Where many concurrent Heartbeat streams create measurable server load
• Low-spec VPS configurations: Where bootstrapping WordPress repeatedly on background requests costs more than it would on a well-provisioned server

On managed WordPress hosting with properly allocated resources, Heartbeat’s server impact is lower because your site’s PHP processes aren’t competing with other sites and the underlying infrastructure is tuned for WordPress workloads. That doesn’t mean ignoring it — reducing unnecessary polling is still a sensible default — but it’s less likely to be the cause of front-end performance problems.

Practical Recommendation

For most WordPress sites, a reasonable default is:

1. Set the Heartbeat interval to 60 seconds (instead of 15) on all pages
2. Restrict Heartbeat to editor pages only if you want to go further
3. Disable entirely only if you’re running a single-author site and don’t use the autosave or post-locking features

This reduces background server load without disabling features your team may actually rely on.

---

If you’re finding that server-side overhead is a persistent issue regardless of Heartbeat settings, the underlying problem is often hosting capacity. Managed WordPress hosting handles the infrastructure layer — server configuration, resource allocation, caching — so your site isn’t bottlenecked by underpowered shared resources.

Rocket.net is built specifically for WordPress, with isolated resources per site, enterprise-level caching, and a global CDN included. If you’re running on shared hosting and hitting consistent performance ceilings, it’s worth a look.