Disable Heartbeat only in the backend: no impact on the frontend, no impact on the editing experience

exist WordPress of performance optimization in practice.Heartbeat API It is an inescapable but often "misunderstood" module.
Many sites, when optimizing backend performance, simply disable Heartbeat site-wide, and the results bring:

• Editor autosave disabled
• Multi-Player Collaboration on Locked Anomalies
• WooCommerce Order Status Out of Sync
• The backend experience is worse

The right thing to do is not to "turn off Heartbeat", but to disable it only in non-editing scenarios in the background.

This article will make it clear in its entirety:

• What the hell is Heartbeat doing?
• Why "background-only" is the optimal solution
• Multiple safe and controllable implementations
• Differentiation strategies for different backend pages
• Common pitfalls and validation methods

I. What is Heartbeat? Why does it slow down the background

1. The nature of Heartbeat

The Heartbeat API is a suite of Timed AJAX Polling Mechanism, default:

• each 15-60 seconds triggered once
• pass (a bill or inspection etc) admin-ajax.php or REST API
• Continuous exchange of status data with the server

Primary uses include:

• Article autosave
• Edit lock (prevents multiple overwrites)
• Background notifications, status refresh
• WooCommerce Order/Inventory Updates in Real Time

2. Where the problem lies

In a real production environment, the problem with Heartbeat is not so much the "functionality" as it is the fact thatFrequency + Range::

• Every open page in the backend is polling
• Stacking of requests when multiple administrators are online at the same time
• Low Profile Servers / Overseas Servers RTT High
• admin-ajax.php Poor performance per se

Eventually it manifests itself:

• High CPU usage in the background
• MySQL Query Count Exception
• PHP-FPM process stacking
• Occasional lagging and spinning in the background

Why can't you "globally disable Heartbeat"?

Many tutorials will suggest it:

add_action( 'init', function() {
    wp_deregister_script( 'heartbeat' );
}).

This is the wrong demonstration.

The reason is simple:

functionality	Whether to rely on Heartbeat
Gutenberg Autosave	✅
Editing Lock	✅
WooCommerce Backend Order Refresh	✅
Classic Editor Draft Protection	✅

One-size-fits-all is usually the consequence:

• Loss of editorial content
• Multiple editing conflicts
• Backstage features "look normal, but are actually mined"

So the goal must be:

Disable Heartbeat only on [backend non-edit page].
Heartbeat required to preserve editor, key functions

III. Overview of best strategies (conclusions first)

A proven, controlled strategy should satisfy:

1. ✅ Does not affect the front-end (Front-end)
2. ✅ Does not affect article/page editing
3. ✅ Only works with wp-admin
4. ✅ Scalable and maintainable

Recommended Priority:

1. on the basis of admin_enqueue_scripts Precision disabling (preferred)
2. Differentiated processing based on page judgment conditions
3. Control Heartbeat frequency (not completely disabled)
4. Plug-in program (only as a supplement)

Option 1 (recommended): Disable Heartbeat only on non-editing pages in the background.

Core ideas

• Heartbeat is a script:heartbeat
• Background loading by hookConditional removal
• Edit page (post.php / post-new.php) does not move
• Other backend pages directly disable

Full usable code

/**
 * Disable Heartbeat only on admin non-editor pages
 */
add_action( 'admin_enqueue_scripts', function() {

    // 当前后台页面
    $screen = get_current_screen();

    if ( ! $screen ) {
        return;
    }

    // 编辑文章 / 页面时，保留 Heartbeat
    if ( $screen->base === 'post' ) {
        return;
    }

    // 其余后台页面禁用 Heartbeat
    wp_deregister_script( 'heartbeat' );
});

Why this program is safe

• admin_enqueue_scripts Only works in the background
• post Pages are explicitly excluded (editorial experience is not affected)
• No touching of frontend scripts
• Does not affect the REST API

V. Program 2: Finer back-end page control (advanced)

If you areLarge Site / E-commerce Back Office / Multi-Role System, could be more refined.

Example: Keep Heartbeat on these pages only

• Articles / Page Editors
• WooCommerce Order Page
• Customize Backend Dashboards

add_action( 'admin_enqueue_scripts', function() {

    $screen = get_current_screen(); if ( !
    if ( ! $screen ) return;

    $allowed = [
        'post',
        'woocommerce_page_wc-orders'.
    ];

    if ( in_array( $screen->base, $allowed, true ) ) {
        return;
    }

    wp_deregister_script( 'heartbeat' ); }
}).

Fit:

• WooCommerce Standalone
• Multi-person backend operation
• High Frequency Order / Content Update System

VI. Option 3: No ban, only "downscaling" (more conservative)

If you're concerned about the unknown effects of disabling it altogether, you canReducing Heartbeat FrequencyThe

Example: Backend non-editing page → 120 seconds at a time

add_filter( 'heartbeat_settings', function( $settings ) {

    if ( is_admin() ) {
        $settings['interval'] = 120;
    }

    return $settings.
}).

Comparative notes

be tactful	Server load	functional integrity
Completely disable	⭐⭐⭐⭐	⭐⭐⭐⭐⭐⭐⭐
Background Disabled Only	⭐⭐⭐⭐	⭐⭐⭐⭐
downmix	⭐⭐⭐⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐

---

VII. Plug-in program (not recommended as a long-term program)

Common Plugins:

• Heartbeat Control
• WP Rocket(incidental)

The problem is:

• Not fine enough particle size
• Uncontrollable behavior after escalation
• Difficult to distinguish between specific backend pages

Fit:

• Inconvenient to write code
• ad hoc test
• small site

It doesn't fit:

• highly concurrent
• e-commerce
• multi-editor system

VIII. Common pitfalls and checklist

1. Failure of editorial autosave

rationale: Misdisabled post web page
tackle: Acknowledgement $screen->base === 'post' excluded

2. WooCommerce Orders Not Refreshing

rationale: The order page relies on Heartbeat
tackle: Whitelisting

3. Wrongful death of the front desk

rationale: Uses the init / wp_enqueue_scripts
tackle: Only use admin_enqueue_scripts

4. Failure of a condition of judgment

rationale::get_current_screen() premature call
tackle: don't use it in init hooks

IX. How to verify whether it is really effective

Method 1: Browser Network panel

1. Open the backend non-editable page
2. filtration heartbeat / admin-ajax.php
3. No more cyclical requests ✅

Method 2: Server logs

• admin-ajax.php Significant decrease in the number of requests
• PHP-FPM Load Drop

X. Summarizing (giving direct conclusions)

The correct Heartbeat optimization principle is one sentence long:

Don't turn off the features you need, only the scenes you don't need.

Best Practices:

• ✅ Front desk not moving
• ✅ Edit page not moving
• ✅ Background non-editable pages disabled
• ✅ Code-level control to avoid plugin dependencies

I can help you with the next step if you want:

• check or refer to WooCommerce / Content Station / SaaS Backend Customized version for you
• Help you organize this one into SEO Technical Blog Structure (H1-H4 + Meta)
• Or just give you a Reusable version of mu-plugin

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