Contents
Introduction — What the WordPress Heartbeat API is and why you might reduce it
The WordPress Heartbeat API is a small JavaScript-driven system that polls the server on a regular interval (default ~15 seconds) to exchange “heartbeat” data. Core features that rely on Heartbeat include post locking (preventing two editors from overwriting each other), auto-save, session expiration notices, certain admin notices, some plugin interactions and real-time features in third-party tools.
On high-traffic dashboards or low-resource hosts, frequent heartbeats can cause high admin-ajax.php request volume, increased CPU and memory use, and sometimes elevated database or PHP-fpm load. Reducing heartbeat activity (increasing interval or limiting when/where it runs) can reduce load while preserving necessary features when appropriate.
High-level approaches
- Deregister or dequeue heartbeat completely — stops all Heartbeat activity (safe for front-end when you don’t need it, dangerous in admin/post editor).
- Change heartbeat interval — increase the time between requests (e.g., 15s → 60s or more).
- Conditionally control heartbeat — restrict heartbeat to particular screens, user roles, or only when the page is focused.
- Server-side short-circuiting — intercept heartbeat AJAX server-side and return minimal output (advanced, risky).
Important cautions
- Disabling heartbeat entirely in the WordPress admin can break autosave, post locking and other real-time features. Do not disable heartbeats globally in wp-admin unless you understand the consequences.
- Always test changes on a staging site first.
- Prefer reducing frequency and scoping changes to specific pages, roles or contexts rather than blocking heartbeat globally.
Method 1 — Deregister Heartbeat on the front-end (safe approach)
If you only need Heartbeat for admin screens, remove the heartbeat script from the front-end. This is the simplest and safest global reduction.
Example: plugin or theme functions.php (deregister on front-end)
Why this is safe: core admin functionality is unaffected because the script is still present in the admin. Only front-end heartbeat activity (which some plugins use) is removed.
Method 2 — Reduce the interval with a small admin script
A common and compatible approach is to increase the heartbeat interval in admin screens (or particular admin screens) by injecting a tiny JavaScript that sets the global wpHeartbeatSettings.interval. This preserves functionality but reduces frequency.
How it works
- WordPress exposes a global JavaScript object wpHeartbeatSettings with an interval property.
- If you enqueue a script that depends on heartbeat (so heartbeat is loaded first), you can set wpHeartbeatSettings.interval = X (seconds).
- Typical safe values: 60–300 seconds depending on how responsive you need the features to be.
Example: enqueue an inline or small file script for admin screens
Notes:
- Placing this only on admin pages ensures the front-end is unaffected.
- If a plugin relies on a shorter heartbeat interval for vital functionality, increasing the interval may change its behavior.
Method 3 — A control script that adapts interval by focus and screen
A flexible JavaScript approach boosts interval when the browser tab is not focused or when the user is not editing content, and lowers it when focus returns. This reduces background load while keeping responsive behavior during active editing.
Example: adaptive heartbeat control JavaScript (enqueue it with heartbeat dependency)
(function(){
// Store original interval (if available), and define a low activity interval
var original = (typeof wpHeartbeatSettings !== undefined wpHeartbeatSettings.interval) ? wpHeartbeatSettings.interval : 15
var idleInterval = 300 // 5 minutes when idle
var activeInterval = Math.max(60, original) // at least 60s while active in admin
// Try to set a reasonable default immediately
if ( typeof wpHeartbeatSettings !== undefined ) {
wpHeartbeatSettings.interval = activeInterval
}
// When tab is hidden, increase the interval
(window).on(blur, function() {
if ( typeof wpHeartbeatSettings !== undefined ) {
wpHeartbeatSettings.interval = idleInterval
}
})
// When tab regains focus, reduce the interval so features are responsive
(window).on(focus, function() {
if ( typeof wpHeartbeatSettings !== undefined ) {
wpHeartbeatSettings.interval = activeInterval
}
})
// Optional: adapt based on specific admin pages via body class checks (example)
(document).ready(function() {
if ( (body).hasClass(post-php) (body).hasClass(post-new-php) ) {
// editing screen — keep it more responsive
if ( typeof wpHeartbeatSettings !== undefined ) {
wpHeartbeatSettings.interval = Math.max(30, original)
}
}
})
})(jQuery)
How to enqueue this script from PHP:
Method 4 — Conditionals: limit heartbeat based on screen or role
Often you only need heartbeat on certain admin screens (post editor) and unnecessary elsewhere. Use the current_screen or get_current_screen APIs to scope changes.
Examples for scoping
base, array( post, post-new ), true ) ) {
// For editors, set a moderate interval
interval = 30
} else {
// For other screens, set a high interval or disable
interval = 300
}
js = (function(){ if ( typeof wpHeartbeatSettings !== undefined ) { wpHeartbeatSettings.interval = . intval( interval ) . } })()
wp_enqueue_script( heartbeat )
wp_register_script( heartbeat-scope, )
wp_enqueue_script( heartbeat-scope )
wp_add_inline_script( heartbeat-scope, js )
}
?>
Method 5 — Server-side interception (advanced and risky)
You can intercept heartbeat AJAX requests server-side and return a lightweight/empty response. This reduces processing but can break heartbeat-driven features or plugins that expect server responses. Use only if you understand the impact.
Example: short-circuit heartbeat AJAX when not needed
Do not apply the above to administrators or editors unless you have alternative autosave/post-locking logic.
Comprehensive example — a small plugin that provides a control UI (concept)
Below is a compact plugin skeleton that demonstrates combining PHP conditionals and an external JS file to adjust heartbeat per screen and per focus state. This is an example production plugins should provide an options page and sanitization for admin inputs.
45,
idleInterval => 300,
targets => array( post, post-new ), // screens to treat as editors
)
wp_localize_script( shc-adaptive, shcConfig, config )
}
?>
// File: shc-adaptive.js
(function(){
var cfg = window.shcConfig {}
var activeInterval = cfg.activeInterval 45
var idleInterval = cfg.idleInterval 300
if ( typeof wpHeartbeatSettings !== undefined ) {
wpHeartbeatSettings.interval = activeInterval
}
(window).on(blur, function() {
if ( typeof wpHeartbeatSettings !== undefined ) {
wpHeartbeatSettings.interval = idleInterval
}
})
(window).on(focus, function() {
if ( typeof wpHeartbeatSettings !== undefined ) {
wpHeartbeatSettings.interval = activeInterval
}
})
// Optionally check body class to detect editor screens:
(document).ready(function(){
var isEditor = (body).hasClass(post-php) (body).hasClass(post-new-php)
if ( ! isEditor ) {
// Increase interval for non-editor admin pages
if ( typeof wpHeartbeatSettings !== undefined ) {
wpHeartbeatSettings.interval = Math.max(120, activeInterval)
}
}
})
})(jQuery)
Troubleshooting and validation
- Open your browser dev tools → Network tab. Filter by admin-ajax.php and watch requests with action=heartbeat. Confirm the request interval changed to your new value.
- Test core features: open two browser windows editing the same post to ensure post locking and autosave still work (if you intended to preserve those features).
- Verify plugins that depend on real-time updates still operate correctly on the screens you need.
- Monitor server load and admin-ajax.php request count before and after changes (use server logs, host monitoring or NewRelic).
Best practices and recommendations
- Prefer increasing interval and scoping changes over outright removal in admin.
- Keep heartbeat enabled for editors and admins who actively edit content.
- Consider combining multiple strategies: deregister on front-end, increase interval on most admin pages, and provide responsive intervals on active editor pages.
- Document changes in your site maintenance notes so future administrators understand the heartbeat modifications.
Final checklist before deployment
- Backup site and database.
- Test on staging environment (simulate concurrent editing, autosave, and plugins that rely on heartbeat).
- Deploy during off-peak hours and monitor logs and site health.
|
|
Acepto donaciones de BAT's mediante el navegador Brave 🙂 |