A performance report shows repeated requests to admin-ajax.php, so somebody disables the WordPress Heartbeat API. The requests disappear—and autosave, post locking or a plugin feature quietly stops working. The safer diagnosis is to identify what is calling the endpoint, how often, and what work each request makes the server perform.
WordPress documents the Heartbeat API as a polling mechanism that can run at intervals and exchange data between the browser and server. Core features and plugins can use that channel, so the presence of Heartbeat traffic is normal. The question is whether the frequency or work performed during each request is actually causing a problem.
admin-ajax.php is the messenger
Many WordPress features use admin-ajax.php, not only Heartbeat. A slow AJAX request could come from autosave, a dashboard widget, a plugin background task or a custom feature. Profile the request payload and server timing before assigning blame.
What the Heartbeat API is actually doing
Depending on context, Heartbeat participates in features such as post locking, autosave-related coordination and session information. Plugins can attach their own data. Disabling it globally because one screen is noisy can remove useful safeguards from unrelated screens.
Count requests and measure server cost separately
Twenty lightweight requests may be cheaper than one request that triggers a heavy database query. Record response time, database activity, PHP CPU time and the screen where the requests originate. Our guide to fixing slow WordPress pages without rebuilding recommends finding the dominant bottleneck before applying a broad optimization.
Tune the feature, not the whole site
If Heartbeat is genuinely too frequent for your hosting environment, adjust it where the cost exists—perhaps a dashboard screen—rather than disabling it across the entire site. Preserve editor behavior when editors rely on post locking and autosave coordination.
Sometimes the caller is the real problem
A plugin may hook into every Heartbeat tick and perform expensive work. Disabling the API hides the symptom without fixing that behavior. Profile callbacks, query counts and external API calls. If a plugin is doing business-critical background work through frequent browser polling, consider whether a server-side scheduled or queued process would be more robust.
Do not confuse frontend performance with admin performance
Heartbeat normally matters most in logged-in contexts. If anonymous frontend users are slow, verify whether the relevant AJAX calls are actually occurring there. Optimizing an admin-only polling mechanism will not improve a frontend bottleneck caused by images, cache misses or uncached database queries.
A diagnostic sequence that preserves functionality
- Capture the slow session in browser network tools or application monitoring.
- Identify the specific AJAX action and request interval.
- Measure response time and server work.
- Temporarily disable or isolate the suspected plugin on staging if needed.
- Tune the interval or callback only after the cause is confirmed.
- Retest editor, session and autosave behavior.
- Monitor server load after deployment.
Include this check in routine WordPress maintenance when administrators report a slow dashboard. Performance tuning should preserve functionality unless a feature is proven unnecessary.
Profile logged-in and anonymous sessions separately
Performance plugins, object caches and CDNs often treat logged-in users differently. Reproduce the complaint in the same context as the affected user. A fast anonymous page does not prove that the editorial dashboard is healthy, and a slow admin request does not prove the public site is slow.
Document intentional tuning
If you change Heartbeat frequency or disable it on a specific screen, record why and what features were tested afterward. Future maintainers should not have to guess whether a filter is a deliberate optimization or a forgotten experiment.
After tuning, retest
- Post locking between two editors.
- Autosave behavior during long edits.
- Session/login warnings where relevant.
- The original server-load metric.
- Any plugin feature that used the same AJAX action.
Consider object caching and database health
If each Heartbeat tick triggers the same expensive option lookups or database queries, a persistent object cache or query fix may reduce the cost without changing the polling interval. Profile first: caching a bad query pattern can mask it, but healthy caching can make legitimate background communication inexpensive.
Database bloat can also make otherwise normal AJAX requests slow. Autoloaded options, expired transients and oversized session data deserve investigation when admin performance degrades across several actions.
Do not copy performance snippets blindly
Code that deregisters Heartbeat globally is easy to find online, but the snippet has no knowledge of your editorial workflow or plugins. Treat any global disable as a functional change that needs testing. Performance work is successful only if the site remains reliable for the people using it.
Measure the request before cutting the feature
Do not optimize the endpoint name. Identify the feature behind the request, measure its cost and tune that feature as narrowly as possible. When a Heartbeat interval or AJAX callback is genuinely excessive, the fix should preserve the workflow it supports rather than trading a performance graph for a broken editor or background process.