You open wp-admin with three tabs — WooCommerce products, orders, a product edit screen — and the dashboard turns sluggish. Or worse: your host emails about admin-ajax.php and thousands of requests per hour. You search "disable WordPress Heartbeat," find a functions.php snippet that kills everything, and two days later a writer loses an hour of work because autosave stopped responding.
You're not alone. WordPress's Heartbeat API is useful — edit locking, autosave, admin notifications — but left on defaults it turns every wp-admin tab into a regular pulse to admin-ajax.php. On a WooCommerce store with 15 active plugins, a support team on four tabs, and shared hosting, CPU climbs while front-end traffic stays flat.
This guide exists because we see two extremes every week: disable everything (and break the editor), or do nothing (and pay for bigger hosting unnecessarily). The right answer is in the middle: control Heartbeat per zone, keep 30–60 s minimum in the editor, cut the public front, lighten lists — with tested presets instead of copy-paste hacks.
Why read this article? You'll understand what Heartbeat actually does, how to diagnose whether it's Heartbeat (or something else) saturating admin-ajax.php, which 5 presets fit your profile (blog, WooCommerce, agency, builder), and how to optimize in 7 steps without losing autosave or edit locks. Comparison tables, error playbook, checklist for this week, FAQ from real support tickets.
What you'll learn: Heartbeat anatomy · 5 warning signs · requests-saved math · 4 configurable zones · WooCommerce preset · WP Rocket conflicts · multisite · when not to disable everything.
Let's start with diagnosis — then move to action.
Sign up and unlock advanced presets
Per-role rules, JSON export, and agency runbook — on top of public resources.
No credit card · Public checklists stay free.
What Heartbeat is — and why admin-ajax.php spikes
Before changing anything, name the problem. Many hosts send an admin-ajax.php chart without saying which action consumes resources. Heartbeat is only one of dozens.
How Heartbeat works
WordPress loads heartbeat.min.js in admin (and sometimes on the front). Every X seconds, the browser sends a POST to:
/wp-admin/admin-ajax.php?action=heartbeat
The server responds with JSON: session state, autosave, post lock, dashboard notifications, sometimes third-party plugin hooks.
Definition: the 4 zones to know
| Zone | Where | Main role |
|---|---|---|
| Public front | Visitor pages | Rarely needed — 0 pulses often enough |
| Dashboard | wp-admin index.php | Widgets, notifications, updates |
| Content lists | Posts, products, WC orders | Counter refresh, bulk actions |
| Editor | Gutenberg, Classic, product screen | Autosave, co-editing lock, revisions |
Optimizing Heartbeat means tuning each zone differently — not one global switch.
What actually overloads your server
- Multiple wp-admin tabs open (each tab = its own timer)
- Default 15 s interval on dashboard + lists + editor at once
- Plugins hooking
heartbeat_send/heartbeat_received(WooCommerce, builders, SEO) - Heartbeat on the front when visitors don't need it
- Shared hosting with limited PHP workers — slow admin drags the front
What Heartbeat protects (don't break this)
- Gutenberg autosave and Classic editor
- Edit lock — "X is editing this post"
- Unread notifications in the admin bar
- Some builders (Elementor, Divi) relying on short pulses while editing
Real-world example
An agency runs 12 WooCommerce sites. Each manager keeps 4 tabs open. Default 15 s interval → ~960 Heartbeat requests/hour/user for Heartbeat alone. Shared host sends a CPU alert. Cause: no Heartbeat tuning + multi-tab habits — not a "site too big."
Heartbeat is a useful admin session pulse that's expensive on WordPress defaults. The public front is the first zone to lighten; the editor is the last to touch.
"Am I affected?" — 5 signs
- wp-admin is slow while the public site is fast (or cached).
- Host email citing
admin-ajax.phpwith peaks only during business hours. - Multiple admin tabs per person (support, editorial, inventory).
- WooCommerce: order/product lists take 5+ seconds without a huge catalog.
- You tried a "disable heartbeat" snippet and got autosave complaints.
If two or more match: per-zone Heartbeat optimization is worth it — after diagnosing the admin-ajax.php action.
US hosting benchmarks: Heartbeat impact by provider
Heartbeat load hits different US hosts in very different ways. The number of PHP workers, container isolation, and caching architecture all change how much Heartbeat pulses stress your server.
| Host | PHP workers | Heartbeat risk | Best practice |
|---|---|---|---|
| WP Engine | 30–50 per server | Low | Per-zone tuning if team >10 |
| Kinsta | 12–24 per site pod | Medium | Apply Agency preset at 5+ staff |
| SiteGround | 4–8 per account | High | Cut front; dashboard at 120 s |
| Cloudways | 8–16 (configurable) | Medium | Tune per zone; raise worker count |
| GoDaddy Managed | 4–6 per account | Very high | Disable front; editor max 60 s |
| Liquid Web | 12–20 per server | Low-Medium | Standard preset is enough |
| Pressable | 8–12 per site | Low | Default preset works well |
Why this matters for US hosting: On GoDaddy Managed or entry-level SiteGround, four admin tabs at 15 s default can consume the full PHP worker pool — spilling over into front-end visitor slowdowns during business hours. On WP Engine or Kinsta, the same load is barely noticeable but scales poorly when your team grows past 5–8 concurrent admin users.
Real test data across three US hosts (WooCommerce store, 50 products, 10 plugins, 4 admin tabs):
- GoDaddy Managed: 98% PHP worker saturation, TTFB spike from 400 ms to 3.2 s
- SiteGround GrowBig: 72% worker saturation, admin pages loading 5–8 s
- Kinsta Pro: 18% pod usage, no measurable front-end impact
Bottom line: If your US host logs show PHP worker exhaustion during office hours, Heartbeat tuning delivers the fastest ROI of any single performance change — often cutting admin-ajax.php requests by 60–80% in under ten minutes.
Step-by-step optimization guide (7 phases, editor-safe)
This is the core tutorial. Block 45 min to 1.5 h on staging or a quiet window. Measure before/after.
1Diagnose admin-ajax.php (10 min)
- Open wp-admin → Tools → Site Health (or DevTools Network)
- Filter requests to
admin-ajax.php - Note the most frequent
actionparameter - Count how many admin tabs you keep open
| Frequent action | Lead |
|---|---|
heartbeat | This guide — per-zone optimization |
woocommerce_* / as_async_request_queue_runner | WooCommerce Action Scheduler, not Heartbeat |
| Third-party plugin name | That plugin's settings or support |
2Pick your preset profile
Three questions:
- Active WooCommerce store? → WooCommerce preset
- Agency / multi-author? → Agency preset
- Elementor or visual builder? → Builder preset
Otherwise: Blog / media preset.
3Install Heartbeat Control Manager
- Install Heartbeat Control Manager by Volade
- Open Settings → Heartbeat Control
- Read the effective config preview on the current screen — confirms what actually applies
Without a Volade account, presets, JSON export, 2 rules per screen, and stats work. Free account: 15–30 s intervals, CPT rules, inactive-tab slowdown. V+ Premium: role rules, URL regex, pulse log + CSV.
4Apply the preset (WooCommerce example)
The WooCommerce preset sets:
| Zone | Preset setting |
|---|---|
| Public front | Disabled |
| Editor / product screen | 30 s |
| Dashboard | 60 s |
| Lists (products, orders) | Disabled or lightened |
customer / subscriber roles | Heartbeat off |
Click Apply — fine-tune afterward.
5Verify autosave and edit lock
- Open a post or product for editing
- Type text, wait 35–45 s, reload — draft should be saved
- Open the same post in a second browser (admin account) — lock should appear
- If editor interval > 120 s, the UI shows an autosave warning — don't ignore it
6Measure requests saved
The plugin dashboard shows:
- Pulses today
- Running total
- Requests avoided (estimate vs WordPress default)
Repeat the same admin workflow as before (same tabs, 15 min) and compare.
7Deploy to production and document
- Go live in off-peak hours
- Export config as JSON for other sites (agency)
- Disable old
functions.phpsnippets or duplicate Heartbeat plugins - Monitor 48 h: autosave tickets, admin slowness, host alerts
— Volade support teamSites that apply the WooCommerce preset then test five minutes in the editor avoid 90% of rollbacks. Disabling Heartbeat without testing autosave saves CPU and loses articles.
Diagnose action → pick preset → apply → test autosave → measure → prod → 48 h watch. Don't skip step 5.
Code-based optimization techniques
For developers who prefer code over plugins, here are the three main approaches ordered by safety and precision.
1. heartbeat_settings filter (safest)
Changes the interval globally without disabling the API:
add_filter('heartbeat_settings', function($settings) {
$settings['interval'] = 60; // Default 15 → 60 seconds
return $settings;
});
Pros: autosave and edit locks keep working. Cons: applies to all admin screens — no per-zone control without extra conditions.
2. Screen-specific unregister
Disables Heartbeat on targeted screens while keeping it in the editor:
add_action('admin_enqueue_scripts', function($hook) {
if (in_array($hook, ['edit.php', 'index.php'])) {
wp_deregister_script('heartbeat');
}
});
Pros: per-screen control. Cons: easy to miss a hook — our support teams see this as the top cause of "lost draft" tickets when the conditional isn't carefully scoped.
3. JS pulse override on inactive tabs
Uses the browser Page Visibility API to reduce Heartbeat frequency when a tab is backgrounded:
add_action('admin_footer', function() {
echo '<script>
document.addEventListener("visibilitychange", function() {
wp.heartbeat.interval(document.hidden ? 120 : 30);
});
</script>';
});
Pros: respects user behavior. Cons: depends on JS execution — harder to debug with minified assets.
Which approach for US agencies?
If you manage multiple client sites, the heartbeat_settings filter in a site-specific plugin is cleaner than editing functions.php on each install. Exportable, version-controllable via Git, survives theme switches. For per-client granularity, pair it with a JSON config file stored outside wp-content.
Your options in 2026
Not every site needs the same tool. Honest approaches — without blindly disabling everything.
Option 1 — functions.php snippet
For: comfortable developers, single site, minimal needs.
| Pros | Cons |
|---|---|
| No extra plugin | No stats, no fine zones |
| Quick paste | Often breaks autosave if wrong |
| Free | Hard to maintain across 10 agency sites |
Option 2 — WP Rocket (or similar) — Heartbeat tab
For: you already pay for WP Rocket for front cache.
| Pros | Cons |
|---|---|
| Fits your perf stack | Less granular than HCM |
| Good for front | Double config risk with another Heartbeat plugin |
| — | No per-screen / role rules |
Option 3 — Heartbeat Control Manager by Volade (recommended)
For: WooCommerce, agencies, builders — you want presets + stats + JSON export.
| Pros | Cons |
|---|---|
| 5 one-click presets | One more plugin to maintain (lightweight) |
| 4 separate zones + screen rules | V+ for URL rules / CSV log |
| Conflict detection Heartbeat Control / WP Rocket | — |
WP-CLI: wp hcm status, wp hcm preset woocommerce | — |
| Free without account for essentials | — |
We built Heartbeat Control Manager because merchants and agencies deserved better than a copied snippet — with autosave guardrails and "requests avoided" numbers to justify the change to clients.
Full comparison table
| Criteria | Default WP | functions.php snippet | WP Rocket Heartbeat | Heartbeat Control Manager |
|---|---|---|---|---|
| Disable front | No | Yes (if coded well) | Yes | Yes — 3 front modes |
| Dedicated editor interval | Fixed 15 s | Variable | Partial | 30–300 s + warning >120 s |
| Separate lists / dashboard | No | Rarely | Partial | Yes |
| Requests avoided stats | No | No | No | Yes |
| JSON export multi-site | No | No | No | Yes — no account |
| WooCommerce presets | No | No | No | Yes — one click |
| Conflict detection | No | No | No | Yes |
| Price | $0 | $0 | ~$59/yr (cache included) | Free (optional V+) |
One site, confident dev → snippet possible. Already on WP Rocket → use its Heartbeat tab, not a second plugin. WooCommerce / agency / need proof → Volade HCM.
No credit card · Public checklists stay free.
Common mistakes and how to avoid them
Even with a good preset, these issues show up in most Heartbeat optimizations.
"I disabled everything and autosave broke"
Why: aggressive snippet or "max perf" preset without reading the editor warning.
How to avoid:
- Keep 30–60 s minimum in the editor
- Always test on a draft before production
- Use the plugin's built-in autosave warning
"admin-ajax.php is still high after optimization"
Why: the culprit wasn't Heartbeat — WooCommerce Action Scheduler, admin search plugin, or third-party monitoring.
How to avoid:
- Re-check the action= diagnosis in DevTools
- Try Plugin Usage Detector if you suspect a zombie plugin
"Conflict with WP Rocket / Heartbeat Control"
Why: two plugins modify the same API.
How to avoid:
- One active tool — HCM detects Heartbeat Control and WP Rocket and warns you
- If WP Rocket handles Heartbeat, disable redundant HCM settings (or vice versa)
"My client keeps six wp-admin tabs open"
Why: human habit, not a WordPress bug.
How to avoid:
- Agency preset + inactive-tab slowdown (Volade account)
- Training: close unused tabs — no preset fixes eight timers per person
"Elementor / builder acts weird after tuning"
Why: editor interval too long for the visual builder.
How to avoid:
- Elementor / Builder preset (editor 30 s, lighter media library)
- Don't apply "max perf" on a 100% builder site
Don't disable everything · diagnose the right action · one Heartbeat plugin · test the editor · train on tabs. Four zones, four rules — not one global kill switch.
Your action plan this week
Use this checklist as your execution layer — print it, share internally.
Heartbeat optimization checklist
- Measure
admin-ajax.php— note dominant action (heartbeator other) - Full backup before changes
- Choose preset: Blog / WooCommerce / Agency / Builder / Max perf
- Install Heartbeat Control Manager (or configure WP Rocket — not both)
- Apply preset + verify effective config preview
- Test autosave + editor lock (5 min)
- Note "requests avoided" in the plugin
- Export JSON config for clone sites (agency)
- Remove old
disable_heartbeatsnippets in duplicate - Monitor 48 h — support + host
Recommended tools
- Heartbeat Control Manager by Volade
- Heartbeat API docs — Jorijn Schrijvershof
- Taming the Heartbeat API — Delicious Brains
- Volade V+ pricing — role rules, URL, CSV log across the catalog
Resources & PDF guide
Download public checklists from this article's resource panel. Members unlock the 16-page complete guide with host matrices, annotated JSON presets, and admin-ajax decision tree.
Sign up and unlock advanced presets
Per-role rules, JSON export, and agency runbook — on top of public resources.
No credit card · Public checklists stay free.
US e-commerce: Heartbeat optimization for WooCommerce stores
US WooCommerce stores face specific Heartbeat challenges that European stores typically don't:
- Sales tax plugins (TaxJar, Avalara) often hook into
heartbeat_receivedto refresh tax tables on order screens — disabling Heartbeat entirely can delay tax calculations - QuickBooks / Xero sync plugins frequently tick on Heartbeat to trigger accounting syncs
- USPS / FedEx / UPS live rates may use Heartbeat polls to refresh shipping quotes in the admin order editor
- Multi-warehouse inventory plugins (ShipStation, Skubana) poll via Heartbeat when editing products
US-specific tuning strategy:
- Audit handlers first — use Heartbeat Control Manager's pulse log to see which plugins attach to
heartbeat_receivedon each admin screen - Keep order edit at 30–60 s if you run real-time tax or shipping plugins
- Agency preset + inactive-tab slowdown is ideal for US teams managing multi-state stores
- Kinsta and WP Engine users can optimize Heartbeat independently — their CDN and caching layers don't interact with admin AJAX
US case study — New York WooCommerce store:
A fashion retailer with 2,000 SKUs, 8 support staff, and TaxJar integration logged 12,400 daily Heartbeat pulses across the team. Admin order pages took 6–8 s to load. After applying the WooCommerce preset (editor 45 s, dashboard 120 s, front disabled), pulses dropped to 1,800/day — an 85% reduction. Admin load times fell to under 2 s. TaxJar calculations continued working without issues. No autosave problems over a 3-month follow-up. The client deferred a planned $200/mo hosting upgrade.
FAQ — questions we get most
Should I disable Heartbeat completely?
No, except very specific cases (brochure site with rare admin editing). Disable the front, lighten dashboard and lists, keep the editor at 30–60 s minimum.
How many requests can I save?
Ballpark: going from 15 s to 60 s on dashboard + disabling front can cut 60–85% of Heartbeat pulses — depending on open tabs. The plugin shows an estimated "requests avoided."
Does Heartbeat Control Manager require a Volade account?
No. Presets, essential settings, JSON import/export, and 2 rules per screen work without an account. Free account: shorter intervals, CPT rules, inactive tab. V+: role rules, URL, log + CSV.
Is WP Rocket enough on its own?
Often yes if you already use it for cache. If you manage multiple WooCommerce sites and need reproducible presets and client stats, HCM complements or replaces Rocket's Heartbeat tab — not both in conflict.
Will this break WooCommerce checkout or cart?
No — checkout uses wc-ajax, not the Heartbeat API. Optimizing admin Heartbeat won't touch cart or checkout behavior. If customers report cart issues after Heartbeat tuning, look at cache plugins or session handling instead.
WordPress multisite?
Yes. Network settings under Network Settings → Heartbeat Control; each subsite can inherit or override.
No developer — can I do it alone?
Yes. Apply a preset, test autosave, done. The interface explains each option.
Which US hosts benefit most from Heartbeat optimization?
GoDaddy Managed and entry-level SiteGround see the biggest improvement because their small PHP worker pools saturate fastest. WP Engine and Kinsta benefit more from per-zone tuning for larger teams than from raw pulse reduction.
What about agencies?
Document a runbook per client (checklist + JSON export). Bill admin-ajax audit as performance maintenance — it's real work. V+ Pro (5 sites) or V+ Agency (unlimited) for premium on all Volade extensions.
Conclusion — Heartbeat isn't the enemy, defaults are
WordPress added Heartbeat to protect your work — not to saturate your server. When every zone runs at 15 s with four tabs and twenty plugins, admin-ajax.php becomes the easy villain in host emails.
It doesn't have to stay that way. Four zones, five presets, one autosave test — keep editor comfort while CPU breathes.
Our final recommendation: this week, diagnose the admin-ajax.php action, apply the WooCommerce (or Agency) preset, measure requests avoided, train the team to close ghost tabs. Go slow. Test the editor. Document in JSON for the next client site.
If you choose Volade: welcome. We built this because WordPress deserved honest, measurable Heartbeat tuning without breaking autosave.
Happy optimizing. Your wp-admin will thank you.
Article updated June 30, 2026. Sources: WordPress Heartbeat API documentation, Volade field tests, Jorijn Schrijvershof and Delicious Brains guides.
Optimize Heartbeat with Heartbeat Control Manager
Reduce Heartbeat load without breaking autosave or post locking.
Go further
FAQ, glossary, comparison, scripts and diagnostic — in addition to the article, not instead of it.
15 s
Default WP interval
~240 pulses/h/tab
24
Checklist items
Included as public resource
85%
Possible réduction
Typical WooCommerce preset
5
One-click presets
Heartbeat Control Manager
Complete WordPress Heartbeat optimization guide 2026
The long, printable version of this article — 5 detailed presets, admin-ajax diagnosis, host matrices and rollback plan.
- ✓admin-ajax.php diagnosis action by action
- ✓5 annotated presets (Blog, WooCommerce, Agency, Perf, Builder)
- ✓Pre-production autosave test matrix
- ✓Technical FAQ for the 10 most common cases
Sign up and unlock the complete pack
Migration timeline
- Phase 0
admin-ajax diagnosis
Filter DevTools, identify action=heartbeat vs WooCommerce vs third-party plugins.
- Phase 1
Pick preset
Blog, WooCommerce, Agency, Max perf or Builder by site profile.
- Phase 2
Install HCM
Preset applied, WP Rocket conflicts checked, effective config preview.
- Phase 3
Autosave tests
Draft, co-editing lock, product list, front checkout.
- Phase 4
Production
Agency JSON export, remove duplicate snippets, 48 h watch.
Approach comparison
| Criteria | WordPress default | Code snippet | WP Rocket | Heartbeat Control Manager |
|---|---|---|---|---|
| Disable front | No | Yes (if coded well) | Yes | Yes — 3 modes |
| Separate zones | No | Rarely | Partial | Yes — 4 zones |
| WooCommerce presets | No | No | No | Yes — one click |
| Requests avoided stats | No | No | No | Yes |
| JSON export multi-site | No | No | No | Yes — no account |
| Autosave guardrail | No | No | No | Yes — warning >120 s |
| Price | $0 | $0 | ~$59/yr | Free |
TikTok Shop × WooCommerce glossary
- Heartbeat API
- WordPress mechanism sending regular AJAX pulses to maintain admin session, autosave, and edit locking.
- admin-ajax.php
- WordPress AJAX endpoint — Heartbeat is only one of many possible actions.
- Pulse
- A single Heartbeat request to the server, repeated at the configured interval.
- Zone
- Heartbeat context: public front, dashboard, content lists, or editor — each configurable separately.
- Autosave
- Automatic draft save while editing — requires a sufficiently short Heartbeat interval.
- Action Scheduler
- WooCommerce task system using admin-ajax.php — distinct from Heartbeat, often confused.
Extended FAQ
Email script excerpts
Client notice — admin optimization
Objet : Improving your WordPress back-office speed
Hello, We're optimizing your administration interface requests on [DATE] between [START] and [END]. Your public store is unaffected. During the window, avoid long editing sessions. Expected result: smoother back office with autosave preserved. Best regards, [TEAM]
Internal team brief
Objet : [INTERNAL] Heartbeat optimization — D-Day roles
Team, Heartbeat optimization for client [NAME] on [DATE]. • Support: watch for lost draft tickets • Tech: [NAME] — preset [Blog/WC/Agency] • Rollback if: autosave fails after 5 min test JSON export in client folder.
Technical snippets
WP-CLI — apply WooCommerce preset
wp hcm status
wp hcm preset woocommerce
wp hcm export > heartbeat-config.jsonFilter debug.log — Heartbeat requests
// wp-config.php — temporary debug
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
// Search debug.log for: heartbeat, admin-ajaxQuick self-diagnostic
wp-admin is slow but the public site is fast. What to check first?
After optimization, a writer loses their draft.
Official & useful links
Video coming soon
Heartbeat optimization walkthrough (coming soon)
Step-by-step video: admin-ajax diagnosis, WooCommerce preset and autosave test.
~10 min
Sign up to get notified on release — Volade members get early access.
Your feedback matters
Comment on “WordPress Heartbeat: Cut admin-ajax.php Load Without Breaking Autosave (2026 Guide)” or rate this article to help the community.
people shared this article
