Making good plugin choices

I’ve often said that a WooCommerce site built with more than 25 plugins was built wrong. That’s somewhat of a shock tactic in getting folks to take responsibility for their plugin decisions. It’s also quite true, though perhaps not with such an explicit number given that plugins vary in size and impact.

Each plugin consumes resources and slows down a site, particularly on weaker hosting. Plugins can also clog-up the database by caching a bunch of data or storing oversized settings inside the wp_options table, even if the plugin is later removed. I’ve seen plugins leave whole custom DB tables behind. Worst are the autoload=yes settings that chew up RAM with every page request.

It’s very important to test plugins first on a clone (dev, staging) environment and never on production.

Plugin decisions tell me a lot about how the site was put together.

When I see very standard framework-type plugins being used I feel better about the quality of the site’s structure. To use a construction analogy — the bones are good. For example, WooCommerce, Advanced Custom Fields, Gravity Forms, Elementor, Gutenberg, Contact Form 7, JetPack, and of course the official WooCommerce extensions.

When I see outdated community plugins or more especially third party Pro plugins that try to do a bunch of nonstandard stuff I know the quality is dubious. That’s when I hear about plugin updates severely breaking the site in the past, those twice-shy trepidations from those having been once-bitten (if not more).

Worse yet, plugins that bundle their own licensing models. I’m talking about you WP Bakery, Advanced Custom Fields Pro, Elementor Pro, Divi, Slider Revolution, and so many more. If you see a folder inside of a plugin called Freemius then run! In these cases you’re activating functionality for the plugin to update itself based on a license you have, and it won’t even function on a clone environment where you need to be doing your development and testing. Plus this is an indication the plugin is not GPL compliant or compatible with WordPress licensing.

I’ve got some more interesting research data for you! I counted the WordPress and WooCommerce hooks (actions and filters) utilized by popular plugins. The average is 195 each. That means that with each and every plugin you have there’s 195 overrides that YOU – the webmaster – are responsible for understanding and maintaining.

Try running 50 plugins and being responsible for 50 websites. That’s nearly half a million customizations minus the overlap of plugins used between those sites. Interested in plugin reduction yet?