Wordpress - Is it heavyweight plugins or lots of plugins that make a site slow?

Generalities

The rule of thumb "lots of plugins slow down a site" is a very blunt instrument and is perpetuated by those who don't understand how plugins work so they pick something easy to demonize.

Yes plugins can slow down your site but it doesn't have to do with the quantity it has to do with the quality and what they are trying to accomplish. I could write a single plugin that would bring a site to it's knees (if there were a reason for me to do so) and it would be worse than 50 other well-written plugins. Of course people write plugins all the time that will bring a site to its knees because they don't know any better.

I guess the only truth to "lots of plugins slow down a site" is that when you have a lot of plugins it's more likely that you'll catch a bad one.

Specifics

So let's talk more specifics. Plugins use "hooks" which are bits of PHP code that run a certain points along the execution path and they can either do something or filter a value or both. WordPress starts calling hooks earlier in its efforts to compose a web page and generate HTML to send to the browser and continues calling hooks almost until it finishes running for a given page.

Depending on which hooks a plugin uses it might be called only on certain pages, in the "background" or even almost never. Some hooks only work within the admin console. Some hooks only work within certain pages of the admin console. And some hooks are called by the internal psuedo-cron system. OTOH, some plugins can load extra CSS or JS files and each of those files slows down performance because of Web Performance Rule #1.

If you want to get a feel for what hooks are called on each page consider using the "Instrument Hooks for WordPress" plugin I wrote for the question "Where Can I Find a List of WordPress Hooks?" Here's a screen shot of what the plugin shows in the footer when used:

Screenshot of Instrument Hooks for WordPress Plugin in action

But just knowing the hooks won't help you know for sure if there is a problem with a plugin. You could call a plugin 100 times and calling it could be negligible compared to another hook call that adds a WHERE clause to a SQL query that could bog down a site that has more than a few hundred posts. Or it could do an HTTP call to another server. Or it could flush the rewrite rules on every page load. The list of sins goes on.

The only real way to know for sure it so audit the plugin's hooks by reviewing the source code or better running it through a debugger like PhpStorm+XDEBUG.

Your Own Plugins

Don't worry about how the code is organized for purposes of performance; worry about what your code does. Optimizing a frequently run SQL query buy leveraging the Transient API (See: Presentation about the Transient API) would be far better for performance than merging the code of 10 plugins into one.

On the other hand, do consider organizing your code for other reasons. I think a long list of plugins can create psychological distress for a lot of users; they see a screen like this, get overwhelmed and just want to simplify things:

Long List of Plugins
(source: mikeschinkel.com)

Yet on the other hand sometimes users can be overwhelmed because one plugin does too much. For example I felt that way with the GD Star Rating Plugin. After trying it on a project (and worse, trying to hook it to get it to do what I needed) I decided to toss it out on it's ear.

So some people (like me) will often prefer lots of small tight plugins that each do one thing and do it well (it would be nice though if WordPress would support a grouping feature kinda like how iPhone iOS 4 lets you group apps in folders.)

Long List of GD Star Rating Options
(source: mikeschinkel.com)

Anyway, hope this helps.


Naturally Plugins are only one part of the performance story, so you can't measure it by the number of files in the end. There is more and you can't say in advance what works, so something that might be well on your computer is not on others.

Instead of looking for performance you should define other and own criteria to make decisions on. For example, for plugins you can prefer to put separate functionality into separate plugins, so to not mix things. This might not ever be performance wise in terms of speed or memory usage, but the trade is to keep things lightly coupled so it's easier to develop and use the plugins. Not to forget, when a new version of WordPress comes out, only two plugins might break out of ten and not the one big one all the time. And in the end, a user only needs three of ten plugins so he needs less memory.

If a user is complaining about the performance of her/his Blog, you can normally suggest that they just can buy a bigger server and performance problems are solved.

(Pre-Mature) Optimization is the root of all evil. Just do not longer think about performance when writing plugins. Take it the light and bright way: WordPress is not designed performance wise in the end, don't make the mistake and try to write performant plugins for it ;)

WordPress is designed with the Big Ball of Mud-(anti-)design-pattern. The plugin system is one that is working very well with it. Just do not think you can optimize that much as a plugin author. You can't. Don't fight it :)

Tags:

Plugins