Menu

I want my site to work the way I want it to. Sometimes this matches the way WordPress works right out of the box, sometime it doesn’t – that is where my plugins come in. I’m using over 20 plugins – is it too many?

Unfortunately, this isn’t an easy question to answer. Different plugins have different levels of load to your WordPress install. Plugins like Popularity Contest add a little hit on every page load, comment, etc. to track all the activity on your site. Others like Share This, WP Grins, etc. hardly add a blip. There are also plugins that shouldn’t cause much overhead by what they are doing, but do because of the way they are written.

Which plugins you use, much more than the number of plugins you use, is the determining factor in their overall effect on your blog.

My recommendation is to use whatever plugins you need in order to make your site behave the way you want it to. However, as you add them you also need to be aware of the effect the plugins are having on your site.

A couple of tips:

Pay attention to your page load times. Occasionally you may want to empty your browser’s cache so you can see your site as first time visitors do.

Pay attention to the number of database queries needed for each page load. Many themes include this information in an HTML comment at the bottom of each page (visible by using View Source). If your theme doesn’t add this, you can add it yourself (this taken from the Hemingway theme):

Plugins that drastically increase the number of queries or page load time may be doing as much harm as good for your site’s overall profile. It’s a good idea to contact the plugin developer to let them know if their plugin is having a negative impact on these metrics for your site.

The other problem you can run into with plugins is collisions and incompatibilities. Most plugin developers will try to mention these up front if they know about them – for example, current releases of my Popularity Contest and WP Mobile Edition1 plugins don’t work well with WP Cache.

Plugin incompatibilities are tough on both users and plugin developers. The best you can do is identify the plugins that aren’t playing nicely together, then check the WordPress forums for solutions and notify the developers.

So don’t be afraid of loading up with the plugins you want, but keep in mind that you need to be smart about it as well.

I recently found out about this one, so it isn’t documented in the README yet. [back]

This post is part of the project: ShareThis. View the project timeline for more context on this post.

I’ve got over 30 plugins active on my personal blog. I’ve also been torn between keeping this factoid to myself or publishing what plugins I have via a different plugin. I’ve had to ditch some plugins, but I keep finding new ones to replace those ones. Thus far, my plugins are playing nicely and my site loads fast. I will add that little bit of code to my theme to see what/how many queries are being made. Thanks!

I’m running 16, but they aren’t all active on the same page load. WP Tiger Admin only impacts me, The AJAX comment and contact plugins only work on individual post pages and the contact page, respectively. Gallery and Audioscrobbler only on the main page, and so on.

Raw numbers aren’t always what it’s about, like you say. A site could run easily with 100 plugins, but crash under the weight of 20 poorly written or poorly matched ones.

I learned this the hard way today – I’ve got 2 blogs I manage, one with 13 plugins and one with 14. Today, one of the sites just up and died on me.

To make a long story short, I had to re-balance both SQL and apache to get the site back online and make them all play nicely together.

It would be *really* good to have some parameters to benchmark this stuff by and I’d be more than willing to run some tests and publish the data, but even I don’t really know what “good” answers would look like.

I’m also wondering what a good baseline for search queries/load time is? I just checked my front page and got 20 queries in 1.489 seconds. Looks like Danny has me beat, but I really have no clue on how to evaluate good vs bad performance.

Also, is there anyway to figure out what my 20 queries might be? I’m guessing 10 of them come from each of the entries, and another 5 come from my use of the Recent Comments plugin – but what about the others?

I currently have 14 plugins enabled on my site, but no more than 10 are seen by the viewer at any given time. In my opinion, the plugin threshold would only be determined by the potential of the server, and the expected load time by the owner.
One thing I have noticed is the performance of MySQL when indexes aren’t tuned or maintained appropriately. This can have an adverse effect on the entire site, limiting its potential.

I’ve got 23 plugins activated but about 30 installed that I enable temporarily for various tasks. My stats were 28 queries. 0.369 seconds. Site seems to load relatively quickly, but I’m on 4Mbps so not sure how it looks on a dialup or slower cable connection.

Unfortunately there are no real guidelines for seeing if a plugin is misbehaving just by looking at the page creation time and number of queries. The best advice I can give you is to look at these numbers with a plugin enabled and disabled – then decide if the plugin’s value is worth whatever performance cost it brings with it.

One thing I have started doing on sites I take care of that use multiple plugins is stripping out the admin functions and adding them into a seperate file, called with an include.

What you see with a lot of plugins is that the bulk of the code is devoted to the admin interface. This is of course wasted file loading/compiling on regular site views. Moving the plugins to their own folder and adding a simple check at the top if you are in the /wp-admin/ section and then requiring the admin file ends up helping out.

One of the actual plugins I did check on was the (now defunct) EditorMonkey. I renamed the actual plugin and created a new plugin with the name (and head information for the plugin loader). In that file, I just included a simple check if the request_uri was in the /wp-admin/ and if so it included the full EditorMonkey file. Running XDebug, I noticed about an 80k difference on peak memory usage.

This probably would be a lot of work on a lower traffic site, but on one I manage we get over 250,000 hits a day and running off 2 machines – 1 for apache and 1 for mysql. Before I did this, the server would hang alot. Since it has been done it has greatly reduced that. Another note – I never tried this with xmlrpc as we never use it. It would probably require a bit of extra coding to determine if the plugin is loaded via xmlrpc.

Basically my train of though with doing this was taking the Drupal model of “if it isn’t needed then don’t load it”. If you are on a server running op-code caching, I doubt it would really help. If you don’t have op-code caching, then it will save a lot of cycles having to compile a lot of needless code.

I’m VERY curious about how your options page in WordPress looks like. Do the tabs under options split up into two lines? I’ve got just three plugins, but I’m always interested in how to reduce complexity of the user interface while still offering a lot of features. I think that WordPress does a great job with it’s plugins.

[…] of the number of plug-ins on WordPress performance. For example, a listing in early 2007 from Alex King’s blog seems to have the largest nucleus of discussion. The earlier consensus was that too many plug-ins […]

[…] party Javascripts and data sources and 2.) the database hit for the local plugin (see more on that here). I wish there was a way of caching that content locally, but I think that would have to be worked […]