{"id":4380,"date":"2026-09-12T16:51:43","date_gmt":"2026-09-12T11:21:43","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/how-to-disable-wordpress-bloat-heartbeat-revisions-xmlrpc\/"},"modified":"2026-09-12T16:52:33","modified_gmt":"2026-09-12T11:22:33","slug":"how-to-disable-wordpress-bloat-heartbeat-revisions-xmlrpc","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/how-to-disable-wordpress-bloat-heartbeat-revisions-xmlrpc\/","title":{"rendered":"How to Disable Bloated WordPress Core Features: Heartbeat, Revisions & XML-RPC"},"content":{"rendered":"

WordPress is designed to accommodate every conceivable use case out of the box\u2014from 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<\/a>.<\/p>\n

If you have ever noticed unexplained CPU spikes in top<\/code> or htop<\/code> when editors are writing articles, observed your MariaDB database ballooning past gigabytes of revision history, or faced automated botnets flooding xmlrpc.php<\/code> 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.<\/p>\n

1. Restraining the WordPress Heartbeat API<\/h2>\n

The Heartbeat API<\/strong> (wp-admin\/admin-ajax.php<\/code>) 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.<\/p>\n

By default, Heartbeat sends an AJAX POST request every 15 seconds<\/strong> while an editor is in the Gutenberg post editor and every 60 seconds<\/strong> 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.<\/p>\n

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<\/code>):<\/p>\n

<?php\n\/\/ Slow down Heartbeat API to 60-second intervals in admin\nadd_filter('heartbeat_settings', function ($settings) {\n    $settings['interval'] = 60; \/\/ Set interval to 60 seconds\n    return $settings;\n});\n\n\/\/ Completely disable Heartbeat on the public frontend\nadd_action('init', function () {\n    if (!is_admin()) {\n        wp_deregister_script('heartbeat');\n    }\n}, 1);<\/code><\/pre>\n
2. Capping Post Revisions & Autosave Intervals<\/h2>\n
Every time an author clicks “Save Draft” or triggers an autosave, WordPress inserts a complete copy of the post into the wp_posts<\/code> 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<\/code> ends up storing 80,000 dead rows, drastically inflating database index sizes and slowing down SQL queries.<\/p>\n
Constrain revisions and expand autosave intervals inside wp-config.php<\/code>:<\/p>\n
\/* Cap post revisions to the last 3 edits *\/\ndefine('WP_POST_REVISIONS', 3);\n\n\/* Increase autosave frequency to 300 seconds (5 minutes) *\/\ndefine('AUTOSAVE_INTERVAL', 300);\n\n\/* Automatically empty trash after 7 days *\/\ndefine('EMPTY_TRASH_DAYS', 7);<\/code><\/pre>\n
To purge historical orphaned revisions from an existing bloated database, run this single SQL command via WP-CLI:<\/p>\n
wp db query \"DELETE FROM wp_posts WHERE post_type = 'revision';\" --allow-root\nwp db query \"OPTIMIZE TABLE wp_posts;\" --allow-root<\/code><\/pre>\n
3. Completely Disabling XML-RPC (xmlrpc.php)<\/h2>\n
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.<\/p>\n
However, xmlrpc.php<\/code> remains the single most targeted attack vector on WordPress servers. Automated botnets exploit the system.multicall<\/code> method to guess hundreds of password combinations in a single HTTP request, completely bypassing basic login rate limiters and exhausting server CPU.<\/p>\n
Block XML-RPC at the Nginx Web Server Level<\/h3>\n
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:<\/p>\n
# Block all access to xmlrpc.php\nlocation = \/xmlrpc.php {\n    deny all;\n    access_log off;\n    log_not_found off;\n    return 403;\n}<\/code><\/pre>\n
Disable XML-RPC via WordPress PHP Filter<\/h3>\n
As a secondary defense, disable XML-RPC handling inside your mu-plugin:<\/p>\n
\/\/ Disable XML-RPC methods in WordPress core\nadd_filter('xmlrpc_enabled', '__return_false');\nremove_action('wp_head', 'rsd_link');\nremove_action('wp_head', 'wlwmanifest_link');<\/code><\/pre>\n
4. Disabling Self-Pingbacks and Trackbacks<\/h2>\n
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:<\/p>\n
add_action('pre_ping', function (&$links) {\n    $home = get_option('home');\n    foreach ($links as $l => $link) {\n        if (str_contains($link, $home)) {\n            unset($links[$l]);\n        }\n    }\n});<\/code><\/pre>\n
\n
Measurable Server Performance Gains<\/h4>\n
Implementing these four core optimizations slashes baseline PHP-FPM requests by over 40%, shrinks database backups by up to 60%, and completely shields your server from XML-RPC distributed brute-force floods. Your VPS CPU stays cool, leaving full compute power dedicated to genuine visitor traffic.<\/p>\n<\/div>\n
WordPress Database Optimization: Purging Transients & Autoloaded Options<\/h2>\n
Beyond disabling the Heartbeat API, revisions, and XML-RPC, another silent performance killer is autoloaded data bloat<\/strong> in the wp_options<\/code> table:<\/p>\n