WordPress Heartbeat API performance becomes a concern when repeated background requests compete with real work in the dashboard. You may see frequent calls to admin-ajax.php, rising CPU, slow editor actions, or several PHP workers occupied while people are logged in.
That pattern deserves investigation, but it does not prove Heartbeat is the cause. WordPress routes many AJAX actions through the same file. A plugin can also attach expensive work to a legitimate heartbeat request. Disabling the API first can hide the traffic while breaking post locking, session checks, or another feature that depends on it.
At Webless, we treat Heartbeat as a request path to measure, not a feature to blame. The useful sequence is simple: identify the action, reproduce the load, inspect what runs during the request, change the smallest safe control, and repeat the same test.
What the WordPress Heartbeat API actually does
Heartbeat is a polling system that lets the browser and WordPress exchange small updates without a full page reload. The official WordPress Heartbeat API documentation explains that the browser gathers data on a timed tick, sends it to the server, and receives a response through an AJAX handler.
WordPress and plugins can use that exchange for near-real-time behavior. In the editor, it supports coordination between logged-in users. Elsewhere in the dashboard, plugins may use it to refresh state, preserve sessions, or process their own data. The request itself is normal.
The cost depends on what happens after the request reaches WordPress. Every uncached AJAX request must load enough of the application to run its action. Active plugins, the theme, database queries, object-cache operations, and external calls can all affect the response. Two sites can send heartbeat requests at the same interval while producing very different server load.
Prove that Heartbeat is the busy AJAX action
A list of requests to admin-ajax.php is not enough. First inspect the request payload or form data. A Heartbeat request normally carries action=heartbeat. Other actions can use the same endpoint for search, filters, imports, forms, cart behavior, analytics, and plugin tools.
This distinction prevents an easy false diagnosis. If another action creates most of the runtime or traffic, changing the Heartbeat interval will not repair it. Our slow WordPress admin guide follows the same rule: name the slow request before changing the dashboard.
Use browser developer tools, a host request log, an application performance monitor, or a server access log that includes request data. Record:
- the AJAX action;
- the WordPress screen that was open;
- the logged-in role;
- the request frequency and duration;
- the response status and size;
- the number of simultaneous dashboard users.
A single request every minute is different from several long-running requests overlapping across many browser tabs. Measure both frequency and cost. A fast repeated request may be harmless, while one slow request can occupy a worker long enough to queue other uncached traffic.
Reproduce the load under controlled conditions
Choose one affected screen and one user role. Close duplicate tabs, wait for the page to settle, and record a short baseline. Then open the same screen in another session only if concurrent use is part of the real problem.
Do not mix several changes into this test. If you clear caches, disable plugins, change the PHP worker limit, and alter the interval at once, the result cannot tell you which action mattered. Keep the production site stable and use staging for invasive tests.
A useful test answers four questions:
- Does the load appear only while a logged-in screen is open?
- Is
action=heartbeatthe request consuming time? - Which screen or role produces the slowest response?
- How does server pressure change after the browser session closes?
If the public site slows during the test, compare cached and uncached traffic. Heartbeat is not a substitute for a broader capacity check. The same shortage of PHP workers may also appear during a campaign or import, which is why our traffic spike preparation guide tests authenticated and uncached paths separately.
Find what runs inside the heartbeat request
Once the action is confirmed, inspect its execution. The core handler may be only the route. A plugin or custom feature can add work to the request, and that work can trigger database queries, remote calls, large option reads, or repeated writes.
Start with request-level timing. If database time dominates, trace the slow query back to its caller instead of assuming that Heartbeat itself needs tuning. Our guide to slow WordPress database queries explains how to connect SQL cost to the plugin, theme, or custom code that requested it.
If PHP time dominates without a clear query, profile callbacks and hooks during the request. Look for the same component in repeated samples. A single slow sample during an update, cache rebuild, or deployment is not enough evidence for a permanent setting change.
Pay attention to response data as well. A plugin that continually sends or receives growing payloads may create avoidable serialization and database work. The repair may belong in that plugin’s configuration or code, not in a global Heartbeat control.
WordPress Heartbeat API performance: choose the smallest safe change
Improving WordPress Heartbeat API performance starts with the evidence you collected. There is no universal interval that is safe for every editor, membership site, store, learning platform, or custom dashboard.
| Evidence | Likely next step | What to protect |
|---|---|---|
| Heartbeat is frequent but consistently fast | Leave it alone and investigate the actual capacity event | Normal dashboard behavior |
| One plugin adds expensive work to each request | Change that integration, callback, or plugin configuration | Other Heartbeat consumers |
| Non-editor screens create measurable overlapping load | Test a longer interval only on those screens | Editor locking and active sessions |
| The editor request is slow because of queries or external calls | Repair the caller before changing the tick | Collaboration and content safety |
| Many logged-in users exhaust PHP workers | Combine request repair with a capacity plan | Checkout, forms, accounts, and uncached pages |
A speed plugin may expose Heartbeat controls, but the presence of a switch is not proof that it should be used. If the issue is a heavy callback, a longer interval merely runs the same expensive work less often. That can reduce average load while leaving slow dashboard actions and code risk unresolved.
For stack-level bottlenecks, a structured WordPress speed optimization service checklist should include request evidence, before-and-after measurements, and regression checks. For plugin or custom-code ownership, the work is closer to development than configuration.
Why disabling Heartbeat can create a second problem
A blanket disable is attractive because it produces an immediate drop in one request type. However, that result answers only whether the requests stopped. It does not prove the site still behaves correctly.
Editors may lose coordination signals. A plugin may stop refreshing an important status. Session-related behavior can change. A custom dashboard can silently become stale. The exact effect depends on the components installed and the screens where the script was active.
There is another risk: disabling Heartbeat may remove the trigger that exposed a slow callback without repairing the callback itself. The same code can still run through another path later. That is why request attribution matters more than a lower line on a CPU graph.
When a temporary restriction is necessary during an incident, document its scope, time, reason, and rollback condition. Then move the diagnosis to staging or a controlled production window. An emergency control should not become an undocumented permanent setting.
Do not confuse Heartbeat with WP-Cron or every AJAX request
Heartbeat, WP-Cron, the REST API, and plugin AJAX calls are separate mechanisms even when their symptoms overlap. A dashboard may feel slow while background queues also fall behind, but changing one system does not automatically repair the other.
If scheduled actions are late, inspect the trigger, queue, and responsible task using our guide to WordPress cron jobs not running. A different AJAX action needs its own trace. When the browser calls a REST endpoint, measure that endpoint instead.
This separation is especially important on WooCommerce, membership, and learning sites. They often have several authenticated request paths that bypass full-page cache. Grouping them all under “admin-ajax load” produces broad changes and weak evidence.
Validate the repair with the same workload
After one change, repeat the baseline under the same conditions. Use the same screen, role, browser state, number of tabs, and observation window. This WordPress Heartbeat API performance check should compare request count, response duration, server CPU, worker occupancy, and the user-visible action that originally felt slow.
Then test the behavior the change could affect:
- open the editor in two sessions and confirm post-lock behavior;
- leave an affected dashboard screen open long enough for several ticks;
- confirm session and login behavior;
- check plugin status panels that previously refreshed automatically;
- repeat a normal uncached business action such as checkout, form submission, or account access;
- review logs for new JavaScript, AJAX, PHP, or authorization errors.
Keep a rollback path. If an interval change reduces load but breaks a required workflow, it is not a successful optimization. Restore the known-good setting and repair the expensive caller.
What a useful Heartbeat performance report should contain
A credible result is more specific than “Heartbeat optimized.” It should state where the load appeared, which action was measured, what executed during the request, what changed, and what remained functional afterward.
| Record | Minimum evidence |
|---|---|
| Baseline | Screen, role, interval, request duration, and server condition |
| Attribution | action=heartbeat plus the responsible callback or component when identifiable |
| Change | Exact code, plugin setting, scope, and rollback instruction |
| Validation | Repeated workload, resource comparison, and feature checks |
| Follow-up | Monitoring window and threshold for reopening the investigation |
This record also prevents future drift. A new plugin, editor workflow, or increase in logged-in users can change the cost. The old setting may remain, but the assumptions behind it no longer apply.
When the problem needs optimization or development
Configuration work is often enough when the server stack is healthy, the callback is lightweight, and a measured interval change on selected screens reduces overlap without affecting features. That work fits a focused WordPress speed optimization service.
Development becomes the better path when a plugin or custom integration performs heavy work on every tick, sends unnecessary payloads, repeats database writes, calls an external service, or lacks screen-level controls. A WordPress development service can move that work to a safer trigger, reduce the callback, or repair the data path instead of suppressing the signal.
The dividing line is ownership. If the request is expensive because of code, changing server settings around it is only a partial fix. If the code is sound but concurrent uncached work exceeds capacity, the solution belongs in performance architecture and hosting resources.
Measure the request before changing the heartbeat
WordPress Heartbeat API performance should be judged by request cost, concurrency, and the features that depend on it. Frequent requests alone do not prove a fault, and admin-ajax.php alone does not identify the action.
Confirm the payload, reproduce one screen, trace what runs, and make one reversible change. Then repeat the same workload and test the editor, session, and plugin behavior that the change could affect. That method takes longer than disabling a switch, but it produces a repair you can explain and maintain.