I've often heard that having a lot of plugins will slow down a WordPress site. This makes sense of course, as the more code that executes, the longer it will take.

I'm wondering whether the slowness is mostly:

  • a result of the sheer number of plugins? (because WP has to do some processing to locate and load each plugin)

  • a result of having a few slow/heavy plugins?

More practically, when I am writing my own, should I combine functionality into fewer files to gain speed? Or is it okay to have 10-20 plugins each doing a quick task?

  • Summarizing the answers so far, speed has much more to do what what the plugins do than the number of plugins you have. But having lots of plugins increases the chances of having some slow ones.
    – allclaws
    Aug 19, 2010 at 16:30
  • Again from my comment below, if someone has a bias against plugins then all they will see from your comment is "having lots of plugins increases the chances of having some slow ones", nothing more because that would be the only thing that confirms what they already believe. Much like people do with political news these days. Aug 19, 2010 at 16:40

7 Answers 7



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.


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.

  • Interesting tip about the Transients API.. I'd not heard of that before. I think your point that increasing the number of plugins increases the chances of getting a bad/slow one is crucial.
    – allclaws
    Aug 19, 2010 at 16:28
  • "I think your point that increasing the number of plugins increases the chances of getting a bad/slow one is crucial." Well it certainly does give those who are looking for a justification ammunition to support their own biases. :) The reality is it's not the number of plugins its the indiscriminate selection of plugins. Unfortunately there's not currently an easy way to evaluate them without having an advanced user dig into the code. I wonder if we could use StackExchange to crowdsource it? :) Aug 19, 2010 at 16:37
  • That's fair enough! I didn't bring (much of) a bias to this question, but I did get the answer I hoped for - that writing lots of lightweight plugins is not necessarily bad. What I meant by crucial is that your observation explains where the conventional wisdom (that lots of plugins is bad) came from, that is, probability * indiscriminate selection.
    – allclaws
    Aug 20, 2010 at 14:02
  • It wasn't so much you I was concerned with but someone else who might see that sentence and run with it as pure justification for the evils of plugins. Aug 21, 2010 at 1:24

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 :)

  • I though money was "the root of all evil." No? ;-) Aug 19, 2010 at 6:49
  • Don't think so, maybe the premature-optimization part of it :) en.wikipedia.org/wiki/Materialism_and_Empirio-criticism
    – hakre
    Aug 19, 2010 at 7:45
  • @MikeSchinkel "For the love of money is a root of all kinds of evil." 1 Tim 6:10
    – hemp
    Aug 19, 2010 at 21:58
  • "Wordpress is not designed performance wise in the end" Making wild statements like that with no proof or backup is just flamebait. How about we stick to facts please? :) Aug 20, 2010 at 1:53
  • Oh, why not to save the time and instead serve a round Spaghetti Code for our hungry stomaches? :)
    – hakre
    Aug 20, 2010 at 9:24

You can use WordPress with hundred of plugins, when the design of the plugins is fine - the most plugins has a bad code and this is the problem of the performance of WordPress.


it is all about having the right plug-ins. For example, check to see if your plug-ins write their own tables to the database, this generally slows things down a bit. anything that loads a lot of jquery or javascript is generally going to slow it up a bit too. Large quantities of plug-ins does not always mean performance drop. Make sure that you are using a caching plug-in that will help as well.

I assume you are asking this because you are experiencing a slow down? Ask your host if there is anything you can do to speed it up, and make sure that your php configuration is set correctly.


You're looking at 2 things that will slow your site: 1, the processing from the files to the server(s), your php and 2, the way the browse reads the code.

If the code is sloppy the browser will double or triple check the code before presenting it on the screen. If your using a lot of plugins with lots of database and or server requests this could take some time and if they are not made correctly, there could be conflicts with the request that could cause extra time or worse, your site not loading and/or error messages.

rFair404 mentioned caching programs which will help with server requests and some will compress the html code and that reminds me, I need to compress some css pages.


I usually don't install too many plugins for WordPress, instead i try to use theme frameworks that do the main work. It is true that every plugin will add up to resource consumption.

Every plugin will do something, they have to initialise, so they will run some code when a page for your website is requested, not to mention that so many links on admin WordPress panel that makes it harder to load.

Maybe you won't notice it on a shared hosting with 2-3k page views a day, but if you have a website with 3k active users that each of them request 10 pages every day it might become a problem.


I would say that the answer is both.

More plugins = more slowness

Every plugin you enable that adds a stylesheet and/or javascript file to the page is dramatically slowing down your website.

Even the best written plugins will bog your site down if each requires a stylesheet and javascript file to do something on the front end of your web site.

Merge Your Files

If you run a wordpress site, you owe it to yourself to learn how to:

  • Properly merge javascript files together
  • Properly merge stylesheet files together
  • Move javascript calls from the header to the footer

If you run a wordpress site and you cannot do the above things, then you shouldn't be running a wordpress site ... or at least you should not be complaining when your site slows down as you load more plugins.

Additionally, anyone running a wordpress site should know how to:

  • Minify CSS and javascript files
  • Turn on server compression
  • Make sure expires headers are provided with scripts and stylesheets

Poorly written plugins = more slowness

The main ways for a plugin author to really slow your website down are as follows:

  1. Loading multiple scripts or stylesheets for a single page - see above
  2. Using the database improperly - poorly written queries, query modifications, etc. can have a serious impact on a website. Failing to cache results where possible can also make things slow. Most people suck at database development and administration. When such people use databases, problems ensue.
  3. Using wp cron improperly - constant cron jobs on each user request will bring a server to its knees.

Short of writing really bad code (semi-infinite loops, tons of regular expressions where not necessary, etc.), most things aren't going to have much effect when you consider how large wordpress is already. Adding 1% extra processing time isn't much.

Tasks that are innately slow

There are some things that are just slow no matter how well written:

  1. Using 3rd party services - Any time your response to a user relies on a response from some 3rd party, your site is going to become much slower.

Of course, when done properly (cached results, does as background processes where possible, etc.) many 3rd party services can be used without much problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.