Most WordPress sites accumulate plugins over time. Some were installed for a specific project and never removed. Some are active but only used on one obscure page. Some were deactivated but never deleted. Each active plugin costs something in PHP execution time, memory, database queries, and potentially in JavaScript and CSS loaded for every visitor, whether or not that plugin is doing anything useful on that page.
Deactivated plugins don't execute during normal page requests, so they don't directly affect front-end performance. However, their files remain on disk and can be scanned by automated vulnerability discovery tools. An abandoned, deactivated plugin with a known CVE (Common Vulnerabilities and Exposures entry) is a security risk even when inactive, some exploits target plugin files directly without requiring the plugin to be activated.
The rule is simple: if you're not using it, delete it. Not deactivate, delete. Deactivating a plugin without deleting it provides no security benefit. The files are still there, still readable by PHP if a file inclusion vulnerability exists elsewhere on the server, and still a target for automated scanning.
Every active plugin's main file is loaded on every request, regardless of whether the plugin does anything on the requested page. The WordPress plugin loading mechanism doesn't differentiate between pages, if a plugin is active, it runs its initialization code on every page load. Even a plugin that only outputs a widget in a footer does something during PHP initialization: it registers hooks, loads text domains, checks user capabilities, possibly queries the database.
The cumulative cost of 35 active plugins versus 10 is measurable in every uncached PHP request. The difference might be 80ms vs 200ms of PHP execution time, which doesn't matter if every page is cached, but matters significantly for logged-in users, WooCommerce sessions, and any page that bypasses the cache.
JavaScript-heavy plugins multiply the problem on the front end. A contact form plugin loading 150KB of jQuery UI on every page for a form that only appears on the Contact page is costing every visitor on every page. A slider plugin loading 200KB of JavaScript and CSS on the homepage only to display three static images is a poor trade. These costs show up directly in Core Web Vitals, particularly INP and LCP.
Install Query Monitor and visit your homepage, a blog post, and a key landing page. In the Query Monitor panel at the bottom of the screen, check:
Scripts panel, lists every JavaScript file loaded on the page with its source plugin or theme. If a plugin is loading JavaScript on a page where it provides no visible functionality, that's a candidate for conditional loading or removal.
Styles panel, same for CSS. Plugins that load stylesheet files on every page regardless of usage contribute to render-blocking overhead and page weight.
Database Queries panel, shows every query, its execution time, and which plugin generated it. If a plugin you barely use is generating 15 database queries per page load, that's significant overhead for negligible benefit.
PHP Errors panel, surfacing any deprecated notices or warnings from outdated plugins that aren't yet causing fatal errors but indicate poor maintenance.
For each active plugin, ask: what would break if I deactivated this right now? If you're not certain, test it. Create a list of your active plugins, then deactivate them one at a time and check the affected pages. Start with plugins you haven't actively configured or thought about in the last 6 months, those are the highest-probability candidates for being unused.
Do this on a staging site if possible, so you're not taking risks on the live site. If your host provides staging environments, the process is: clone to staging, deactivate suspicious plugins, check for breakage, document results, then apply confirmed removals to the live site. The whole audit typically takes 30–60 minutes and the performance improvements compound with caching.
Multiple SEO plugins. Yoast SEO and Rank Math running simultaneously is the most common example. Both are doing identical jobs. Pick the one you prefer and remove the other completely (including any residual database entries it left behind).
Duplicate caching plugins. W3 Total Cache installed on a site already running LiteSpeed Cache. Multiple caching plugins conflict and produce unpredictable results. One caching layer is what you need.
Social sharing plugins. Many add 50–150KB of JavaScript to every page. Simple share links, https://twitter.com/intent/tweet?url=URL, require no JavaScript at all and provide the same core functionality. If you're loading a full social sharing plugin for buttons that could be 5 lines of HTML, remove the plugin.
Slider plugins. Slider Revolution and similar plugins are often the heaviest single asset on a WordPress site, 300–600KB of JavaScript and CSS, sometimes more. If you're displaying one or two images that don't actually need carousel functionality, a static hero section with CSS handles it without the overhead.
Redundant redirect managers. Sites that have gone through multiple migrations often have two or three redirect plugins installed. These are cumulative: every redirect plugin adds its own lookup on every request.
Some plugins are necessary but shouldn't load on every page. A contact form plugin only needs its JavaScript on pages that contain the form. WooCommerce scripts should be limited to shop, product, cart, and checkout pages. You can conditionally dequeue scripts using WordPress hooks in your theme's functions.php:
add_action( 'wp_enqueue_scripts', function() {
if ( ! is_page( 'contact' ) ) {
wp_dequeue_script( 'contact-form-7' );
wp_dequeue_style( 'contact-form-7' );
}
}, 99 );This approach requires some experimentation to get the hook handle names right (use Query Monitor's Scripts panel to find them), but it's the right long-term architecture for sites that need certain plugins but don't want their assets loading on every page.
HostBible's LiteSpeed hosting gives you the performance foundation. Keeping your plugin list lean keeps that performance visible to every visitor on every page.
View Hosting Plans