Skip to content 
The WordPress Heartbeat API causes silent crashes on shared hosting due to frequent AJAX pings via admin-ajax.php. Server load and thus leads to noticeable delays in the backend. I'll show you how to safely tame the heartbeat frequency, reduce the server load on WordPress, and preserve important functions such as autosave.
Key points
- heartbeat frequency Extend in a targeted manner instead of completely deactivating.
- Auto-save Save in the editor, stop unnecessary pings.
- Shared resources Protect: CPU, RAM, I/O at a glance.
- Monitoring Before/after optimization for clear effects.
- Holistic Optimization: Caching, DB, CDN, PHP version.
Understanding Heartbeat: A useful feature with costs
The Heartbeat API sends periodic AJAX requests, typically every 15 seconds in the dashboard, to maintain sessions and save drafts; these Frequency However, this comes at a price. Each ping hits admin-ajax.php and triggers PHP processes, database accesses, and possibly plugin hooks. If the browser remains minimized, communication often continues and creates load peaks. Open tabs multiply the requests and slow down the editor's response time. On heavily shared systems, this leads to throttled processes, delayed autosaves, and subjectively „sluggish“ performance.
Why shared hosting is particularly affected
On shared hosting, I share CPU, RAM, and I/O with neighboring sites, which is why additional requests slow down the Capacity If several users come together or the dashboard remains open for hours, pings accumulate and block PHP workers. This increases TTFB and waiting times in the admin, and the server load WordPress climbs to short peaks. Simultaneous loads from neighboring sites cause a chain reaction: cache hits decrease, database locks increase, and the editor becomes sluggish. This is how I unintentionally turn a convenience feature into a source of load.
Recognize symptoms in good time
If I notice sluggish clicks in the backend, a noticeable number of POST requests in DevTools, and jerky input in the editor, this often points to heartbeat pings as the cause. Drivers Host warnings due to CPU spikes or memory limits also fit the picture. Weaker Core Web Vitals in the admin context and declining PageSpeed scores can also be indirect signals. In logs, I see clusters of admin-ajax.php accesses with „heartbeat“ action. If these effects occur during inactive editing, background tabs are wasting valuable resources.
How many requests are actually generated? A quick calculation
A standard interval of 15 seconds generates four pings per minute per tab. Three open admin tabs therefore mean 12 heartbeat requests per minute – per editor. If two people are working in parallel, that's already 24 per minute, or 1,440 per hour. If I set the interval in the admin to 60 seconds, I reduce the same load to three pings per minute per person. In the above example, the number drops from 24 to 6 per minute: a reduction of 75%. This simple calculation explains why the perceived response time improves significantly after throttling.
Take control: plugins or code
First, I'm going with a clear rule: increase frequency instead of just going with the flow. switch off. With tools such as Heartbeat Control, WP Rocket, or LiteSpeed Cache, I set 30–60 seconds in the admin, 120–180 seconds in the frontend, and disable pings on pages without interaction. If you prefer code, you can selectively slow down the API. Example: Set intervals to 60 seconds and leave autosave only in the editor. This way, I reduce load without compromising content security.
// Adjust intervals add_filter('heartbeat_settings', function($settings) { $settings['interval'] = 60; // Seconds return $settings; });
// Deactivate heartbeat, e.g., in the frontend add_action('init', function() { if ( ! is_admin() ) wp_deregister_script('heartbeat'); }, 1);
Block Editor vs. Classic: What Heartbeat really does in the editor
In the Classic Editor, autosave relies directly on Heartbeat. In the block editor (Gutenberg), autosave primarily runs via the REST API, but Heartbeat continues to perform important tasks such as post locking and session checks. Conclusion for practical use: A moderate extension (30–60 seconds) does not break autosave in the Block Editor, but it can delay the updating of locks and status messages. That's why I choose shorter intervals in the editor than in the rest of the admin area and test with real drafts whether locks and warnings work as expected.
Selective throttling based on screen and role
To achieve maximum control, I regulate Heartbeat depending on the screen and, if necessary, user roles. This keeps the editor fast, while quiet admin areas generate virtually no pings.
// 1) Different intervals depending on screen add_filter('heartbeat_settings', function($settings) { if ( function_exists('get_current_screen') ) { $screen = get_current_screen();
if ( $screen && in_array($screen->id, ['post','page','product']) ) { $settings['interval'] = 30; // Editor: more frequent for autosave/locking
} else { $settings['interval'] = 60; // other admin } } return $settings; }); // 2) Load heartbeat in admin only where necessary add_action('admin_enqueue_scripts', function($hook) {
$allowed = ['post.php', 'post-new.php', 'site-editor.php']; // Editor contexts if ( ! in_array($hook, $allowed, true) ) { wp_deregister_script('heartbeat'); } }, 1);
// 3) Treat frontend differently (e.g. for logged-in users) add_action('wp_enqueue_scripts', function() { if ( ! is_user_logged_in() ) { wp_deregister_script('heartbeat'); // Visitors: no heartbeat necessary } }, 1);
// Optional: Harmonize autosave interval add_filter('autosave_interval', function() { return 60; });With this setup, live functions remain active where they are useful and disappear in areas without interaction. In the shop or checkout context, I keep Heartbeat active and brief, while it remains inactive in the rest of the frontend.
Reasonable intervals and exceptions
I keep the editor functional while removing unnecessary pings on quiet pages, because Auto-save remains essential. 60 seconds in the admin often hits the sweet spot between security and load. In the frontend, I usually don't need Heartbeat at all, with exceptions for live components. For shops or dynamic UIs, I only plan shorter cycles where inputs are running. This keeps the site fast and stable without compromising content.
| Context | Recommended interval | Note |
|---|---|---|
| Dashboard in general | 60 s | Load decreases significantly, sessions remain active. |
| post editor | 30–60 s | Autosave and locking still usable. |
| Static front end | Disable | No interaction, so no pings necessary. |
| Interactive front end (e.g., checkout) | 15–30 s | Only on affected Pages activate. |
| Long-open admin tabs | 90–120 s | Save resources when the tab remains in the background. |
Streamline heartbeat payload: less data per ping
In addition to frequency, the amount of data transferred is also important. Some plugins attach additional information to Heartbeat. I can use filters to further reduce server load by cutting off unnecessary payloads or simplifying responses.
// Serverantwort für Heartbeat-Anfragen optimieren
add_filter('heartbeat_send', function($response, $data, $screen_id) {
// Beispiel: große, selten benötigte Blöcke entfernen
unset($response['irrelevante_status']);
// Eigene, zu große Daten nicht mitschicken
if ( isset($data['my_plugin_heavy']) ) {
unset($data['my_plugin_heavy']);
}
return $response;
}, 10, 3);
// Auf eingehende Heartbeat-Daten reagieren (z.B. Logging vermeiden)
add_action('heartbeat_received', function($response, $data, $screen_id) {
// Teure Vorgänge nur auf relevanten Screens ausführen
if ( $screen_id !== 'post' ) {
// ggf. Frühabbruch in eigenen Hooks
}
}, 10, 3);I then check the size of the heartbeat responses in DevTools. If the payload shrinks, this reduces the load on the database and PHP, especially during peak times.
Holistic optimization: caching, DB, media, PHP
Heartbeat is one piece of the puzzle, but I achieve real impact when I combine caching, database maintenance, and media optimization to Load Page and object caching reduce database queries in the admin flow. I consistently reduce the size of images and activate lazy loading. I regularly clean up revisions, transients, and sessions. I also check the PHP version and remove unnecessary add-ons; I go into more detail in this guide to Plugin anti-patterns.
In the database, I pay attention to autoloaded options, bloated revisions, and outdated transients. An upper limit for revisions prevents uncontrolled growth without sacrificing security. Object caching (e.g., Redis) helps noticeably, especially in the admin area, because recurring requests find their data faster. And: Fewer activated plugins mean fewer hooks that each heartbeat call can trigger.
Combining WP-Cron and Heartbeat
Many installations use Heartbeat indirectly, while WP-Cron triggers tasks in parallel, which can cause the Worker takes up additional resources. I therefore check the cron jobs, summarize frequencies, and avoid unnecessary events. In the case of a permanent load, I switch to real system cron and deactivate wp-cron.php calls by visitors. This stabilizes response times and protects the admin interface. If you want to delve deeper into this topic, you will find practical steps in my article on Optimize WP-Cron.
PHP workers, concurrency, and AJAX queues
AJAX requests compete with page views, which is why a limited number of PHP workers can handle the waiting time significantly increased. If heartbeat calls pile up, the backend appears to freeze, even though the server remains accessible. I therefore aim for fewer but more meaningful pings and caches that relieve PHP. As projects grow, I check for higher worker quotas or change the tariff. If you want to understand how this works, read my guide to PHP worker balance.
Browser and usage behavior: Background tabs and timer throttling
Modern browsers throttle timers in background tabs, but heartbeat calls do not disappear completely—they just become less frequent. The decisive factor is how many windows, profiles, and devices are open at the same time. I make editors aware of this: close unnecessary admin tabs, avoid long periods of inactivity, and, if in doubt, save drafts before leaving your workstation. Technical throttling via code is the perfect complement to these rules of conduct.
Troubleshooting: typical conflicts and reliable tests
If problems arise after throttling, I first check: Is post-locking working? Are session timeouts still being reported? Is checkout running stably in real-time forms? I temporarily deactivate individual optimization steps, test with different roles, and switch between Classic and Block Editor. In DevTools, I filter the network for „action=heartbeat“ and observe the interval, duration, and size. On the server side, PHP and error logs provide clues if hooks from plugins slow down Heartbeat unexpectedly.
Monitoring and test plan: How I measure the effect
I'll start with a before profile: number of admin-ajax.php requests per minute, CPU share, RAM, and editor response time to determine the Base After that, I set new intervals and repeat the measurements under the same conditions. In Browser DevTools, I check whether pings are less frequent and complete more quickly. In the hosting panel, I observe whether load peaks are flattening out. Only when the results are stable do I transfer the settings to live systems.
Target values and evaluation
My goals for the admin section are: 60-second intervals on general screens, 30–60 seconds in the editor, less than 300 ms TTFB for heartbeat responses, and an average response size of less than 10 KB—depending on plugins. Under load (multiple users, multiple tabs), there should be no long queues; worker utilization remains smooth instead of spiking. If I achieve this, the editorial team will notice the difference immediately.
When is a hosting upgrade advisable?
Even with a clean configuration, a project can use the shared resources of a tariff. blow up. More simultaneous editors, shop checkout, search, or chat widgets drive up AJAX load. In such cases, I calculate the costs: time lost by the team vs. additional costs for more workers, RAM, and CPU. An upgrade is often worthwhile as soon as editors are blocked on a daily basis. I start with the next plan and test whether editing remains smooth.
Briefly summarized
The Heartbeat API provides valuable real-time functionality, but it puts a strain on shared hosting if I don't set intervals and contexts. control. With longer cycles in the admin area, the frontend disabled, and autosave enabled in the editor, I significantly reduce the number of requests. Caching, database organization, lean plugins, and an up-to-date PHP version provide additional stability. In combination with clean WP-Cron and sufficient PHP workers, the sluggish clicks in the backend disappear. This allows me to maintain comfort and security while reducing the load on my hosting.
