Once a year, a redundant topic reappears on Twitter within the WordPress Community, which sparks a weird fear of using too many plugins as add-ons.
You will hear people trying to joke about the number of plugins some websites have. Or they will post memes about site makers who look into performance improvements after they’ve finished with their website structure.

I understand that in time, we allowed the idea that more plugins mean less performance because it is partially true. If you are installing two-page builders and three cache plugins, it won’t make your website faster; on the contrary.
This is true because the features are redundant, not because the number of plugins is directly proportional to bad performance.
Counterpoint
I could easily bring a counter-example: a site with one plugin having worse performance compared to a 10-plugin website; that’s because at the end of the day, the code and the feature itself matters, not the number of features.
Let’s use Jetpack as an example, it brings many useful features, but I don’t always need all of them on all the websites that I built. I’m simply stuck with all of them; also, whenever they are doing an update to a small feature, I have to update the entire Jetpack plugin, which is harder to track for breaking changes or small visual changes that I’m not aware of.
WooCommerce on the other side, it has the important features in the core plugin and if you want extra integrations with PayPal, Google Analytics, and Facebook you will have to install them as Extensions. In the end, in your plugins folder you will have a structure like this:
- woocommerce
- – woocommerce-paypal-payments
- – google-listings-and-ads
- – facebook-for-woocommerce
This is obviously a better structure because a plugin with 10 extensions is probably better than a single plugin with 50 features.
Advantages of small plugins over big ones
Let’s dive into what benefits we can get by splitting features into multiple plugins dependent on one main plugin:
- The ability to enable/disable each plugin. This guarantees me the fact that the entire code part is not executed anymore. While I disable a feature in Jetpack, I’m not 100% sure it will also remove the entire code execution.
- The ability to update features individually. If I need the latest Google Analytics tracking code changes, I should be able to do that fast, not wait for an entire stack of changes to be released with my small needed change.
- Programmatically, it is easier to check if a folder exists rather than accessing the options table to determine if a feature is active or not.
- A personal preference is that smaller plugins are easier to read and comprehend. It’s simpler for me to create integrations with smaller extensions compared to larger plugins.
Even better with WordPress 6.5.
WordPress 6.5 came with plugin dependencies, which allows us to declare that a Plugin B is dependent on Plugin A. This is blocking users from activating a dependent one without the main one being active.

We will have clear visual feedback showing which plugins depend on each other in the Dashboard plugins page. For example, you cannot delete WooCommerce until you deactivate the WPSSO Product Metadata extension.
How cool is that? How many times have you disabled a plugin and triggered a fatal error because it was a dependency for another? Now that can be avoided within the WordPress core.
Also, now on the plugins page on WordPress.org you will be notified if a plugin has a dependency

Don’t look for firecracker look for fireplace
I have no clue what the last header of this article means, but it sounds fancy.
My conclusion is the following: It is good to be concerned about our websites performance. But we need to understand the plugins structure before being concerned about their performance impact.
There are plugins that hook right into the WP_Query class and that will downgrade the performance of your website exponentially.
There are also plugins that will simply add a small feature in the Admin Dashboard. How many of them you have installed or their impact is insignificant when it comes to front-end performance.
Leave a Reply