How to Optimize the WordPress Heartbeat API to Reduce Server Load

If your host has ever flagged your WordPress site for high CPU usage, or your admin dashboard feels sluggish the moment you open a second browser tab, the Heartbeat API is a common culprit. It runs quietly in the background of every WordPress install, and on shared hosting in particular it can eat through your CPU allowance faster than almost anything else on the site.

The Heartbeat API is the built-in system WordPress uses to send an AJAX request to admin-ajax.php roughly every 15 to 60 seconds while the dashboard, post editor, or certain front-end plugins are open. It powers things like autosave, post-locking (so two people can’t edit the same post at once), and live session checks. In my experience, most small business sites never need it running at full speed — tuning it down is one of the simplest performance wins you can make without touching a line of your theme.

Quick Answer

Slow the Heartbeat API down with a heartbeat_settings filter in your theme’s functions.php, and stop it running on the front end entirely unless a specific plugin (like a live chat widget or WooCommerce) genuinely needs it there. This cuts the number of admin-ajax.php requests your server handles without breaking autosave or post locking.

Why This Matters

Every Heartbeat request is a full trip to admin-ajax.php, which loads a meaningful chunk of WordPress to respond — even for a tiny check-in. On a well-resourced managed host this barely registers. On budget shared hosting, where CPU seconds are metered and multiple sites share the same server, a handful of open dashboard tabs across your team can trigger the kind of resource spikes that get a site suspended or throttled.

It also affects the people actually working on the site. A Heartbeat interval that’s too aggressive can make the post editor feel laggy, especially on sites running several plugins that hook into it for their own polling. Tuning the interval — rather than switching it off completely — keeps the useful parts working while removing the load nobody actually benefits from.

Step-by-Step Instructions

1. Confirm Heartbeat Is Actually Worth Tuning

Before changing anything, check whether admin-ajax.php is actually showing up as a load source. Your hosting control panel’s resource usage graphs are the most direct evidence — look for a pattern of small, frequent spikes rather than one large one. It’s also worth running a general check through the WordPress Site Health tool, which surfaces performance-related warnings even though it won’t name Heartbeat specifically.

2. Slow Down the Heartbeat Interval

Add this to your child theme’s functions.php (or a custom plugin, never the parent theme) to stretch the default interval out to once a minute instead of the default 15 to 60 seconds. The available settings are documented in WordPress’s own Heartbeat API reference, including the minimum and maximum values each screen will accept:

<?php
add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60; // seconds
    return $settings;
} );

This alone can cut the number of Heartbeat requests by more than half on a site where the default interval is 15 seconds, with no visible change to how the dashboard behaves.

3. Stop Heartbeat Running on the Front End

Most sites don’t need Heartbeat at all outside wp-admin. Unless you’re running a plugin that specifically relies on it on the public-facing site (some live chat tools and WooCommerce cart features do), deregister it there:

<?php
add_action( 'init', function () {
    if ( ! is_admin() ) {
        wp_deregister_script( 'heartbeat' );
    }
}, 1 );

4. Limit It to the Post Editor Screen

Inside wp-admin, Heartbeat mostly earns its keep on the post-editing screen (autosave and post locking). If your dashboard’s main pages feel slow, you can restrict Heartbeat to editor screens only, so it doesn’t keep polling while someone’s just browsing the Posts list or Settings pages:

<?php
add_action( 'admin_enqueue_scripts', function () {
    global $pagenow;
    if ( ! in_array( $pagenow, array( 'post.php', 'post-new.php' ), true ) ) {
        wp_deregister_script( 'heartbeat' );
    }
} );

5. Or Use a Plugin If You’d Rather Not Touch Code

If editing functions.php isn’t something you’re comfortable with, a dedicated Heartbeat Control plugin gives you the same settings — interval and location (dashboard, post editor, front end) — through a simple settings screen instead. The result is the same; it’s just a question of whether you’d rather manage it through code or a UI.

Practical Tips

• Test post locking and autosave again after making changes — open a post in two browser windows and confirm the “someone else is editing this” notice still appears.
• If you’re already running object caching, Heartbeat requests are cheaper to serve because WordPress isn’t rebuilding as much from the database on every check-in — the two changes work well together rather than replacing each other.
• On WooCommerce stores, be cautious with front-end deregistration — some cart and checkout features depend on AJAX polling that looks similar to Heartbeat traffic. Test a full checkout flow before assuming nothing broke.
• If server response time is still slow after tuning Heartbeat, the bottleneck is probably elsewhere — see our guide on how to reduce TTFB in WordPress for the next place to look.

Common Mistakes

• Disabling Heartbeat completely everywhere. This can silently break post locking, autosave, and any plugin features that quietly depend on it — including some WooCommerce and membership plugin session checks.
• Editing admin-ajax.php directly. It’s a WordPress core file. Any change will be overwritten on the next core update, and there’s no need to touch it — everything here is done through filters and hooks.
• Assuming Heartbeat is the only cause of high CPU usage. Bloated plugins, uncached database queries, and cron jobs running too frequently are common co-conspirators. Rule those out too rather than stopping at Heartbeat.
• Not testing after tuning. A broken autosave or post lock is easy to miss until someone loses unsaved work — check it before moving on.

When to Use This vs Alternatives

Tuning Heartbeat is worth doing on shared or budget hosting, on sites with several editors working simultaneously, or anywhere you’ve seen CPU usage warnings from your host. If you’re on a managed WordPress host with generous resources and good server-side caching already in place, the gains are smaller and it’s a lower priority — you’ll likely get more out of following the step-by-step approach in our guide to building a WordPress website and getting the caching and hosting fundamentals right first.

Conclusion

Slowing down and scoping the Heartbeat API to only where it’s needed is a five-minute change that can meaningfully reduce server load, particularly on shared hosting. Make the change, then actually test autosave and post locking before you consider it done.