"Cut your plugins to speed up WordPress" is the most repeated piece of speed advice there is, so we measured how true it is. The short answer: plugin count has essentially no relationship with server response time, but a strong one with how many files the browser has to fetch.
Those are two different things, and which one is broken decides what you should actually do.
Method
On 16 August 2026 we requested the homepage of 59 sites ranking in the top twenty for WordPress and SEO queries, from a Hetzner host in Helsinki. Thirty run WordPress, and on 25 of those the plugin paths were visible in the page source.
For each site we counted the distinct plugins appearing in file paths, the number of script and stylesheet files requested, and server response time as the median of three pulls.
Two limits belong here, because without them the numbers should not be believed. First, we only count plugins that load a file on the homepage; a plugin that works purely in the admin is invisible to this count, so the figure is a floor and not a total. Second, our measuring point is in Finland and these sites are far from it, so the response figure is valid for comparing sites against each other, not as a number any visitor experiences.
The result we did not expect
We calculated the correlation across three pairs of variables:
| Relationship | Correlation | Meaning |
|---|---|---|
| Plugin count and server response time | 0.05 | effectively none |
| Plugin count and script plus stylesheet files | 0.48 | real and substantial |
| File count and server response time | 0.08 | effectively none |
Splitting the sites into two groups sharpened the picture:
| Group | Sites | Median response | Median script and style files |
|---|---|---|---|
| Three plugins or fewer | 9 | 435 ms | 30 files |
| Six plugins or more | 10 | 352 ms | 76 files |
Sites with more plugins did not have slower servers. Their median response was in fact slightly better, which probably means whoever installs more plugins also bought better hosting. But they sent two and a half times as many files to the visitor's browser.
Why it works this way
A WordPress plugin has two separate costs and they get conflated.
The server-side cost is that PHP has to read and execute the plugin's code. That cost is real but small, and more importantly, page caching drives it close to zero. Once a page has been built and stored, the next visitor receives the finished file and no plugin code runs at all. That is why plugin count does not predict response time in our data: most of these sites have caching.
The browser-side cost is that each plugin adds its own CSS and JS files to the page, and page caching does not touch that. The files remain in the HTML output and the browser must fetch and process every one. The heaviest site in our list had 14 plugins and 79 style and script files. The web.dev guide to optimising LCP separates these too: server response and resource load are independent parts of one number.
So "cut your plugins" aims at the wrong target. The issue is not how many plugins exist, it is how many files land on the page, and those two do not always rise together.
What to do instead
Look at what each plugin adds to the page
Open the page source and search for wp-content/plugins. A plugin loading files on the homepage while its actual job lives on one other page is the thing to restrict.
Scope single-page plugins to that page
A contact form plugin loads files on every page of the site while it only has work to do on the contact page. This one change usually returns the most.
Get page caching working before anything else
Without caching, the server-side cost of plugins is real and counting them makes sense. With it, that argument is settled and you should be looking at files. We run FlyingPress on this site. If you have no caching yet, the relationship between hosting, speed and SEO is a better starting point than swapping plugins.
Take the page builder seriously
In our data the highest file counts belonged to sites running a page builder, and a page builder counts as one plugin in our tally. A single plugin can add more files than ten others combined.
The limits of this data
Fifty nine sites is not a large sample, and all of them rank on Google, which probably makes them better than average. Correlation is not causation either: the fact that more plugins came with better response times does not mean installing plugins speeds up a server.
And there is one case where the usual advice is right. A plugin that makes an external request on every page load stays a problem even with caching. That one should be removed, not because of the count but because of what it does.
Frequently asked
What is a plugin in WordPress? A package of code that adds a capability without touching core. Everything from a contact form to a full shop arrives as a plugin.
Which plugins are essential? There is no single essential list. What nearly every site needs is one for caching, one for SEO and one for backups. The rest depends on what the site does.
What are the best free WordPress plugins? Free is a poor selection criterion. Better ones: has it been updated in the last six months, and how many files does it add to your page.
Which plugins are good for making a site look better? Appearance plugins are usually the heaviest category, because they have to load files on every page. If looks matter to you, doing it in the theme is cheaper than doing it with a plugin.
How do I find which plugin slowed my site down? Turn caching on first, then count the page source. If it is still slow after caching, the problem is server side and not the plugins.
If you want this done on your own site, we report the file count and the cleanup of your page output with a before and after figure. If the after figure is no better, that is what we write. And to work out which number matters in the first place, the three numbers Google actually measures is a better place to start than any scoring tool.
Comments & Questions
Have a question about this article? Ask, we'll answer.
No comments yet; be the first.