Here’s a reality check most WordPress site owners don’t want to hear: that collection of 30+ plugins powering your site is almost certainly the biggest reason it’s slow. Every plugin you install adds PHP execution time, database queries, CSS files, JavaScript files, and HTTP requests — whether the visitor needs that functionality on the current page or not.
The irony is that many of the most commonly installed plugins do things that WordPress can already handle with a few lines of code. You don’t need a plugin to disable comments, add Google Analytics, set a custom excerpt length, or redirect login pages. You need a functions.php file and the confidence to use it.
In this guide, we’ll replace 10 plugins that collectively add dozens of HTTP requests, hundreds of database queries, and megabytes of unnecessary code — with clean, lightweight code snippets that achieve the same result in a fraction of the performance cost.
The Real Cost of Plugin Bloat
Before we start removing plugins, it’s worth understanding exactly what each one costs your site. A plugin isn’t just a file sitting on your server — it’s active code that runs on every single page load.
Each plugin typically loads its own CSS and JavaScript files globally (on every page, not just where they’re needed). It registers its own database tables or options. It hooks into WordPress actions and filters, adding execution time to the core loop. And many plugins run background processes, scheduled tasks, and admin-side scripts that slow down your dashboard too.
A site with 35 plugins might be making 80+ HTTP requests per page and running 200+ database queries before a single word of content appears. Remove 10 unnecessary plugins, and you could cut your page load time by 30-40% without changing anything else about your hosting, caching, or content.
Where to Put These Code Snippets
Every snippet in this guide should go in one of two places: your child theme’s functions.php file, or a site-specific plugin. If you don’t have a child theme set up, a site-specific plugin is even simpler — create a file called my-site-functions.php in your /wp-content/plugins/ directory with a standard plugin header, and activate it.
<?php
/**
* Plugin Name: My Site Functions
* Description: Custom code snippets replacing unnecessary plugins.
* Version: 1.0
* Author: Your Name
*/
// Your snippets go below this lineThis approach keeps your custom code independent of your theme, surviving theme switches and updates. It’s how professional developers manage small customizations.
1. Replace Your “Disable Comments” Plugin
Plugins like Disable Comments add an entire admin settings page, multiple database queries, and conditional logic — just to turn off a core feature. Here’s the code replacement:
// Disable comments site-wide
add_action( 'admin_init', function() {
// Redirect any user trying to access the comments page
global $pagenow;
if ( $pagenow === 'edit-comments.php' ) {
wp_safe_redirect( admin_url() );
exit;
}
// Remove comments metabox from all post types
foreach ( get_post_types() as $post_type ) {
remove_meta_box( 'commentsdiv', $post_type, 'normal' );
remove_meta_box( 'commentstatusdiv', $post_type, 'normal' );
}
});
// Close comments on the front end
add_filter( 'comments_open', '__return_false', 20, 2 );
add_filter( 'pings_open', '__return_false', 20, 2 );
// Hide existing comments
add_filter( 'comments_array', '__return_empty_array', 10, 2 );
// Remove comments from the admin menu
add_action( 'admin_menu', function() {
remove_menu_page( 'edit-comments.php' );
});
// Remove comments from the admin bar
add_action( 'wp_before_admin_bar_render', function() {
global $wp_admin_bar;
$wp_admin_bar->remove_menu( 'comments' );
});This does everything the plugin does — disabling front-end comments, hiding the admin menu item, removing the dashboard metabox, and redirecting the comments page — with zero additional database queries or loaded assets.
2. Replace Your “Custom Excerpt Length” Plugin
Some sites install an entire plugin just to change the excerpt length from 55 words to something else. This is a single filter:
// Set custom excerpt length
add_filter( 'excerpt_length', function( $length ) {
return 25; // Change to your preferred word count
}, 999 );
// Customize the excerpt "read more" text
add_filter( 'excerpt_more', function( $more ) {
return '… <a href="' . get_permalink() . '" class="read-more">Continue reading</a>';
});Two filters, four lines of actual logic. The priority of 999 ensures this overrides any theme defaults.
3. Replace Your “Insert Headers and Footers” Plugin
Plugins that let you paste code into the header or footer through a GUI are convenient — but they store your scripts in the database (adding a query per page load) and often load their own admin assets. If you know what script you’re adding, hook it directly:
// Add tracking scripts to the header
add_action( 'wp_head', function() {
if ( is_admin() ) return;
?>
<!-- Your header scripts here -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXX');
</script>
<?php
}, 1 );
// Add scripts before closing body tag
add_action( 'wp_footer', function() {
?>
<!-- Your footer scripts here -->
<?php
});Same result, zero database queries, no admin UI overhead. The scripts are version-controlled in your code rather than buried in the database.
4. Replace Your “Disable WordPress Emoji” Plugin
WordPress loads emoji detection and rendering scripts on every page by default — even though every modern browser handles emojis natively. Many sites install a plugin to remove this. Here’s the code:
// Remove WordPress emoji scripts and styles
add_action( 'init', function() {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
});This removes two HTTP requests (one JavaScript file, one CSS file) from every page on your site. It’s a small win individually, but it compounds when you’re eliminating multiple unnecessary resources.
5. Replace Your “Maintenance Mode” Plugin
Maintenance mode plugins often load entire template engines, custom CSS, and admin settings panels. For a basic maintenance page, this is all you need:
// Enable maintenance mode for non-admins
function swiftly_maintenance_mode() {
if ( ! current_user_can( 'manage_options' ) && ! is_login() ) {
wp_die(
'<h1>We\'ll be right back</h1>
<p>We\'re performing scheduled maintenance. Please check back in a few minutes.</p>',
'Maintenance Mode',
array( 'response' => 503 )
);
}
}
// Uncomment the line below to activate maintenance mode
// add_action( 'template_redirect', 'swiftly_maintenance_mode' );Comment or uncomment the add_action line to toggle maintenance mode. Admins can still access the site normally. The 503 response code tells search engines the downtime is temporary, preventing any SEO impact.
6. Replace Your “Limit Login Attempts” Plugin
Basic brute-force protection doesn’t require a full plugin with database tables, email notifications, and admin dashboards. This snippet limits login attempts using WordPress transients:
// Limit login attempts using transients
function swiftly_limit_login_attempts( $user, $password ) {
$ip = $_SERVER['REMOTE_ADDR'];
$transient_key = 'login_attempts_' . md5( $ip );
$attempts = get_transient( $transient_key );
if ( $attempts !== false && $attempts >= 5 ) {
return new WP_Error(
'too_many_attempts',
'Too many failed login attempts. Please try again in 15 minutes.'
);
}
return $user;
}
add_filter( 'authenticate', 'swiftly_limit_login_attempts', 30, 2 );
// Track failed logins
function swiftly_track_failed_login( $username ) {
$ip = $_SERVER['REMOTE_ADDR'];
$transient_key = 'login_attempts_' . md5( $ip );
$attempts = get_transient( $transient_key );
if ( $attempts === false ) {
set_transient( $transient_key, 1, 15 * MINUTE_IN_SECONDS );
} else {
set_transient( $transient_key, $attempts + 1, 15 * MINUTE_IN_SECONDS );
}
}
add_action( 'wp_login_failed', 'swiftly_track_failed_login' );This blocks an IP after 5 failed attempts for 15 minutes. It uses WordPress transients (which auto-expire), so there are no permanent database tables to maintain or clean up.
7. Replace Your “Hide Admin Bar” Plugin
Showing the WordPress admin bar to subscribers or customers creates a poor user experience. Some sites install a plugin for this one-line fix:
// Hide admin bar for non-administrators
if ( ! current_user_can( 'manage_options' ) ) {
add_filter( 'show_admin_bar', '__return_false' );
}One conditional check, one filter. No settings page needed.
8. Replace Your “Custom Login URL” Plugin
Changing the WordPress login URL from /wp-login.php to something custom is a basic security-through-obscurity measure. While not a replacement for proper security, it does reduce bot traffic significantly:
// Redirect default login to 404 and use custom URL
function swiftly_custom_login_url() {
$custom_slug = 'my-secret-login'; // Change this to your preferred slug
// If someone accesses the custom login URL, show the login form
if ( strpos( $_SERVER['REQUEST_URI'], '/' . $custom_slug ) !== false ) {
require_once ABSPATH . 'wp-login.php';
exit;
}
}
add_action( 'init', 'swiftly_custom_login_url' );
// Block direct access to wp-login.php (except for POST requests during actual login)
function swiftly_block_default_login() {
if (
strpos( $_SERVER['REQUEST_URI'], 'wp-login.php' ) !== false
&& $_SERVER['REQUEST_METHOD'] !== 'POST'
&& ! isset( $_GET['action'] )
) {
wp_safe_redirect( home_url( '/404' ), 302 );
exit;
}
}
add_action( 'init', 'swiftly_block_default_login' );9. Replace Your “Disable XML-RPC” Plugin
XML-RPC is a legacy remote access protocol that most WordPress sites don’t use but attackers frequently exploit for brute-force and DDoS attacks. Disabling it is a single filter:
// Disable XML-RPC entirely
add_filter( 'xmlrpc_enabled', '__return_false' );
// Remove the XML-RPC discovery link from the head
remove_action( 'wp_head', 'rsd_link' );Two lines. No plugin settings page, no database entries, no admin scripts loaded. If you use Jetpack or the WordPress mobile app (both of which require XML-RPC), don’t add this snippet. For everyone else, it’s a free security improvement.
10. Replace Your “Clean Up wp_head” Plugin
WordPress adds several meta tags and links to the <head> section that most sites don’t need: version numbers, feed links, shortlink tags, and Windows Live Writer support. Cleaning these up is a series of simple remove_action calls:
// Clean up wp_head output
remove_action( 'wp_head', 'wp_generator' ); // WP version
remove_action( 'wp_head', 'wlwmanifest_link' ); // Windows Live Writer
remove_action( 'wp_head', 'rsd_link' ); // Really Simple Discovery
remove_action( 'wp_head', 'wp_shortlink_wp_head' ); // Shortlink
remove_action( 'wp_head', 'rest_output_link_wp_head' ); // REST API link
remove_action( 'wp_head', 'feed_links', 2 ); // Feed links
remove_action( 'wp_head', 'feed_links_extra', 3 ); // Extra feed links
remove_action( 'wp_head', 'wp_oembed_add_discovery_links' ); // oEmbed discoveryEach of these removes an unnecessary tag from your HTML output. Collectively, they clean up your source code, reduce page weight slightly, and eliminate information that attackers can use to fingerprint your site.
How to Measure the Impact
After replacing plugins with code, measure the difference. Run your site through Google PageSpeed Insights, GTmetrix, or WebPageTest before and after. Pay attention to these specific metrics: total HTTP requests (should decrease noticeably), Time to First Byte (should improve as PHP processing time drops), total page weight (should decrease as unused CSS/JS is eliminated), and the number of database queries (check with Query Monitor plugin).
On a typical site, replacing these 10 plugins can eliminate 15-25 HTTP requests per page, reduce database queries by 30-50, and cut 200-500ms off your total page load time. Those numbers compound with caching, and they apply to every single page on your site.
When You Should Keep the Plugin
Not every plugin should be replaced with code. Plugins make sense when the functionality is complex and actively maintained against evolving threats (like a full security suite), when you need a GUI because non-technical team members manage it, when the plugin provides ongoing updates for compatibility with other tools, or when the code required would be extensive and hard to maintain yourself.
The rule of thumb: if a plugin does one simple thing that WordPress can do natively with a hook, replace it with code. If a plugin does many complex things that require ongoing development, keep it — but make sure it’s a well-built, lightweight plugin from a reputable developer.
Final Thoughts
Plugin bloat is the silent performance killer on most WordPress sites. It accumulates gradually — one plugin for this, another for that — until your site is loading 40 unnecessary files per page and running hundreds of database queries before any content appears.
The 10 replacements in this guide are a starting point. Audit your own plugin list with the same critical eye: does this plugin do something I could achieve with a few lines of code? If the answer is yes, make the switch. Your page load times, your server resources, and your visitors will all benefit.
At SwiftlyWP, this philosophy is built into everything we create. Every plugin we ship follows strict performance budgets — no unnecessary assets, no bloated admin interfaces, no database queries that don’t need to exist. Because the best plugin is one that does its job and gets out of the way.
