What is WordPress Heartbeat? Backend Slowdown and CPU Spikes Explained

Appears in the WordPress backendLagging, unusually high CPU usage, admin-ajax.php request spikeWhen, many webmasters are advised a phrase:

"TheTry turning off Heartbeat."The

but What the hell is Heartbeat??
Why does it slow down the background?
ittrulyIs CPU spiking the culprit, or is it just misplaced "scapegoats"?

I. What is Heartbeat? One sentence explains what it is doing

Heartbeat is a set of WordPress built-inBackground heartbeat mechanism, the essence is:

The backend page without refreshing the web pageTiming AJAX requests to the server, which is used to synchronize the state.

These requests are made primarily through the admin-ajax.php sent, the default frequency is:

Every 15-60 seconds
Open background page ≠ idle
As long as the page exists, Heartbeat is "jumping."

II. Heartbeat's core role (it is not redundant)

Many people's first reaction is:

"This thing sounds like a waste of resources."

But in reality, Heartbeat assumesMultiple backend key functionsThe

Auto Save

When you are writing articles and changing pages:

WordPress saves drafts on a regular basis
Prevents browser crashes, disconnections, and false closures

This is courtesy of Heartbeat.

Edit Lock (Post Lock)

When multiple people collaborate:

A Articles being edited
B Open the same article
The system says, "It's being edited by another user."

Also Heartbeat is in a synchronized state.

Login Status Detection

Heartbeat will periodically confirm:

Is the login still valid?
Whether you need to re-verify permissions

Otherwise you could be doing a bunch of things in the background only to realize that you're "offline" at the end of the day.

Plugins/themes with real-time backend functionality

including but not limited to:

Order Status Refresh
Security Plugin Risk Control
Editor real-time calibration

In particular, the use of WooCommerce sites, this type of dependency will be more frequent.

Why does it slow down the background and spike the CPU?

Here's the point:
Heartbeat itself is not heavy, it's "what it triggers" that counts.

The problem isn't "jumping", it's "doing a lot of things at once".

with every Heartbeat request:

go into admin-ajax.php
Loading WordPress Core
Execute the mounted action / hook
"Intercepted and processed" by plug-ins

If your site meets the following conditions
CPU spikes can occur very easily.

The 5 Real Reasons Why CPUs Are Soaring

Multiple tabs open at the same time in the background

this isThe most common but most overlooked condition::

One backend page = one Heartbeat
5 tabs = 5x requests
Plus multiple administrators online at the same time

Heartbeats stack directly.

Plugin "works" on Heartbeat

Many plugins will do this:

"Since Heartbeat triggers on a regular basis, I'll check something in the meantime."

For example:

Security Plug-ins: Scan Status
Statistical plug-ins: Journaling
Mall Plugin: Synchronize orders
editor (software): Preservation of structural data

The result:One heartbeat = multiple complex SQL queries

admin-ajax.php itself is already a performance bottleneck

In some server environments:

admin-ajax.php Caching not enabled
Limited number of PHP-FPM processes
Slow database response

Heartbeat just keeps knocking on the door with insufficient processing power behind it.

The backend editor itself is "heavy".

When using the block editor, page builder:

Every Heartbeat is accompanied by a data comparison.
Complex JSON structure
Automatic revision stacking

CPU usage has increased in a stepwise manner.

Server configuration is not friendly to the backend

Commonly found:

Low Profile VPS
web hosting
Sharing resources between back and front office

Heartbeat amplifies existing performance issues.

V. A key cognitive misunderstanding: Heartbeat ≠ CPU problem source

Very important point:

Heartbeat is a "trigger", not a "maker".

It does just that:

time-based request
provide a single point of entry

What really consumes the CPU is usually:

Plugin mounted functions
Database Queries
Log Write
safety check

So you will see a phenomenon:

Same with Heartbeat.
A The site is fine.
B Site Direct CPU 100%The

VI. How to tell: Is your question Heartbeat or not?

Quick judgment method (no configuration change)

You can observe these 3 signals:

Whether CPU spikes occur only after logging into the backend
Close the background page, does the CPU drop rapidly
Does admin-ajax.php appear heavily in the server logs

If all three hold true at the same time
Heartbeat is most likely involved.

But note: participation ≠ culprit

The right question isn't:

"Should I turn off Heartbeat?"

Instead:

"What really happens when Heartbeat is triggered?"

Why "Shutting Down Heartbeat Across the Board" is Dangerous

Many tutorials will suggest this directly:

"Disable Heartbeat all in the background."

This is done in the following scenariosHighly Unrecommended::

Multi-author sites
Mall Backstage
Write long essays often
Using the online editor

Possible consequences include:

Autosave Failure
Edit Conflict Unprompted
Abnormal login status
Rising risk of data loss

VIII. Summary of ideas for the correct understanding of such issues

You should remember these three points:

Heartbeat is infrastructure, not garbage code
CPU spikes are usually plugin/logic issues, amplified by Heartbeat
Optimization focuses on "control" and "positioning" rather than "shutting down".

Conclusion: Heartbeat is not the enemy, losing control is the problem!

If your site's backend slows down and CPU spikes:

Don't turn off Heartbeat first.
Understand first that it is inWhat's the trigger?
Then decide if you need toLimit frequency, limit pages, reduce mount logic

True professional optimization is never about "turning off features".
Rather, it's "let the features appear only where they should".

Contact Us
Can't read the tutorial? Contact us for a free answer! Free help for personal, small business sites!	Customer Service
① Tel: 020-2206-9892
② QQ咨询：1025174874
(iii) E-mail: info@361sale.com
④ Working hours: Monday to Friday, 9:30-18:30, holidays off