When a WordPress site or store gets slow, a plugin is often the first suspect, and often rightly so. But it’s rarely the number of plugins that’s the problem. It’s what each plugin does on every page view: how many database queries it runs, whether it waits on other servers, and how many files it adds to the page.
This guide shows how to find the plugin that’s slowing your site down without guessing, and what to do once you’ve found it.
Is it the number of plugins?
No. A site with 40 small plugins that each do one thing when needed can be faster than a site with five, where one of them runs heavy queries on every page. What costs time is:
- Work on every page view, including pages where the plugin isn’t used.
- Heavy or numerous database queries, such as filters and searches that read whole tables.
- Calls to other servers while the page is built: license checks, news, prices or stock.
- Scripts and CSS on every page, even when the feature is only used on one.
- Large data in autoload or many background jobs running on top of customers’ visits.
Fewer plugins is still a good idea, because each plugin is code that has to be kept up to date. But remove them because they’re not used, not to reach a particular number.
Find it with Query Monitor
Query Monitor is a free plugin that shows what happens while a page is built. Install it, ideally on a copy of the store, and open the slow page. Look in particular at:
| Panel | What to look for |
|---|---|
| Queries by Component | A plugin responsible for a large share of database time or many queries |
| Slow Queries and Duplicate Queries | Slow queries and the same query run many times, with the plugin that called them |
| HTTP API Calls | Calls to other servers, how long they took, and which plugin made them |
| Scripts and Styles | Files loaded on the page, and which plugin they come from |
Query Monitor shows the database and external calls well, but not how much time each plugin’s PHP code takes. If the page is slow and the queries don’t explain it, you need a profiler that measures each function. What that looks like in practice is shown in our example of a JSON function that cost 100 ms. More on the PHP side is in PHP optimization in WordPress.
Turn plugins off, one group at a time
If the measurements don’t point to a clear culprit, find it by turning plugins off. Do it on a copy of the store, not the live one where customers are buying.
- Measure the slow page with every plugin on, so you have a baseline.
- Turn off half of the plugins that aren’t needed for the page to work, and measure again.
- If the page got fast, the culprit is in the half you turned off. Otherwise it’s in the other half. Split again until you’re left with one plugin.
- Turn the others back on, and confirm that the page is fast without that one.
If you don’t have a copy, the Health Check & Troubleshooting plugin from WordPress.org can turn plugins off just for you, while customers still see the site as it is. It’s a fallback. A copy is better, especially when it’s checkout you’re testing.
When only the admin is slow
Many plugins do most of their work in the admin: dashboard widgets, statistics, license checks and news from the developer. If it’s mainly the admin that’s slow, see our guide to a slow WooCommerce admin. Plugins that store large amounts of data in wp_options make both the admin and the rest of the site heavier. How to find them is in the guide to autoloaded options that have grown too large.
Scripts and CSS on every page
Forms, sliders, chat, reviews and pop-ups often load their JavaScript and CSS on every page, even when they’re only used on one. That makes pages heavier to download and render in the browser. Look in the browser’s developer tools (F12) under Network at which files an ordinary product page loads, and which plugins they come from.
Many plugins have a setting to load their files only where they’re used. If they don’t, there are plugins that can remove files from specific pages. Use them with care: if you remove a file a plugin needs, the feature stops working, and you may only find out when a customer complains.
Once you’ve found it
- Update it. Slow code may be fixed in a newer version.
- Go through its settings. Many plugins can turn off heavy features, such as statistics, logging or automatic syncing.
- Contact the developer with what you measured: which page, which query or which call.
- Replace it if there’s an alternative that does the same with less work.
Don’t turn a plugin off on the live store before you know what it’s for. Plugins for payment, shipping and invoicing can look like they do nothing until an order goes wrong. Where plugins fit when troubleshooting a slow store is covered in the plugins and theme section of the troubleshooting guide.
Frequently asked questions
How many plugins is too many in WordPress?
There’s no number. One heavy plugin can do more harm than many light ones. Remove the ones you don’t use, and measure the ones you do.
Are paid plugins faster than free ones?
Not necessarily. The price says nothing about how much work the plugin does on each page. Measure it on your own store.
Want help?
Finding the slow plugin is often quick with the right measurements. The hard part is knowing what can be replaced without something else breaking. If you’d like us to find it in your store, read about optimizing a slow WooCommerce store. We take a free look at your store first and tell you what it will take.