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

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:

Read More
  • 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?

Related posts

Leave a Reply

7 comments

  1. 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.

  2. 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 🙂

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.