A busy `admin-ajax.php` log does not automatically mean WordPress is broken. But if Heartbeat requests are firing every 15 seconds across many open admin sessions, they can consume PHP workers, create database activity, and make the dashboard feel sluggish. To optimize WordPress heartbeat API safely, reduce its frequency on low-priority admin screens first. Do not disable it blindly: the API protects post edits, supports autosaves, and powers parts of WordPress and plugin workflows.
The right fix is usually targeted throttling, backed by measurements. Check request frequency, response time, PHP worker utilization, and the payload being sent before changing anything.
What the WordPress Heartbeat API Actually Does
The WordPress Heartbeat API is a browser-based polling system. JavaScript sends periodic requests to `wp-admin/admin-ajax.php`, and WordPress returns information that the current screen or plugin needs.
Core WordPress uses Heartbeat for post locks and autosaves in the editor. If two people open the same post, Heartbeat helps warn the second editor that the content is already being changed. It also saves a draft revision periodically, which matters when a browser crashes or an editor loses connectivity.
Plugins use it too. WooCommerce extensions, page builders, editorial tools, security dashboards, and custom admin software may register Heartbeat events. That is why generic advice to "disable Heartbeat" causes avoidable problems. You might reduce AJAX traffic while breaking an editor, inventory workflow, or custom admin screen.
A single request every 15 to 60 seconds is usually insignificant. The issue appears when the request is expensive or multiplied across many users. Ten staff members with several tabs open can generate a steady stream of uncached PHP requests. Unlike a cached public page, each request can require WordPress bootstrap, plugin loading, database queries, and a PHP worker.
When Heartbeat Is a Real Performance Problem
Start with evidence, not a plugin setting. Look in your access logs, application performance monitor, or hosting dashboard for requests to `admin-ajax.php`. Identify whether the action is `heartbeat`, how often it runs, and how long it takes.
Heartbeat deserves attention when you see one or more of these conditions:
- `admin-ajax.php` requests consistently take more than a second.
- PHP workers are saturated while staff are working in wp-admin.
- Database CPU rises with editor or dashboard activity.
- WooCommerce admin users report slow order screens during busy periods.
- A plugin adds large Heartbeat payloads or slow callback queries.
Do not confuse Heartbeat with every `admin-ajax.php` request. Many plugins use the same endpoint for unrelated actions. Also separate it from WordPress cron. WP-Cron may run during normal web requests and create its own performance issues, but changing Heartbeat settings will not fix a poorly scheduled cron workload.
Check the browser before changing server settings
Open browser developer tools, select the Network tab, and filter for `admin-ajax.php`. Click a request and inspect the form data. A WordPress Heartbeat request typically includes `action=heartbeat`.
Check its timing over a few minutes. Then compare it with server-side data. If browser requests return quickly but PHP workers remain busy, another admin action is likely responsible. If each Heartbeat request takes 800 ms or more, inspect active plugins, database queries, and slow external calls attached to that request.
Optimize WordPress Heartbeat API by Screen
The safest first move is to increase the interval on screens where real-time updates are not essential. The WordPress Heartbeat interval can range from 15 to 120 seconds. For a dashboard or low-activity admin page, 60 seconds is a sensible starting point.
Keep the post editor closer to the default unless you have tested the editorial impact. Autosaves and post-lock checks are worth the small amount of overhead for people actively publishing content.
Add the following to a small must-use plugin or a site-specific plugin. Avoid placing operational code in a theme, where a theme update or redesign can remove it.
add_filter( 'heartbeat_settings', function( $settings ) { $screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
if ( $screen && 'dashboard' === $screen->id ) { $settings['interval'] = 60; }
return $settings; } );
This changes the interval only on the main Dashboard screen. It does not interfere with the block editor or classic editor. If your server data points to another low-priority screen, adjust the screen ID after confirming it in the browser or with a temporary diagnostic snippet.
For agencies managing multiple sites, this scope matters. A global Heartbeat setting may look efficient in a benchmark but quietly degrade a client team's publishing workflow. Optimize the expensive screen, not every screen by default.
Throttle broad admin usage with care
If the majority of Heartbeat load comes from general wp-admin navigation rather than editing, you can apply a broader interval while excluding editing screens. Test this on staging first.
add_filter( 'heartbeat_settings', function( $settings ) { $screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
if ( ! $screen ) { return $settings; }
$editor_screens = array( 'post', 'page' );
if ( ! in_array( $screen->base, $editor_screens, true ) ) { $settings['interval'] = 60; }
return $settings; } );
Custom post types often use the `post` screen base as well, so this preserves normal editor behavior across posts, pages, and most custom content types. Page builders and custom admin applications can behave differently, however. Verify their editing and save actions before deploying this site-wide.
Why Disabling Heartbeat Often Backfires
Many optimization plugins offer an option to disable the Heartbeat API everywhere. That setting is attractive because it is simple, but simplicity is not the same as safety.
Disabling Heartbeat in the editor removes post-lock communication. Two editors can work on the same content longer without a warning, increasing the risk of overwritten changes. It can also reduce autosave protection. For a solo blogger editing occasional posts, the trade-off may be acceptable. For an agency, newsroom, membership site, or store with several administrators, it usually is not.
Disabling it on the front end can be reasonable when a plugin has unnecessarily enqueued `heartbeat.js` for anonymous visitors. First confirm that it is actually loaded there and determine why. WooCommerce stores, for example, must not lose dynamic cart, checkout, stock, or account behavior because someone applied an overly broad script optimization rule.
The better sequence is straightforward: measure the request, identify its screen and callback, slow it down where possible, and disable only a confirmed nonessential use case.
Fix Slow Heartbeat Requests at the Source
Reducing frequency helps, but it does not repair a request that is slow because the server or application is unhealthy. A 60-second interval only hides a bad query if each request is still taking several seconds.
First, inspect the response payload. Large payloads often indicate a plugin passing too much state through Heartbeat. Next, profile the request. Look for slow database queries, repeated option reads, remote HTTP calls, and plugin callbacks that run on every poll.
Autoloaded options are a frequent contributor to slow admin requests. WordPress loads autoloaded options on nearly every request, including AJAX. A bloated `wp_options` table can make Heartbeat look guilty when the real issue is accumulated plugin data. Review unusually large autoloaded values carefully, and do not mass-delete options without knowing which plugin owns them.
Persistent object caching can reduce repeated database reads, especially on a busy backend. Redis-backed object caching is useful when it is correctly configured and monitored, but it will not fix uncacheable queries or exhausted PHP workers. Likewise, faster CPUs help process WordPress requests quickly, but infrastructure cannot compensate for a plugin that runs a remote API call every 15 seconds.
For WooCommerce, inspect order-related admin screens during normal staff activity. The highest-risk bottleneck may be concurrent non-cacheable requests competing for limited PHP workers, not Heartbeat alone. Increase worker capacity only after identifying whether workers are blocked on PHP execution, database waits, or slow external services.
Test the Change Like an Operations Change
Make Heartbeat adjustments on staging when possible, then test with the same plugins, roles, and editing patterns used in production. Confirm that post locks appear, autosaves work, page-builder editing remains stable, and WooCommerce administration behaves normally.
After deployment, compare before-and-after metrics over a representative period. Watch request count, median and p95 `admin-ajax.php` response time, PHP worker utilization, database load, and editor reports from actual users. A lower request count is useful only if the site remains functional.
Keep the change reversible. A must-use plugin with one documented filter is easier to audit and roll back than a mystery checkbox buried in a performance plugin. On managed environments with server-level caching, modern CPU capacity, and clear application metrics, Heartbeat tuning becomes a small, controlled improvement instead of a desperate attempt to keep wp-admin usable.
Treat the Heartbeat API as a necessary background process, not an enemy. Slow down what is unnecessary, preserve what protects content and workflows, and investigate any request expensive enough to threaten the health of the server.
