WordPress Heartbeat API: How to Stop It From Slowing Down Your Site

Open a WordPress dashboard in one browser tab, walk away, and the server keeps working anyway. That’s the WordPress Heartbeat API sending requests every few seconds to power autosave, post locking, and live plugin notices, and on shared or resource-limited hosting, it’s one of the quieter reasons a site feels sluggish for everyone, not just the person editing a post.

What Is the WordPress Heartbeat API?

The WordPress Heartbeat API is a built-in system that sends periodic AJAX requests from an open browser tab to the server, using the admin-ajax.php endpoint, to keep features like post locking, autosave, and session checks working in real time. It runs automatically any time someone has the WordPress dashboard open, whether they’re actively editing or the tab is just sitting in the background.

According to the official WordPress Plugin Handbook, the Heartbeat API ticks every 15 seconds by default on the post editor screen, and every 60 seconds on the dashboard and other admin pages, with an allowed range of 15 to 120 seconds. Every one of those ticks is a real PHP request that can’t be served from cache, which means it competes for the same server resources as actual visitor traffic.

Why Is My WordPress Dashboard Slow?

A slow WordPress dashboard is often caused by the Heartbeat API firing requests every 15 to 60 seconds from every open admin tab, each one consuming a PHP worker that a lower-tier hosting plan may only have a handful of. On shared hosting with limited concurrent PHP processes, a handful of editors with the dashboard open in the background is enough to noticeably slow down page loads for the entire site, not just the wp-admin area.

This is easy to miss because the slowdown doesn’t look like a typical performance problem. Nothing in a WordPress database cleanup or a plugin audit turns it up, since the Heartbeat API isn’t a plugin at all, it’s WordPress core. The only way to spot it is checking the Network tab in browser dev tools for repeated admin-ajax.php calls while a dashboard tab sits open and idle.

How to Control the WordPress Heartbeat API

Controlling the WordPress Heartbeat API means adjusting its frequency or disabling it entirely on specific screens, done either through a plugin or a short code snippet in functions.php. The code approach avoids adding another plugin just to change a few settings.

This snippet slows the Heartbeat interval to 60 seconds everywhere except the post editor, where autosave and post locking still need a fast interval to work correctly:

<?php
add_filter( 'heartbeat_settings', 'slow_down_heartbeat' );

function slow_down_heartbeat( $settings ) {
    $settings['interval'] = 60;
    return $settings;
}

To stop the Heartbeat API from running on the dashboard’s main screen while keeping it active in the post editor, deregister the script conditionally:

<?php
add_action( 'init', 'disable_heartbeat_on_dashboard', 1 );

function disable_heartbeat_on_dashboard() {
    global $pagenow;

    if ( is_admin() && 'index.php' === $pagenow ) {
        wp_deregister_script( 'heartbeat' );
    }
}

Test either snippet on a WordPress staging site first, since a typo in functions.php can trigger a critical error on the whole site, not just the dashboard.

Is It Safe to Disable the WordPress Heartbeat API?

Disabling the WordPress Heartbeat API completely is safe on the main dashboard screen, but not on the post editor or WooCommerce order pages, where it also handles autosave, post-locking notices, and real-time order status updates. Turning it off everywhere removes those features along with the extra server load, which is rarely the right trade-off.

The safer move is slowing the interval rather than switching it off, which is exactly what the code snippets above do. A 60-second interval on admin pages still keeps session checks and plugin notices working, just with a fraction of the requests a 15-second default generates over the course of a workday.

WordPress Heartbeat API and Core Web Vitals

The Heartbeat API itself doesn’t directly affect Core Web Vitals scores, since those are measured on front-end pages that visitors load, not the wp-admin dashboard. Its real impact is indirect: on resource-constrained hosting, Heartbeat requests compete with front-end page requests for the same limited pool of PHP workers, which can worsen response times measured by metrics like Interaction to Next Paint during periods when several editors have the dashboard open at once.

This matters more on shared hosting than on managed WordPress hosting with dedicated resources. A site with one or two occasional editors will rarely notice the difference, while an agency-managed site with a content team keeping multiple dashboard tabs open all day is a much stronger candidate for tuning the Heartbeat interval.

Common Heartbeat API Mistakes to Avoid

• Disabling it everywhere, including the post editor: this breaks autosave and post-locking, risking lost work if a browser crashes mid-edit.
• Disabling it on WooCommerce order pages: WooCommerce uses Heartbeat for real-time order status updates on the Orders screen, so disabling it there can delay staff seeing new orders.
• Assuming a caching plugin already handles this: caching plugins speed up front-end pages, not the wp-admin dashboard, so Heartbeat load isn’t touched by page caching at all.
• Setting the interval below 15 seconds: WordPress core enforces a 15 to 120 second range, so anything faster than 15 seconds is simply ignored.

The WordPress Heartbeat API rarely needs to be switched off entirely, it needs to be tuned. Slowing the interval on the dashboard while leaving the post editor and WooCommerce order screens untouched removes most of the unnecessary server load without giving up the features Heartbeat is actually there for.

Frequently Asked Questions