How to Disable Bloated WordPress Core Features: Heartbeat, Revisions & XML-RPC

WordPress is designed to accommodate every conceivable use case out of the box—from beginner blogs to massive media publications. To support this broad audience, WordPress core enables several background background services by default: continuous autosaving, post revision tracking, real-time AJAX polling, and legacy XML-RPC endpoints. While well-intentioned, these background mechanisms introduce severe CPU churn, database bloating, and critical security vulnerabilities when deployed on a production Linux VPS.

If you have ever noticed unexplained CPU spikes in top or htop when editors are writing articles, observed your MariaDB database ballooning past gigabytes of revision history, or faced automated botnets flooding xmlrpc.php with brute-force attacks, your server is suffering from WordPress core bloat. This tutorial demonstrates how to cleanly disable or constrain these bloated features using native PHP hooks and Nginx server directives.

1. Restraining the WordPress Heartbeat API

The Heartbeat API (wp-admin/admin-ajax.php) uses periodic AJAX requests to communicate between the visitor’s browser and the server. It handles autosaving posts, session expiration notifications, and post locking when multiple authors edit the same document.

By default, Heartbeat sends an AJAX POST request every 15 seconds while an editor is in the Gutenberg post editor and every 60 seconds in the administrative dashboard. If you have an editorial team with 5 authors keeping dashboard tabs open, your server processes hundreds of dynamic PHP-FPM requests every minute, consuming CPU cycles for idle screens.

To safely slow down Heartbeat to 60-second intervals or disable it completely on the frontend, add this lightweight snippet to a custom mu-plugin (/wp-content/mu-plugins/disable-bloat.php):

<?php
// Slow down Heartbeat API to 60-second intervals in admin
add_filter('heartbeat_settings', function ($settings) {
    $settings['interval'] = 60; // Set interval to 60 seconds
    return $settings;
});

// Completely disable Heartbeat on the public frontend
add_action('init', function () {
    if (!is_admin()) {
        wp_deregister_script('heartbeat');
    }
}, 1);

2. Capping Post Revisions & Autosave Intervals

Every time an author clicks “Save Draft” or triggers an autosave, WordPress inserts a complete copy of the post into the wp_posts table. Over a year of content creation, a single 1,000-word blog post can easily spawn 80 historical revisions. On a site with 1,000 articles, wp_posts ends up storing 80,000 dead rows, drastically inflating database index sizes and slowing down SQL queries.

Constrain revisions and expand autosave intervals inside wp-config.php:

/* Cap post revisions to the last 3 edits */
define('WP_POST_REVISIONS', 3);

/* Increase autosave frequency to 300 seconds (5 minutes) */
define('AUTOSAVE_INTERVAL', 300);

/* Automatically empty trash after 7 days */
define('EMPTY_TRASH_DAYS', 7);

To purge historical orphaned revisions from an existing bloated database, run this single SQL command via WP-CLI:

wp db query "DELETE FROM wp_posts WHERE post_type = 'revision';" --allow-root
wp db query "OPTIMIZE TABLE wp_posts;" --allow-root

3. Completely Disabling XML-RPC (xmlrpc.php)

The XML-RPC specification was introduced in WordPress 3.5 to allow remote publishing via legacy mobile apps. Today, the modern WordPress REST API handles all authenticated external interactions, rendering XML-RPC obsolete for 99% of web applications.

However, xmlrpc.php remains the single most targeted attack vector on WordPress servers. Automated botnets exploit the system.multicall method to guess hundreds of password combinations in a single HTTP request, completely bypassing basic login rate limiters and exhausting server CPU.

Block XML-RPC at the Nginx Web Server Level

The most efficient way to eliminate XML-RPC abuse is to block it before it ever invokes PHP-FPM. Add this rule to your Nginx virtual host configuration:

# Block all access to xmlrpc.php
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

Disable XML-RPC via WordPress PHP Filter

As a secondary defense, disable XML-RPC handling inside your mu-plugin:

// Disable XML-RPC methods in WordPress core
add_filter('xmlrpc_enabled', '__return_false');
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');

4. Disabling Self-Pingbacks and Trackbacks

Whenever you link to an internal post on your own website, WordPress sends an unnecessary HTTP pingback request to itself, generating wasteful server round-trips. Disable self-pingbacks with this snippet:

add_action('pre_ping', function (&$links) {
    $home = get_option('home');
    foreach ($links as $l => $link) {
        if (str_contains($link, $home)) {
            unset($links[$l]);
        }
    }
});

WordPress Database Optimization: Purging Transients & Autoloaded Options

Beyond disabling the Heartbeat API, revisions, and XML-RPC, another silent performance killer is autoloaded data bloat in the wp_options table:

• Understanding Autoloaded Options: Every single time WordPress boots, it executes a single database query: SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'. If this query returns more than 1MB of serialized data, page load times slow down by 200–500 milliseconds across the entire site.
• Identifying Massive Autoloaded Keys: Audit your autoloaded option size directly using WP-CLI:

  wp db query "SELECT option_name, length(option_value) AS option_size FROM wp_options WHERE autoload='yes' ORDER BY option_size DESC LIMIT 10;" --allow-root

  Look for abandoned plugin settings, stale analytics logs, and cache dumps left behind by deleted plugins.

• Switching Autoload Flags on Inactive Plugins: For large options that are only required in the administrative dashboard, update their autoload setting to no:

  wp db query "UPDATE wp_options SET autoload = 'no' WHERE option_name = 'huge_abandoned_plugin_data';" --allow-root

• Benchmarking Query Time Improvements: After optimizing autoloaded options and disabling core bloat, test page execution time with curl -o /dev/null -s -w 'Total Time: %{time_total}s
' https://yourdomain.com/. Time-to-first-byte (TTFB) routinely drops from 600ms down to sub-80ms.