Too many plugins in WordPress? Measure what each one costs

There is no plugin count that is too many for WordPress: 30 small, well-built plugins can be lighter than one slider that loads 300 KB of JavaScript on every page. What makes a site slow is a few heavy plugins loading their files where nobody uses them, two plugins doing the same job, and plugins that run expensive work on every request. So measure what each plugin costs on a real page, then remove, replace or restrict the heavy ones. This guide shows how, in about an hour. It is the plugin chapter of why is my WordPress site so slow, which covers the server, caching and images too.

Quick answer

• Run the WordPress theme and plugin detector on the home page and on your most important template (a product, a post, the checkout).
• Anything over 150 KB on one page is worth a look; that is where getReport raises the warning.
• Plugin not used on this page? Load it only where it is needed (Perfmatters, Asset CleanUp, or the plugin's own setting).
• Plugin not used at all? Deactivate and delete it.
• Two plugins for one job (two caches, two SEO plugins)? Keep one.
• Not updated in 2 years, or closed on wordpress.org? Replace it, starting with the closed ones.

How many plugins is too many?

The count is a poor signal because plugins differ by orders of magnitude. A plugin that only changes a setting, or works only in wp-admin, costs visitors almost nothing. A slider, a page builder add-on pack or a chat widget can add hundreds of kilobytes and several requests to every page. What does matter:

The number is still a proxy for the last row: every plugin is code from a different author that has to keep up with WordPress, PHP and security fixes. A site with 60 plugins has 60 update streams to watch.

Which plugins slow down WordPress

WordPress lets any active plugin add files to the page through wp_enqueue_script and wp_enqueue_style, and most do so on every page because they cannot know where you will use them. The contact form's script loads on the blog; the slider's JavaScript loads on the checkout. Each file is a request, and scripts in the head block the page from drawing until they arrive. On a mid-range phone, an extra 300 KB of JavaScript means extra download time plus the time to run it, which is what Largest Contentful Paint and Interaction to Next Paint measure.

Server-side cost is less visible. Plugins that store large settings with autoload on make WordPress load them on every request; since WordPress 6.6, Tools → Site Health warns when autoloaded options pass 800 KB. Plugins that call remote services (licence checks, remote fonts, map APIs) make the server or browser wait. That shows up as a slow first byte, not as heavy files.

How getReport measures plugin cost

The detector works only from what the page reveals. Plugins are identified from asset URLs under /wp-content/plugins/<slug>/ (the version comes from ?ver=) and from the HTML comments and headers that SEO and caching plugins leave, such as Yoast's "This site is optimized with the Yoast SEO plugin" comment or LiteSpeed's x-litespeed-cache header. Nothing is guessed: plugins that add nothing to the front end do not appear.

The page is then loaded in Chromium, and every request whose URL contains /wp-content/plugins/<slug>/ is added to that plugin's total: bytes transferred (compressed, as the visitor downloads them), number of files and network time. Each detected slug is looked up in the wordpress.org directory for the latest version, the last update and whether the plugin was closed.

Three limits are worth knowing. It measures one page, so a plugin that loads only on the shop shows "none" on the home page. The version column is whatever ?ver= says, and some plugins print the WordPress version there. Premium plugins are not in the directory, so they show "not in directory", which means no data, not a risk.

Step by step

1. Make an inventory

Open Plugins → Installed Plugins and note every active plugin with one line on what it does. Then run the detector on three pages: the home page, a typical content page, and the page that earns money. Side by side you now have what is installed, what the visitor downloads, and where.

2. Sort each plugin into one of four piles

Deactivating is reversible; deleting removes the files but usually keeps settings in the database. Test on a staging copy if the plugin is part of checkout or forms.

3. Remove duplicates

Two caching plugins both minify and cache the same pages: double minification breaks scripts, and pages go stale because one cache is purged and the other is not. Keep the one your host recommends; two caching plugins at once explains how to choose. Two SEO plugins print two titles, two canonicals and two schema graphs; Yoast vs Rank Math shows how to pick one and import the other's settings.

4. Load plugin files only where they are used

Three ways, from least to most technical.

The plugin's own setting. Many form, slider and gallery plugins have a "load assets only on pages that use the shortcode or block" option. Check it first.

A performance plugin. Perfmatters (Script Manager) and Asset CleanUp let you switch off each script and stylesheet per page, per post type or everywhere except chosen URLs. Start with the heaviest plugin in the table, disable its files everywhere except where it is used, and check that page still works.

A few lines of code. WordPress prints each stylesheet with an id of <handle>-css and each script with <handle>-js, so the page source tells you the handles. This keeps Contact Form 7 on the contact page only:

<?php
// wp-content/mu-plugins/load-cf7-only-on-contact.php
add_action('wp_enqueue_scripts', function () {
    if (is_page('contact')) {
        return;
    }
    wp_dequeue_script('contact-form-7');
    wp_dequeue_style('contact-form-7');
}, 20);

Files in wp-content/mu-plugins/ load automatically and survive theme changes. Priority 20 runs after the plugin enqueued its files at the default priority.

Scripts that must load everywhere can often be deferred. Most caching plugins have a "delay JavaScript" or "defer JavaScript" option; turn it on and test menus, forms and the cart, which are what usually break.

5. Replace the heavy ones

The usual suspects are sliders, page builder add-on packs, social share buttons, social feeds and popup builders. Often the lighter replacement is WordPress itself: a Cover block instead of a slider, core blocks instead of an add-on pack, plain share links instead of a share-button script. Page builders are a special case; page builders vs the block editor measures the difference. Where you need a plugin, install two candidates on staging and compare them in the detector.

6. Replace abandoned and closed plugins

wordpress.org closes a plugin for an unfixed security issue, a guideline violation or at the author's request, and a closed plugin receives no updates. A plugin with no release in two years is not keeping up with PHP and WordPress. Replace closed plugins first; the abandoned plugins fix page explains how to judge a replacement.

7. Look at the server side

A plugin can cost nothing in the table and still slow uncached pages. The free Query Monitor plugin shows database queries, remote calls and time per plugin for the page you are viewing while logged in; use it on staging. If the report shows a slow server response rather than heavy files, read what a slow server looks like.

Platform notes

WooCommerce. WooCommerce's scripts, and on some themes the cart fragments script, load on many pages, and every extension adds its own. Measure a product page and the cart, not only the home page. Do not unload WooCommerce scripts on the cart or checkout.

Page builders. Elementor, Divi and WPBakery load their framework on every page built with them, so they appear heavy by design. Their own performance settings reduce the cost; replacing a builder is a redesign, not a plugin swap.

Verify

• Run the detector again on the same pages. The heavy plugin reads "none" where you unloaded it, and the finding reads "No plugin loads more than 150 KB on this page" once none is above the line.
• Open the pages where the plugin should still work: the form submits, the slider slides, the cart updates.
• Compare the report's speed module before and after; reading a speed test explains which numbers to watch.

Common mistakes

• Counting plugins instead of measuring them. Removing five tiny plugins changes nothing a visitor feels; restricting one 250 KB slider does.
• Unloading a script the page needs. The page looks fine until someone uses the form. Test the interactive parts of every page type.
• Adding a speed plugin next to the host's cache. That is two caches again.
• Deactivating a closed plugin without a replacement. The feature disappears from the live site. Set up the replacement on staging first.
• Trusting the version column blindly. If a plugin shows the same version as WordPress core, it is printing the core version.

Questions people ask

How many plugins is too many for WordPress?

There is no fixed number. A site with 40 lightweight, maintained plugins can be faster than one with 10 heavy ones. It is too many when plugins load files on pages that do not use them, two plugins do the same job, or you have more plugins than you keep updated. Measure each plugin's cost per page instead of counting.

Which plugins slow down WordPress the most?

On the front end, sliders, page builders and their add-on packs, form and popup builders, social feeds and chat widgets, because they load large scripts on every page. On the server, plugins with heavy database queries or remote calls on each request, such as some statistics, related-posts and security plugins. The plugin table shows the front-end cost; Query Monitor shows the server side.

Is one big plugin better than several small ones?

Not automatically. An all-in-one plugin may load code for features you never use, while three small plugins load only their own jobs; or the reverse, when each small plugin brings its own copy of a library. Compare them on staging with the plugin detector: the kilobytes on the page and the number of requests decide, not the number of plugins in the list.