Stop letting every open admin tab quietly hammer the server
Heartbeat controls WordPress's own Heartbeat API — the background request every admin screen sends every fifteen to sixty seconds — with three modes ranging from the WordPress default to disabling it entirely, or keeping it only where autosave and post locking genuinely need it.
- Three modes: default, fully disabled, or post-editor only.
- Frontend heartbeat always removed once a non-default mode is chosen.
- Post locking and autosave preserved specifically in the post editor.
- AJAX requests explicitly excluded from any interference.
What does Heartbeat do?
When the heartbeat_control module is active with a non-default mode, TOWP_Performance deregisters the Heartbeat script based on the chosen setting. In "Disable everywhere" mode, Heartbeat is removed from the frontend and every admin screen. In "Disable everywhere except post editing" mode, it's removed everywhere except the post and page editor screens, where autosave locking and "someone else is editing this" notifications still depend on it. Since the frontend copy of Heartbeat has no genuine use there, it's always deregistered once either non-default mode is active, and AJAX requests are explicitly excluded from this logic entirely.
Heartbeat runs whether or not the screen actually needs it
Since Heartbeat fires from any open admin screen by default, a busy admin can accumulate background requests without anyone deciding that tradeoff was worth it.
It fires on every open admin tab, used or not
WordPress's Heartbeat API sends a background request every fifteen to sixty seconds from any open admin screen, regardless of whether anything on that specific screen depends on it.
Each request is a full PHP execution against the database
Every one of those pings runs PHP and queries the database, and on a busy admin with several people working, those requests add up fast.
Three modes, matched to what a screen actually needs
The module replaces a single blanket setting with a choice between leaving Heartbeat alone, removing it entirely, or keeping it exactly where autosave and post locking depend on it.
Disable it completely, if nothing needs it
Remove Heartbeat from the frontend and every admin screen for a site that doesn't rely on any of its features.
Keep it only where autosave and locking matter
The post editor keeps Heartbeat active specifically, so autosave and "someone else is editing this" warnings keep working exactly as before.
AJAX requests are never touched
The module explicitly excludes AJAX requests from its logic, since Heartbeat itself, and potentially other features, run over the same admin-ajax.php endpoint.
Precise targeting, not a blanket switch
Every capability below is present in the supplied PHP class and its settings registration.
Default, fully disabled, or post-editor only
A straightforward choice between WordPress's own behavior, removing Heartbeat everywhere, or keeping it only on the screens that genuinely need it.
No genuine frontend use case
Once either non-default mode is active, the frontend copy of Heartbeat gets deregistered unconditionally, since nothing on the public site depends on it.
get_current_screen()->base === 'post'
The allow_posts mode checks the exact screen base to confirm it's the post editor before deciding to leave Heartbeat active there.
DOING_AJAX short-circuits the entire check
A request already running through admin-ajax.php returns immediately, before any deregistration logic runs, avoiding any interference with concurrent AJAX.
wp_enqueue_scripts and admin_enqueue_scripts, specifically
These particular hooks are used because $pagenow and get_current_screen() are only fully initialized by the time they fire, making the post-editor detection reliable.
Heartbeat Frequency, an independent setting
A companion setting adjusts how often Heartbeat polls instead of disabling it outright, for a middle ground between the WordPress default and turning it off.
Where controlling Heartbeat helps most
The module supports any admin where background pings add up faster than they're actually needed.
Busy admin dashboards with several people working at once
Cut down on background requests piling up across several simultaneously open editor tabs and admin screens.
Sites where Heartbeat-dependent features aren't used
Disable it entirely on a site where nothing relies on autosave locking, revision conflict checks, or live session monitoring.
Sites that specifically want autosave and post locking kept
Use the post-editor-only mode to trim background requests everywhere else while keeping exactly the features people actually rely on.
Fewer requests, the right features kept
The module combines a genuine reduction in server load with careful preservation of what people actually rely on.
Often the largest single saving on a busy admin
The verified implementation stays lightweight while addressing a genuinely repeated cost.
One conditional check per page load
The mode check and script deregistration run once per request, adding negligible overhead compared to what Heartbeat itself would have cost.
No effect in Default mode
With the module left on its default setting, WordPress's own Heartbeat behavior applies exactly as it always has.
Often the single largest saving on a busy admin
Since Heartbeat fires repeatedly from every open tab, restricting or disabling it is frequently the most impactful single change available for admin performance.
Performance only, features preserved where configured
The code adjusts background request volume, never any capability or permission.
A performance setting, not an access control
This module only affects how often the admin pings the server for background updates; it has no effect on any capability or permission.
AJAX requests stay completely untouched
The explicit AJAX exclusion means no other AJAX-driven functionality, from this plugin or any other, gets disrupted by this module's logic.
Post locking stays intact where it's configured to
In the post-editor-only mode, the collision-detection feature that warns when two people edit the same post keeps working exactly as designed.
Configuration requires the same access as any other setting
Choosing a Heartbeat mode happens through the standard TheOneWP settings screen, available only to an administrator.
Built directly around WordPress's own Heartbeat internals
The supplied code integrates through APIs present in WordPress core; this page makes no compatibility claim beyond the verified implementation.
wp_deregister_script('heartbeat')
The native WordPress function used to remove the Heartbeat script from a given page's enqueued assets.
get_current_screen()
The native WordPress function used to confirm the current admin screen is specifically the post editor before deciding to preserve Heartbeat there.
heartbeat_settings filter
The native WordPress filter used by the companion Heartbeat Frequency setting to adjust the polling interval instead of disabling the script.
TheOneWP versus common alternatives
Compare the verified Heartbeat implementation with a typical single-toggle solution.
| Capability | TheOneWP Heartbeat | Other common solutions |
|---|---|---|
| Mode granularity | Three modes, including a post-editor-specific exception | Often a single on/off switch with no middle ground |
| AJAX safety | AJAX requests explicitly excluded from any interference | Some approaches don't account for Heartbeat's own AJAX transport |
| Screen detection reliability | Hooked where $pagenow and get_current_screen() are fully ready | An earlier hook can produce unreliable screen detection |
| Post editor features | Autosave locking and collision warnings specifically preserved | A blanket disable can silently remove features people rely on |
| Administration | Three labeled modes with plain-language descriptions | Usually a single technical toggle with no explanation of tradeoffs |
Choose the right mode in four steps
Confirm post-editor features still work if that mode was the one chosen.
Enable Heartbeat control
Activate the module from the TheOneWP System settings tab.
Choose a mode
Pick Default to leave WordPress unchanged, Disable everywhere for the maximum reduction, or the post-editor exception to keep autosave and locking intact.
Save the setting
Save the chosen mode; it applies immediately across the frontend and admin.
Confirm post-editor features still work, if that mode was chosen
Open a post for editing and confirm autosave and the "someone else is editing this" notice still appear as expected.
Start conservative, confirm before going further
The safest path trims what's clearly unnecessary before removing anything a site might actually depend on.
Start with the post-editor exception rather than a full disable
This mode trims the most unnecessary requests while keeping the features most sites actually rely on intact.
Reserve a full disable for sites that genuinely don't use these features
Confirm autosave locking and collision warnings aren't relied on anywhere before choosing Disable everywhere.
Consider Heartbeat Frequency instead of disabling, for a lighter touch
Raising the polling interval keeps every feature working, just checking in less often.
Revisit the setting after adding plugins that depend on Heartbeat
A newly installed plugin using Heartbeat for its own features may need it active on screens where it was previously disabled.
Avoid trading away features you actually use
A couple of assumptions are worth checking before settling on a mode.
Disabling Heartbeat everywhere without checking for dependent features
Post locking and autosave collision warnings specifically depend on Heartbeat in the post editor; a full disable removes those too.
Assuming the post-editor exception affects every admin screen
The allow_posts mode preserves Heartbeat only on the actual post and page editor screens, not on other admin pages that might also use it.
Expecting a visible difference from Default mode alone
Default mode makes no change at all; a reduction in requests only shows up once one of the other two modes is actually selected.
Heartbeat FAQ
These answers come directly from the verified class and its settings registration.
What does Heartbeat do?
It controls WordPress's Heartbeat API, offering three modes: the default behavior, disabling it entirely, or keeping it active only in the post editor.
What is WordPress's Heartbeat API?
It's a background request WordPress sends every fifteen to sixty seconds from an open admin screen, used for things like post locking, session checks, and autosave coordination.
Will disabling Heartbeat break anything?
It can affect features that rely on it, like autosave in the post editor and post lock notifications; the post-editor-only mode is designed to avoid that specific tradeoff.
What does "Disable everywhere except post editing" actually preserve?
It keeps Heartbeat active specifically on the post and page editor screens, preserving autosave coordination and collision warnings there.
Does this affect the frontend of the site?
Yes. Once either non-default mode is chosen, the frontend copy of Heartbeat is always removed, since it has no genuine use there.
Does this interfere with other AJAX-based features?
No. AJAX requests are explicitly excluded from this module's logic entirely.
Is there a way to reduce Heartbeat without disabling it completely?
Yes, through the separate Heartbeat Frequency setting, which adjusts how often it polls instead of removing it.
Why does this use wp_enqueue_scripts instead of an earlier hook?
Because $pagenow and get_current_screen() are only fully initialized by the time that hook fires, making screen detection reliable.
Will this help performance on a busy admin?
Often, yes. Since Heartbeat fires repeatedly from every open tab, restricting or disabling it is frequently the single largest performance gain available on the admin side.
Who can change the Heartbeat mode?
Only an administrator with access to the TheOneWP settings screen.
Stop letting Heartbeat ping every open tab regardless of need.Match it to what each screen actually uses.
Use Heartbeat to disable the request entirely, keep it only where post editing depends on it, or leave WordPress's own default in place.