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.

What the Heartbeat API Is Actually Doing

The Heartbeat API is WordPress core’s built-in polling system, sending an AJAX request to admin-ajax.php at a fixed interval that depends on which screen is open. The default is 15 seconds on the post-editing screen (post.php and post-new.php), where it’s doing real work — autosave and post locking, the mechanism that stops two people editing the same post at once. Everywhere else in wp-admin — the dashboard, the Posts list, Settings pages — the default drops to 60 seconds, a slower check-in used mostly for session and plugin-notification polling rather than anything editor-specific. In my experience, most small business sites never need it running at the 15-second rate outside the editor — tuning it down is one of the simplest performance wins you can make without touching a line of your theme.

Every one of those requests 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.

Confirm Heartbeat Is Actually the Load Source First

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, timed to whenever an editor has the dashboard open. 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.

Slow the Interval Down With a Filter

Add this to your child theme’s functions.php (or a custom plugin, never the parent theme) to stretch the interval out to the WordPress-enforced maximum of 60 seconds wherever Heartbeat runs. The available settings are documented in WordPress’s own Heartbeat API reference, which specifies that 60 seconds is the hard ceiling core will accept — a filter value above that gets silently capped back to 60:

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

On the post-editing screen, this cuts request frequency to a quarter of the 15-second default, with no visible change to autosave behaviour for most writers — WordPress still autosaves reliably at 60-second intervals, it’s just checking in less aggressively in between.

Stop It Running on the Front End Entirely

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 );

Limit It to the Post Editor Screen Only

Inside wp-admin, Heartbeat mostly earns its keep on the post-editing screen. If your dashboard’s main pages feel slow, 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' );
    }
} );

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 settings screen instead of code.

A Worked Example: Three Editors, One Shared Host

A site I looked at recently had three people with editor access, each routinely leaving a post-editing tab open in the background for hours while they worked on other things. At the default 15-second interval, that’s three separate admin-ajax.php calls every 15 seconds, all day — roughly 720 requests an hour from Heartbeat alone, before counting anything else the dashboard was doing. Capping the interval at 60 seconds and deregistering Heartbeat everywhere except the actual editor screen cut that to under 180 requests an hour, with no change reported in autosave or post-locking behaviour over several weeks of normal use. The host’s CPU-usage warning, which had been firing roughly weekly, stopped appearing entirely.

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.
• Setting the interval above 60 seconds and expecting it to take effect. WordPress core enforces 60 seconds as the hard maximum; a higher value in the filter is simply ignored.
• 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.

When Tuning This Is Worth the Time

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.

Capping the interval at 60 seconds and scoping Heartbeat 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.