Reduce the WordPress Heartbeat API frequency if your admin area feels slow, your hosting CPU spikes, or your WooCommerce store gets sluggish during busy hours. The Heartbeat API is useful, but it can quietly send frequent background requests that add load to your server. On small sites, that may not matter. On busy sites, membership platforms, and stores, it can become a real performance cost.
TLDR: The WordPress Heartbeat API keeps the admin area active by sending AJAX requests in the background, often every 15 to 60 seconds. A store with 8 logged-in staff members editing products could generate hundreds of extra admin-ajax.php requests per hour. In one common scenario, reducing Heartbeat from 15 seconds to 60 seconds can cut those requests by up to 75%. Do not disable it blindly; limit it in the right places instead.
What Is the WordPress Heartbeat API?
The WordPress Heartbeat API is a built-in system that lets the browser and server communicate while you work inside WordPress. It uses the file admin-ajax.php to send periodic background requests.
These requests support several useful features:
- Post autosaves while editing content.
- Post locking, so two users do not overwrite each other.
- Login session checks, including expiry warnings.
- Plugin notifications from tools such as security, forms, and ecommerce plugins.
- Dashboard updates in the WordPress admin area.
Heartbeat is not malware. It is not a bug. It is part of WordPress core. The issue is frequency. When the interval is too aggressive, especially with many logged-in users, the server has to answer constant requests that may not be needed.
How Heartbeat Affects Performance
Heartbeat requests are usually light, but they are still real HTTP requests. Each one may load WordPress, check permissions, run hooks, and trigger plugin code. That can use CPU, memory, and PHP workers.
On shared hosting, this can hurt quickly. Shared plans often have strict limits on CPU seconds and concurrent PHP processes. If Heartbeat keeps calling admin-ajax.php, normal visitors may have to wait longer for pages to load.
The most common symptoms include:
- Slow WordPress admin screens.
- High CPU usage in hosting reports.
- Frequent
admin-ajax.phpentries in access logs. - Autosave delays in the editor.
- WooCommerce cart or checkout slowdowns.
- 503 or 508 errors during peak use.
The catch is that Heartbeat often looks harmless at first. You may check the site homepage and see decent speed results. Then you open the hosting control panel and find thousands of AJAX requests sitting in the logs. It drives me crazy that many performance scans miss this because they test public pages, not logged-in admin behavior.
Where Heartbeat Runs Most Often
Heartbeat does not run at the same rate everywhere. WordPress can change the interval based on context.
- Post editor: Often every 15 seconds.
- Dashboard: Often around every 60 seconds.
- Frontend for logged-in users: Depends on themes and plugins.
The post editor usually needs faster communication because autosave and post locking matter. The main dashboard rarely needs such frequent updates. The frontend often does not need Heartbeat at all unless a plugin depends on it.
When You Should Optimize Heartbeat
You do not need to touch Heartbeat on every site. A small blog with one editor and strong hosting may run fine with default settings. Optimization becomes more useful when the site has regular logged-in activity.
Consider adjusting Heartbeat if you run:
- A WooCommerce store with staff managing orders.
- A membership site with many logged-in users.
- An online course platform.
- A busy editorial site with several authors.
- A client site hosted on a limited shared plan.
- A site where
admin-ajax.phpdominates server logs.
For example, five editors working in the post editor at a 15-second interval can create about 1,200 Heartbeat requests per hour. Move that interval to 60 seconds and the number drops to about 300. That is a serious reduction with little downside for many teams.
Image not found in postmetaHow to Check If Heartbeat Is Causing Load
Start with evidence. Guessing can waste time and create odd bugs.
- Check hosting analytics. Look for CPU spikes and high usage of
admin-ajax.php. - Review access logs. Search for repeated POST requests to
/wp-admin/admin-ajax.php. - Use browser developer tools. Open the Network tab while logged into WordPress and watch AJAX requests.
- Check plugin monitors. Tools like Query Monitor can help identify slow hooks and admin requests.
- Compare logged-in and logged-out speed. Heartbeat affects logged-in sessions much more often.
If admin-ajax.php appears every few seconds across many sessions, you have a clear signal. If requests are rare, your bottleneck may be elsewhere.
Optimization Option 1: Use a Plugin
The simplest method is to use a performance plugin that includes Heartbeat controls. Many caching and optimization plugins let you reduce or disable Heartbeat by location.
Look for settings that allow you to control Heartbeat in these areas:
- WordPress dashboard
- Post editor
- Frontend
A safe setup for many sites is:
- Dashboard: Reduce to 60 seconds.
- Post editor: Keep enabled, but use 30 to 60 seconds if autosave still works well.
- Frontend: Disable unless a plugin requires it.
Honestly, it feels like some sites send background pings just to prove they are awake. If nobody needs live frontend updates, turning them off can make the site feel cleaner and less wasteful.
Optimization Option 2: Add Code to functions.php
If you prefer not to add another plugin, you can control Heartbeat with code. Use a child theme or a small site-specific plugin. Do not edit a parent theme directly.
To change the Heartbeat interval, you can add:
add_filter( 'heartbeat_settings', 'custom_heartbeat_interval' );
function custom_heartbeat_interval( $settings ) {
$settings['interval'] = 60;
return $settings;
}This sets Heartbeat to 60 seconds. It reduces request volume while keeping key features available.
To disable Heartbeat on the frontend only, use:
add_action( 'init', 'disable_heartbeat_frontend', 1 );
function disable_heartbeat_frontend() {
if ( ! is_admin() ) {
wp_deregister_script( 'heartbeat' );
}
}This is often safer than disabling Heartbeat everywhere. Editors still get autosaves and post locking, while logged-in frontend visitors stop generating extra pings.
What Not to Do
Do not disable Heartbeat across the whole site without testing. That can break useful features. Autosaves may stop. Post locking may fail. Some plugins may lose live status checks.
Be extra careful on sites that use:
- WooCommerce admin order screens.
- Live chat plugins.
- Security plugins with session checks.
- Learning management systems.
- Membership dashboards.
If a plugin relies on Heartbeat, full removal can cause strange behavior. A better first step is to slow the interval, then test important workflows.
Recommended Settings by Site Type
- Small blog: Leave defaults or set dashboard to 60 seconds.
- Editorial site: Set editor to 30 or 60 seconds, dashboard to 60 seconds.
- WooCommerce store: Keep admin Heartbeat active, reduce dashboard frequency, test checkout and order management.
- Membership site: Disable frontend Heartbeat only after confirming member features still work.
- Shared hosting site: Reduce Heartbeat aggressively, but avoid full admin disablement.
Best Practices for Stable Results
Heartbeat optimization works best as part of a broader performance plan. Also review caching, database cleanup, object caching, plugin quality, and hosting limits.
Use these practical rules:
- Measure first. Check logs before changing settings.
- Change one thing at a time. This makes issues easier to trace.
- Keep autosave working. Content loss is worse than a small performance gain.
- Test as a logged-in user. Public speed tests will not show the full picture.
- Watch CPU after changes. Confirm the request count actually drops.
The WordPress Heartbeat API is useful, but it should not run harder than your site needs. For most performance-sensitive sites, the best answer is not total removal. It is controlled frequency, frontend restraint, and careful testing. Start with a 60-second interval in low-risk areas, monitor server load, and keep the features your team depends on.
