Stop telling users they shouldn’t be running very many plugins


If you are having trouble with your WordPress website, or if you ever have a problem with it in the future, you should first check the number of plugins you are running. If it’s a big number then you’ve likely found your problem. You should trim down your number of active plugins immediately.

The best thing you can do in the future is keep that active plugin count as small as possible.

Except it’s not.

None of what I just said is true, and I wouldn’t recommend anyone follow that advice. This sort of advice is both misleading to users and contrary to the spirit of WordPress, yet a growing number of voices within the community are encouraging users to limit the number of plugins they run. It’s a bit sad, because plugins are arguably the best part of WordPress. To convey that they are dangerous in large numbers is to do a disservice to the community itself.

In reality the number of active WordPress plugins you run isn’t important, and the only thing that number can tell anyone is just how much you love plugins.

I’ve heard this “fewer plugins is better” thinking expressed in a few different places. Sometimes it’s in a WordCamp presentation and a speaker recommends against running very many plugins. Other times it’s a back-and-forth on Twitter or a frustrated developer who say, “Of course your site is running slowly, you’re running 80 plugins!” Heck, I’ve been told I run too many plugins.

Of course everyone’s plugin count comfort level is different. Sometimes it’s twenty, sometimes it’s thirty. I’ve heard some say zero plugins is best. But none of these numbers matter in the least.

Telling a user they are running too many plugins is like telling them they’re holding their blog wrong.

What does matter is the nature of the plugins themselves. If the plugins are properly coded and serve their individual purposes well, then it shouldn’t matter even if you have one hundred of them active. If the plugins are big, bloated, and poorly written then you could run into a problem with only two active. The key here is the number of active plugins is unimportant; only the quality matters.

I bet the reason so many speak against running “too many” plugins is a simple one: they’ve run into bad plugins in their work and assume that the odds of running into a bad one increase the more you use. Technically this is true, but speaking out against high numbers of plugins isn’t the right response to the problem, and it’s misleading to the community at large. Instead, we should speak against the use of poorly coded plugins, and not an arbitrary number of them.

I’m all for telling people what to do, and have done my fair share of preaching on this blog. But it’s important to preach to the right people. If there’s a problem with a plugin it’s the developer’s fault, not the user’s. Telling a user they are running “too many plugins” is like telling them they’re holding their blog wrong.

Users should be able to activate any number of plugins they wish, and do so without expecting any trouble. When this kind of plugin use is encouraged, championed even, users will come to expect plugins to just work rather than the opposite.

And if users have that expectation long enough, maybe more developers will start meeting it.

84 thoughts on “Stop telling users they shouldn’t be running very many plugins

  1. I think the answer is somewhere in-between. Telling someone not to install as many plugins as she wants is plain wrong. What is also wrong is installing plugins for things that WordPress provides out of the box or someone could integrate this functionality writing a line or two of code . Examples?

    1. *some* social buttons
    2. Popular posts based on comments number.

    And so many other things that it’s way better not to involve someone else’s code and be 100% that those things will work even in WordPress version 10.

    • I agree with this, I think the article makes it too “black and white” when really users just need to understand WordPress better before they go installing another plugin.

  2. We call it pluginitis.

    It’s not the installation of lots of plugins that’s the problem, but the installation of many *heavy* plugins that worry us. We have plenty of sites with 30+ plugins going on with no issues at all, but others with ten badly selected and poorly tested plugins that are grinding along under the load of hundreds of slow query hits.

    I suppose the problem for developers is that the more plugins there are, the more debugging targets they have. If there’s a hundred plugins there you have a lot to look at, and you can’t possibly know them all. Debugging an issue in WP is usually far simpler to replicate and test.

    You also have to think about the risk of interactions – each plugin added increases that possibility. It could be badly named global variables that bump into each other, or a PHP version issue, or poor indexing on a plugin’s extra tables meaning that as the site grows it grinds. There’s so many things to look at and if the site in question is run on a shoestring then I would indeed say that there’s a lot to be said to being cautious.

    • This is it, exactly. When someone comes to me and tells me their site is behaving strangely, and I FTP in and see they have 30+ plugins installed, I die a little inside. Figuring out where the problem is, then deciding what is causing it (just a poorly coded plugin? Conflicts? Unintended interactions between plugins?) is made significantly more difficult with every plugin installed.

    • Bingo.

      Unless I know that my client has a good idea of what they’re doing, I advice against running a lot of plugins. Otherwise, they end up installing a lot of poorly-written plugins and not deactivating them!

      A client once had 10 different plugins all designed to add a shortcode to handle a media gallery. When they discovered the built-in media gallery, they stopped using these plugins … but left them installed and activated. That meant 10 (actually 15 due to the way they were built) different functions filtering the_content(), passing it through regex, output buffers, and the like … without actually changing anything. Deactivating all of those unused plugins sped up the site a lot – as in taking a 12-second load time down to 0.3 seconds.

      So it really depends on who is giving the advice and who is receiving the advice. But a blanket “keep your plugin counts low” statement is not at all valid. Then again, neither is a blanket “plugin counts don’t matter” statement …

  3. I completely agree, Ryan! Whenever I hear someone telling a user off for running too many plugins, I wonder what their arbitrary max number of plugins should be.

    I’m a strong advocate for coding standards and best practices, and if the plugins you’re running are adhering to those, it shouldn’t really matter how many you have!

    A better suggestion to someone running a lot of plugins who’s running into trouble would be to try disabling them all and re-enabling until they find the problem, then just remove that one. Possibly even install another plugin (heaven forbid!) that shows memory usage and see which plugins make it spike to know which one is possibly poorly coded, or just not a good fit for their setup.

      • Perdrix, I have used TPC! Memory Usage in the past, but WP-Memory-Usage is more up to date so perhaps give that a try.

        Unfortunately none of these specifically show individual plugin memory usage, but you can compare average memory usage with and without the plugin enabled for a good indication.

        If you wanted something more accurate and also more advanced, you could look into XDebug with Webgrind.

  4. Sure would be helpful if there was a way to ensure the quality of the downloaded plugin eh? I mean, users can’t be expected to understand good code. It would be great if they did, but that’s not realistic. Anyone can hack together a crappy plugin, and release it to the masses…. make it sound amazing, and it’ll get used. But, that’s part of open source I guess… ONce you get to be part of the WP community, you can learn who is putting out quality, and who isn’t. But a lot of users have to fend for themselves. Dunno what the best thing is, upgrading the plugin repo?

  5. Biggest issue with many plugins for a user is upgrading WordPress. If plugins are not compatible with new WordPress (and that happens a lot), these incompatibilities can prevent user from upgrade, or they can cause problems. And getting support for so many plugins, getting fast solutions can be a big problem. Debugging website with many plugins can be slow if you need to find exactly what plugin is causing problems and why.

    Maintaining 50, 60 or more plugins on one website can be a pain sometime, and that is the one of the reasons (upgradeability and compatibility with WordPress are two additional reasons) to decide to find some other plugins that can help bring down the number of plugins used. But, number of plugins is not that important if everything is working fine. I have seen slow and bad websites with 3 plugins and I have seen great ones with 100.

    Biggest problem with less-plugins upproach is this: if you need a feature plugin provides, to get that feature you code it into the theme and after a while you get massive functions.php file that you will have a hell of a time to transfer to another theme. Less plugins and same level of functionalities, means that code must go somewhere else, and everything else is very hard to maintain, and anyone suggesting to drop plugin and add code to the theme is neglecting code maintenance later.

    Great thing about WordPress is choice: you have thousands of plugins, and with help of community users can find and use best plugins and make sure that these plugins are up to date.

    • Well said Milan but as you pointed out you need the help of the community to find the best plugins, then again, even the best ones get outdated. How many of you have used NextGenn Galleries?

      How many of you were able to successfully transition to native WordPress galleries? Around 4,000 people are downloading it every day not having a clue that they’re getting locked in. It’s okay if your SEO plugin breaks some day, you’ll be able to restore all your keywords and titles ( probably from post_meta ), etc. But it’s not okay if your gallery plugin breaks since you’ll be left with a bunch of [nggallery] shortcodes that nobody else can replace an a gallery folder with all your images which WordPress doesn’t really know about. So my question is, how do you find good plugins? without being a hardcore WordPress developer of course.

      • This is a big problem right now. We have plugins repository that is next to useless and not a single website that does plugins reviews (both free and commercial) on a regular basis. And if you don’t know someone developer who works with WordPress daily to recommend something you can get stuck with broken website.

        • On plugin directory, you have last updated, ratings, broken/working reports, downloads count…all of this is valuable data when you wanna decide on a plugin.

          Maybe the plugin directory should crunch all that data and display a big, idiot-proof “health meter” on the page of individual plugins…

          • I don’t care for repository much, and even if I need it I can’t find what I am looking for. But, most of the new WP users, users that are not too technical will have hard time finding anything there if they go away from the main page. I have many, many clients and almost all of them say same thing about it: repository is useless. Of all reorganization changes announced over the past 2-3 years only one made it into repository and that is user voting for working or not working (and even that is abused more than useful).

          • Yes, the repository does have this, but I’ve found it to be rather inaccurate, or at least not used hardly at all.

  6. A user is more likely to run into trouble if they’re installing plugins indiscriminately.

    But it’s definitely not like: with each additional plugin you install, you add 100 milliseconds of load time.

    @Milan also makes a good point regarding debugging when you have too many plugins.

  7. In a WordCamp presentation around a year ago I remember somebody saying that a clean WordPress installation has over 1500 different actions that are being carried out ( do_action ) on *every* single page request. I bet it’s even more these days, but my point is that not a single one of them slows down the website, while one single plugin can misuse one single action and produce a 10 seconds loading time, so yes, I totally agree with you Ryan and thanks for publishing this.

    I’ve also heard people judge the quality/performance by the number of lines of code, not in plugins in particular but in general. A 30-line program can be 100x faster than a 5-line program, Google Code Jam can prove this. Bottom line is — you’ll never know unless you benchmark.

    Thanks again for the post!
    ~ Konstantin

  8. Ryan, you really did very little to help change the tone of the “Great plugin Debate” and like most people who tell people stop running too many plugins you too failed to inform readers of the why’s, or how’s of the subject, am I just to take your word on it becuase your are a respected WP authority.

    I bet the reason so many speak against running “too many” plugins is a simple one: they’ve run into bad plugins in their work and assume that the odds of running into a bad one increase the more you use

    The major problems I have with “too many plugins” is the overhead cost as a result of bad optimization, a lot of plugins add scripts (js, css..) on activation most of these stay on the site whether you are using the plugin feature or not even in the admin. Plugins authors should read this article on

    Another problem is plugins not taking advantage of core WordPress functions resulting in unnecessary bloat, this is further compounded by the fact that you cannot extend existing plugins and use them as a base for new plugins there is a presentation on plugabble plugins, can’t remember the exact link but I think it is on WordPress TV.

    But your are correct simply saying stop using too many plugins is a bit counterproductive, unfortunately it not as simple as you make it sound.

    • I think you failed to see where Ryan said its the quality of plugins that counts. Good quality plugins don’t load unnecessary scripts and do take advantage of core WP functions. That’s part of what it means to be a well written plugin.

      • Not really… saying properly coded and defining what properly coded is, are different things, in addition to which a lot of the “quality plugins” that do this A-LOT, fact is most plugins are not optimizing scripts in a proper manner.
        Users are not aware what properly coded means and the truth is that the more you install the more likely it is to run into the bad ones, that just just the way it is…

  9. Excellent article, Ryan! I think you really hit the nail on the head with quality vs. quantity. Overseeing the support community for 8BIT has really shed light on that for me too. Plugin developers have to care enough to learn how to work within the WordPress sandbox without throwing sand in other developers eyes, so to speak (ie. like properly enqueuing jQuery). Thanks for pushing the community to challenge ourselves!

  10. I think user education is the key point here. While I do definitely agree with your overriding point, I have an example of someone following advice without thinking of it.

    A site having issues, and since they were told not to have too many plugins, had only around ten.

    And six of them were SEO plugins.

    I mean, one is good 6 must be better, right? No.

    Here it was not the number of plugins running, it was the fact the ones that were conflicted with each other. And in this case it was not even a matter of the user needed to know anything about code – it was a matter of common sense. One the person stopped and thought about it (discounting the “six SEO plugins you need right now” blog post her read somewhere) they realized that DOH pricing one of those plugins with ALL the features they needed was enough.

    So how about we promote to users that they think carefully about the plugins they have installed, clean out ones they don’t use, and read the descriptions carefully. 😉

    • That. I like to tell people ‘Run all the plugins you need but be aware that may not be all the plugins you want.’

      It’s not about the blanket number of plugins, but what they are, adn the first step to educating someone is to get it through their head that they need to think about what plugins their site must have. Far too many people just install away (pluginitis, exactly) and don’t stop to think about the consequences.

  11. +1 for the comments about educating users. It’s more useful to examine how the plugins function, rather than focus on the total number.

    That said, volume can matter.

    If someone is running 30+ plugins with 40-50 http requests for javascript & css files, what am I supposed to say when they ask the inevitable “why is my site slow” question? (sure, I could tell them to use a cdn).

    Even if each individual plugin isn’t bloated – lets say they only require a reasonable 1 or 2 scripts – it’s the volume that’s the problem. Individually the plugins can be fine, collectively they can cause problems.

    It’s the same with db queries.

  12. Mo plugins = mo problems. The reality is that many plugins have less than optimal overhead and coding. I think I remember the Gravity Forms guys saying that the a large percentage of issues that they troubleshoot with Gforms are the result of conflicts with poorly coded plugins.

    In a perfect world where plugins are perfectly coded, plugins are updated before new releases of WP drop and themes are perfectly coded, feel free to install hundreds of plugins, you will have zero issues.

    Until then, the fewer moving pieces your machine has (wp install), the lower chances you will have of things break…. that’s the simple reality your average WP user is facing today.

    Installing more plugins than you need or installing them with abandon is a simple formula for breakage, increased page load times and increased troubleshooting time …. especially if you are not a WP dev, where you’re not only looking at downtime but having to write a check to a dev to troubleshoot for you.

    • If you’ve got a plugin that’s causing issues, and you can troubleshoot it, then it’s good practice to fix the problem and alert the developer. Coder’s aren’t perfect, but the WordPress community is one that, in most cases, will accept help and criticism warmly. There are some exceptions, but in those cases, you’d be doing more of a service to the community to fork the plugin with the change and alert the plugin moderators.

      WordPress is a meritocracy – jump in, get your hands dirty, and you can make the world a bit better for everyone else 🙂

    • That’s why I update my plugins in parallel with WordPress core development, so when new WP is released, my plugins are up to date. It takes more time, but since I run commercial business, my users expect that plugins will work with latest WP. I know GravityForms is doing the same. But 99% of plugins (and themes for that matter if needed) are waiting for WP to be released to get into fixing problems, and that causes users to get stranded: new WP and outdated and broken plugins.

    • While I agree with you that there are thousands of poorly coded plugins out there that cause lots of problems, as a plugin developer myself, the Number one problem I face is poorly coded themes. I get a support request almost every single day from someone who has a problem with one of my plugins, and the problem is almost always the result of a poorly coded theme. This is especially a problem with a lot of the themes on marketplaces like Theme Forest (at least items published before they got stricter).

      • @Pippin if you have some specific examples, both of themes or problems you’ve run into, I’d love to hear about them and see what we can do to help really stomp out that kind of thing on ThemeForest and CodeCanyon. @Japh on Twitter for an email address or something 🙂

        • The number one issue is with loading jQuery correctly. But also exclusion of wp_footer() and wp_head() are also common problems I’ve run into with Theme Forest themes.

          • Ah yes. Hopefully that sort of thing is a rarity these days, but even recently we’ve had forum topics come up about it, so hopefully authors are up to speed now. The review process catches most of those issues too.

            Please feel free to shoot me an email or @Japh on Twitter if you have any other feedback

          • I have seen ThemeForest theme released last month that don’t have wp_footer() and even wp_head() is in the wrong place, and it uses own included jQuery 1.2 (yes, 1.2) hardcoded in header. NOTHING works with it. And if you try to use jQuery 1.5 or 1.6, you find out that slider in the theme is written 2-3 years ago and will not work with newer jQuery versions., and slider is the main feature of the theme.

      • Theme Forest is the biggest source of badly coded themes on the internet. I have seen few themes that I am 100% sure that are not even tested on the real servers (upload them on Linux server, and find out that line endings are Mac type only, and this breaks PHP). I don’t even accept custom work that involves Theme Forest themes. And same goes for many plugins on the Envato’s Code Canyon. Users are paying for broken plugins and themes and very often they have no way on getting help from the authors.

        • This is something we’re hoping to improve dramatically over the next little while. Making better and stricter review guidelines and enabling better ability for users to get updates for their purchases.

          Again, please contact me if you come across situations like this so we can learn what we need to do better.

          • Many of my customers tried to contact authors for help on Theme Forest, and they either are left to wait for weeks even or they don’t get help at all. But, if the theme is made right in the first place it would be much easier for someone to help them. has a very interesting script that checks each theme during upload to make sure is up to the specifications. Theme Forest desperately needs that for all themes, or more and more developers will distance themselves from themes coming from there. All themes there must be checked, because many of the old themes are still purchased and they are still broken.

          • Absolutely, in fact we have an article scheduled to be published shortly on about exactly that! Trying to improve the processes and get theme authors to follow the procedures that the directory themes go through. Hopefully soon we’ll have a more robust process for this, but raising our author awareness is in some ways more important and a good first step.

    • To continue, as a plugin developer, I’m always a little offended that there is a “stigma” around plugins. Seems to go about like this: “there’s a problem, it must be caused by a plugin! No way could it be caused by my theme because all theme developers are great!”. In reality, I fix problems in themes almost every single day. I’ve even fixed problems in themes by top-tier developers.

      Just because it’s a plugin doesn’t make it bad; just because it’s a theme doesn’t make it great. It’s all about the developer.

      • This really goes both ways. I’m both a theme and plugin developer, so I get to see each side of it. It’s usually the theme/plugin developer who’s willing to help out the user who gets blasted with “your theme/plugin is broken.”

        Of course, even top-tier developers make coding mistakes. That’s just the nature of what we do. If you see a theme/plugin doing something wrong, send the developer a note about the issue. Most of the time, they’ll get the issue fixed and everyone is much happier.

  13. Yes, you should be able to use as many plugins as you’d like but….

    …just as Andrea said, I’ve provided support on numerous occasions where users aren’t using common sense (6 different SEO plugins?), or, are using a plugin instead of a native WP features (most recent posts), or, activating numerous plugins but never actually using any of them (leaving unnecessary .js/.css sprinkled throughout the site).

    Often times I think when a developer tells a user not to use as many plugins, it comes down to a failure to educate that user. It’s a failure in taking the time to explain why you shouldn’t be using plugins that conflict with each other, or, how to check of a .js or .css compatibility issues between plugins and themes. I know I’m guilty of not always taking the time to explain the why’s or how’s of plugin usage.

    The bottom line is that there’s a large part of this discussion that wasn’t touched on in the article that should probably be considered before placing a blanket answer on all WP users.

  14. I actually try to keep my WP sites as lean as possible, and only install plugins I know are free of conflict and can be trusted.

    I used to rely on A LOT of third party plugins, to the point of having about 15 in one site. However, I’m currently reviewing such site and I’m appalled at how many errors it’s throwing because of conflicting plugins (particularly MMForms, which wants to run on ALL pages and breaks jQuery).

    I agree with @Andrea_R: it has to be a matter of education on both parts, the developers and the users. However, end users just want to get a new “feature” and shouldn’t have to bother with whether the plugin is well developed or not. Unfortunately, a WP site sin’t like an iPhone, where no matter how many apps you have, they are pretty much running separately: in WP, plugins usually run together as long as they are active, and that’s something to keep in mind.

    I think most of the responsibility falls on the developers, who should really stick to coding suggestions and be aware of common coding mistakes. It’s a learning process (I’ve made those mistakes too) but it’s all for the sake of improving the awesome WP community.

  15. Yes, extensibility is one of the best things about WordPress. Yes, we would should focus on the quality of code. Yes, and the pure number of plugins is still a concern because, as others on this thread have mentioned, WordPress is a continually evolving ecosystem. That’s not to say that there’s a right or wrong number of plugins to run, only that more plugins take exponentially more time to maintain. 

    There is always a potential for developers to stop developing their plugins. As a user rather than a developer of plugins, I am thankful to developers who freely contribute their time and energy to making all of our sites better. I would also like to encourage users to donate to developers of free plugins and to buy premium plugins. While some developers will continue with only the reward of our appreciation as users, contributing financially can encourage developers to continue plugin development in the context of their custom work. If we want to raise our expectations of plugins, we might consider raising our expectations of our own participation. 

  16. Ryan, I agree with you there. Active plugin count doesn’t matter. Plugins that runs silently in the background are great. Jaquiths Login Logo plugin or Menu humiliation … you can have tons of plugins like that, and it wouldn’t impact your site’s load time at all.

    One of the reasons why I love WordPress is because I can say “There’s a Plugin for that” – Quoting iThemes shirt.

    Now there are few ways plugin count can affect your site’s load time. When plugins are outputting their own JS file(s), and/or CSS file(s) etc. Example, you have 30 plugins each outputting their own CSS file and JS file… You have got yourself 60 additional HTTP queries loading on all pages.

    The sad part is that most of those plugins have a visual back-end, but very few allow you to turn off their output or select their output only on specific pages. For example: Contactform7 outputs a JS on all WP pages… In most cases, the contact form is located only on the contact page. So having an extra JS on each page is stupid.

    In an ideal world, each plugin author would have some sort of conditional thing built-in, so it only registers their jQuery or CSS files on pages their plugin is active. Also, they should have the option for users to turn off their output if necessary.

    Example WP-PageNavi plugin. Lester Chan understands that most folks have custom styling for the navigation. So he has the option for users to uncheck the default style.css file… Often what happens is that users override plugin’s styling from their theme’s style.css file, but they don’t know how to stop the plugin from loading the CSS file regardless.

    I wrote that article a while back out of frustration.

    I think this whole issue has to be dealt in a better way, so we can only load scripts and styles on pages thats needed.

    Example: The twitter blackbirdpie css loads on all pages. But in an ideal world, it should load only when a tweet URL is detected.

    I hope I am making my point here. Correct me if I am wrong because I am not all developery as you guys are.

    • In my plugins I have added extra code that checks for scripts injected by other plugins and is removing them. Contact Form 7 does this, Thesis themes do it also. But, this is not a long time solution, since new plugins get released, and authors still don’t understand that they need to check where they are including scripts, they need to limit scripts/styles inclusion only on pages made for their plugin.

    • I always limit script output from my plugins to the pages it’s needed on. If the plugin has an admin section, then the admin JS/CSS is only loaded on that page. If the plugin displays content on the frontend, then the JS/CSS is only loaded when needed, except in a few rare cases where there’s no good way to do it.

  17. Plugins are definitely one of the best parts of WordPress (I agree with that statement 100%), but that doesn’t mean you should activate every plugin you find just because it does something “cool”. I don’t put a limit on how many plugins you should or shouldn’t have activated within your WordPress install because that really depends on the nature of your particular site. However, I strongly disagree that having a limitless number of plugins activated should be considered a “good thing” or even an acceptable thing to do.

    Yes, if your plugins and your theme have been coded properly according to current WordPress and web standards, you probably aren’t going to run into problems running even 100 plugins on your site. But that’s not the point in my honest opinion. The question you really should be asking yourself is if you absolutely “NEED” every plugin you currently have activated. You might “WANT” to have that cool tabber, slider, social networking box, etc. ect. but do you really “NEED” it.

    I mean, let’s face it, plugins are cool and they can add cool functionality to your site, but that doesn’t mean that you “NEED” that functionality to have a good quality website. If fact, you are probably doing more harm than good by trying to add “cool factor” vs. really evaluating what your site should consist of content and design wise. In most cases I am willing to bet that if you have 10+ plugins activated, you probably could and should eliminate several of them. There is nothing worse then browsing to a website to find an endless amount of sliders, tabbers, advertisements, social media buttons and pop-ups. Don’t you realize that your actual content gets lost in all that mess?

    I’ve been running a theme business for over 3 years now and can say in all honesty that 70% (plus) of the time when a customer runs into problems, it’s due to a poorly coded plugin. But again, that’s really not my issue with users running dozens of plugins. Evaluate your site and your content and stick to the plugins you actually can’t live without vs. the ones that just add that “cool factor”.

  18. I disagree with this post 100% limit the number of plugins you use or atleast go in and strip out the unnecessary code… i had a fellow developer tell me to to use a plugin to use Google Analytics instead of just adding the 3 lines of javascript to the footer file… The plug in used 3 php includes with other 100 lines of code in each plus a javascript file and a style sheet… but really i can just add the 3 lines of code to the footer and get the same result so what is the point of the plugin… dont get me wrong i think that plugins are great for wordpress and make it what it is today but you defiantly need to limit the number of plugins

    WPCandy for example scores a 65 on YSlow because:

    This page has 23 external Javascript scripts. Try combining them into one.
    This page has 6 external stylesheets. Try combining them into one.
    This page has 15 external background images. Try combining them with CSS sprites.

    Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Some ways to reduce the number of components include: combine files, combine multiple scripts into one script, combine multiple CSS files into one style sheet, and use CSS Sprites and image maps.

    Does it really need 23 javascripts to make this page work? i doubt it but because the plugin is installed and active it is loading on this page that it probably isint even being used on

    • I think you’re missing the point of quality, not quantity. Just because some analytics plugins use lots and lots of code, doesn’t mean all of them do. I could write you an analytics plugin that uses just barely more than the plain tracking code by itself, and it would be much, much easier for users who don’t know (or want to interact with) code.

      • Yeah i dont disagree with that i could write one as well but the point that i am getting at is all the extra “bloat code” in these plugins…

        Answer me this does WPCandy really need 23 JavaScript to make this page function? Or 6 style sheets? why not combine them?

  19. The Great debate. I think it comes down to in many cases a matter of need, and availability of resources and knowledge when making these decisions. I’m a huge fan of plugins and like Sayed Balkhi I love being able to say “There’s a plugin for that”, especially when myself or my clients are looking for a quick way of implementing some additional functionality at a fraction of the cost of developing it from scratch.

    It’s very difficult for the average user to know what’s going on behind the scenes though, and lack of testing, valuable feedback, meaningful rating systems and general benchmarking of performance means most people are shooting in the dark when it comes to making these decisions.

    We should definitely as a community be doing more towards reporting bad behavior plugins, and apparent conflicts as far as possible. Like anything else this is a community effort. Yeah sure tell people to build functionality into their themes, but don’t only do that because you’ll be making a buck off doing that dev for them.

    People have needs, and if we can’t deliver on time and within the budget they’ll resort to whatever method is available, which in the majority of cases comes in the form of a plugin, bite sized, easy to find and easy to install. It’s like diets, you never know which one works unless you give it a bash!

    I say, use whatever plugin you want, but be sure to test it first, backup your site with a wide range of backup “Plugins” or other methods available and then go ahead.

    I presented a talk on WordPress as “IS” a CMS at WordCamp Cape Town last week and the majority of the talk focused on using plugins to achieve various results without code. I outlined a process to be sure not to make any major plugin blunders as well. That was the Publisher track to the WordCamp. In the dev track people were saying, plugins, Bah Humbug!

    My Presso online using posts as slides –
    This discussion is being added as part of the dialogue!

  20. What are fighting over? What is the perfect number of plugins? Or, where the end user goes to complain when their site isn’t working? The theme developer, the plugin developer, or the site that had the awesome review?

    Three is the magic number. (Well for me anyway.)

  21. I really appreciate the diversity of comments on this post from the various perspectives of plugin and theme designers to those who help clients troubleshoot. Because I’m more in the latter category, I’m a big believer in less is more when it comes to plugins. Install the ones you need, not every cool whizbang available. And, help users by reviewing plugins that do a good job, plus pass muster on the lean code side of things too. Maybe if those of us who have client followers start educating them on that aspect of plugins, we’ll have far less troubleshooting to do. And, maybe it will increase the demand for lean coded plugins, which will encourage more developers to make it a priority too.

    • I am author of GD Press Tools plugin and that one is intended to be a central plugin for administration of website and include things that normally are done by 20 or more different plugins: backup, seo, sitemaps, tagger, security, settings, maintenance, debug, logs… And plugin is very popular with my clients because it replaces bunch of other plugins and in the same time, when upgrade time comes, you update one plugin, when new WP is out they are sure that I have made it compatible with new WP and that all upgrades are bug fixes are coming fast. And since website administration is very sensitive area, its important to keep things straight. And that is great benefit of having such plugins instead of worrying about 20 separate plugins when WP needs to be upgraded.

  22. A site with “too many” plugins usually comes from the site owner who doesn’t know how to prioritize what he want his site to do.

  23. Damnit. I’ve been meaning to publish this same post for a while now.

    Numbers don’t matter. Complexity matters.

    I run 51 active plugins on my sites. No, not a typo. FIFTY-ONE.

    Virtually all of them have zero load impact on the site. They are small plugins, doing one thing, in one place, and adjusting one minor detail that I want changed.

    You can run as many plugins as you want as long as they’re simple. It’s when you get overly complex plugins that do too much or try to make complex options screens and such that things go wrong.

    USE SIMPLER PLUGINS and you’ll never have a numbers problem again.

    • What Otto said.

      However, there is one thing that no one (as best I can tell) has pointed out. Every new piece of code introduced into an environment carries with it yet another potential vector of attack. Think timthumb. Small discrete scripts as plugins are fine, but every new portion of code that must be executed also carries risk… even small. Sometimes big, depending.

  24. Some plugin developers miss bugs, and cannot catch each and every one.

    Poorly developed plugins add scripts/styles to each page/post instead of limited to where the plugin feature is used (and don’t use wp enqueue script to allow this to easily be fixed).

    There can be consequences to plugin-itis that most end-users do not know how to troubleshoot. I try to explain WHY there needs to be awareness to end-user actions. I find that to be a better technique than just scaring end users with general statements.

  25. I have mixed feelings about this topic. I see where you’re coming from. In a perfect world all code would be valid and the plug-in authors would always keep it updated to accommodate any code that needs it after a core change/update.

    I think that is a good scenario to work towards, but I don’t think the repo standards are high enough to simply say this is right and that’s wrong. It’s almost like saying don’t look both ways when crossing the street if you’re light is green. You should be able to, your light’s green, so you should be safe right? Not good advice though… SPLATT!!!!

    Another thing to consider (more for people that want to learn to code, not for users who have no intention on learning), if you need to add a certain function or feature to your website, and you always turn straight to a plug-in for the answer it will hinder you learning process. I think sometimes, it’s best to use a plug-in. If it’s a case of “Re-inventing the Wheel”, I’d definitely go for a plug-in to save time.

    On the other hand, I guess if no one warns users to moderate the amount of plug-ins it will ultimately lead to more work for the rest of us. When it breaks, someone has to fix it. Or maybe it just causes congestion on the support forums.

    To summarize my opinion I’d agree that what you’ve suggested is something that should hold true, and is something that WordPress should strive for. I’m just not sure that the manpower is there to support additional regulations for the Plug-in Repository.

  26. Pingback: Plugin Quality Not Plugin Quantity

  27. Pingback: WordPress Plugin Spring Cleaning, It's not just for Spring!

  28. Pingback: You shouldn’t run too many plugins and here’s why

  29. Pingback: Why I don’t run a ton of WordPress Plugins! | IF IT IS CREATIVE

  30. Pingback: Do You Really Need All of Those Plugins? « Weblog Tools Collection

  31. Pingback: » Do You Really Need All of Those Plugins?

  32. I haven’t gone through all the comments (so sorry if I repeat someone). I basically support the idea that stable and well coded plugins should not interfere with the others. Probably the updating problem stays active – if you run 60 plugins for 3+ years and you need to update regularly, the chance that a plugin is not supported anymore or have some issues in the future is growing.

    The worst problem here is the WPORG repo control. While themes pass through a “Theme Reviewer” control, plugins are like: “Please reserve me some space at your hosting, I’ll upload something in SVN and it would be up and running in 15mins”. The community needs a reviewing policy for plugins. Many plugins use hardcoded table prefixes (by default it is wp_* but have you noticed that could be changed before installation?) or other default values that are freely modifiable (not to say recommended for security reasons). Some of them grab external data via some feeds or remote services that are suspiciously reliable.

    If you go through the listings of WordPress vulnerabilities last 2 years, half of the problems (if not the majority) are the vulnerable insecure plugins. It’s not the plugins to blame that – it certainly is – but they just have the option to contribute and this contribution is malicious sometimes.

  33. Pingback: Idea: “Theme Check” for plugins | WordPress Developer

  34. Yes, quality of coding is the main issue, not quantity. But I’ve known some otherwise perfectly good plugins to conflict with one another. And the more plugins installed, the greater the chance of a conflict. That’s why I use fewer plugins than I used to.

  35. I’m so glad you wrote this post! There’s such a stigma against plugins, that many people think that adding functions to function.php is better practice than using a plugin – even though they both do essentially the same thing, and function.php bloat can also be an issue but for some reason that’s not a problem that’s really addressed.

  36. As an “amateur” working to develop a WP based site for my company and my company’s blog, the biggest issue to me is learning how to prioritize functionality in the site. Yes, Plugin A would be cool, but is it a priority…That has been the lesson I have learned, the hard way!

  37. I think this article is lacking some basic information about why so many of us tell people not to use so many plugins.

    1. DB Tables: Whether a plugin is coded well (or not) is definitely key to memory usage issues, but it’s the excessive database tables that get me. I have clients that install every plugin in god’s creation, and before you know it they have 150 database tables. Should plugins have better “uninstall” options – sure, but most don’t. We have to clean out client’s WP databases all the time.

    2. Conflicts: The community here is fairly technical, but the WordPress community at large is fairly non-technical. These people running WordPress websites (that we work with as clients every day) install a plugin from the repository without knowing if it will work or not – and sometimes if you install one with a bad enough conflict you can lockup the website (front end, back end, or both). You and I both know to just delete the plugin in FTP to get back in business, non-technical people don’t know this.

    3. Excessive Code: If you install a bunch of plugins and check your HTML code odds are you’ll have scripts loading in the header, the footer, maybe inline style code, maybe even multiple versions of jquery and other libraries loading (even on pages that don’t even use the plugin that loaded it).

    4. Security Issues: I also have clients that install and leave active (or inactive) plugins – and later get their website hacked through them. We fix hacked blogs every week because people don’t stay updated. Another commenter pointed out that people install plugins for silly things like adding google analytics code.

    You can make the argument that these are all “improperly coded plugin” issues, but then there are 8,000 plugins in the repository and probably only hundreds “coded well” – how exactly do you expect the average user to distinguish between good and bad?

  38. I’m new to WP as I’ve only been using it for about a year. As such, I have also heard many people rumbling about not using too many plugins… Problems galore because of one plugin messing up everything else and they have to reinstall their site and start over.

    Because of this, I’ve been worried about adding more plugins to my blogs. Since I don’t know how to create my own “safe” plugins (as some have suggested above), I thus don’t know what may cause one plugin to badly interact with another one.

    What I think would be great is some system that labels a plugin’s safety – for those of us who are not really tech savvy. How do you tell if a plugin is safe? Is it “up to snuff”? So far, I’ve been using the “Star” system in WP to tell at least if it’s liked, but this won’t guarantee safety.

    Of course, I suppose the main issue is no one can test every plugin against every other plugin to ensure they are compatible. I think something some “safety system” or certification would be helpful to many. Just my two cents.

  39. When I first strated using WP I read everywhere about not using large amounts of plug-ins- keep it to 10 or so. It was only until I saw the backend of a few hugely successful WP websites that I realised I’d been told a pile of gumph.

    Make sure you plug-ins are quality.

  40. I am kinda new if it is about WP but found (by just reading and doing some research) a nice tool called Debug Bar and Debug Bar Console. Activated debug option in wp-config and started to “collect” code snippets and created my “own” plugins.
    Yes it is sometimes very nasty if you find a nice snippet which doesn’t seem to work as WP wants, by doing some research for a solution problems can be solved fast.( I don’t say easy) By having 48 “plugins” now the Debug tool tells me that WP memmory usage is 29Mb, total queries 34 and total query time is 28.3ms.(our page loadtime is average <4 seconds )
    Imho it has not directly to do with the amount but as already mentioned above with the "quality" of the plugin/code.
    I "collected" those snippets and tested them on original WP theme before I switched to a theme we liked, all first in a sandbox and then launched it on our VPS.
    All future plugins/snippets will be tested here first in a sandbox before going live. Even WP updates, because talking about a pain in the *ss, WP updates can be ..but who am I, telling you all these known facts 🙂
    I have seen lots of plugins, also the so called "plugin collectors", as illustration only 1 plugin namely Adminimize (and don’t take me wrong it is probably a good one! no doubt or discussion about the quality here). Tell me, is this one plugin or a huge plugin with lots of options in it which also can be done by selected code snippets and placed in own created plugins 🙂 Seen several sites (and talked with their owners) which have “only” 6 or 7 plugins, but all alike this one. Maybe the discussion here could be also a little more specific about those “plugin collectors” if it is about “harm” or not, too many memory usage or query/pageload time.

  41. Pingback: How Many Plugins Should You Install In WordPress?

Comments are closed.