Plugins and Fast WordPress Sites – It’s not the Number of Plugins, It’s the Quality

Fast WordPress Plugins

We’ve heard a lot about why the faster your site loads, the better your customer experience is, the higher your Pagerank will be, and the higher your site will convert. Today, I’m going to address one of the more crucial areas of site speed, and also dispel one of the most common myths about how to make WordPress load fast.

WordPress speed performance can be broken down into three major areas of focus:

  1. Speedy managed WordPress hosting – Investing in fast hosting like WP Engine offers is one of the simplest ways to get a big win here.

  2. Streamlined code in your theme – Googling for “free WordPress theme” is not the best way to find a well-coded theme that loads quickly.

  3. Installing only scalable plugins – This is what we’re going to dig into today. Every plugin adds a bit of complexity to your site, and it’s important to install well-developed plugins from a reputable source.

Plugins allow site owners to exert very specific control over site performance because plugins are simple to swap out and exchanged for one another. Installing and enabling is as easy as uninstalling and disabling. If one plugin is slowing your site down, you can find a faster one or remove it altogether. In general, we always want to have the fastest set of plugins possible for the features you want the plugins to add!

Dispelling A Myth

Can you have too many plugins? There is a common refrain heard in the WordPress ecosystem, spoken at Meetups and written in blog posts that you want to run as few plugins as possible because “having too many plugins will slow your site down.” This isn’t strictly wrong, but like anything that has to do with development, there’s a bit of nuance and subtlety you can dig into here.

Yes, more plugins will add more code that a browser has to load, which can slow it down. And to paint with very broad strokes, a website with a simpler codebase will usually load faster than one with a complicated one, all other things being equal. Since plugins are basically a way of adding code without having to write it yourself, telling new WordPress folks to run as few plugins as possible is great advice. It keeps people from installing 10 different Facebook plugins that all basically perform the exact same functionality.

How many plugins is too many?

I chatted with Pippin Williamson, the developer of Easy Digital Downloads, because he’s one of the active WordPress thought leaders who runs a high number of plugins, and they load quickly. PippinsPlugins.com runs 81 in total, and EasyDigitalDownloads.com runs 83.

I wanted to investigate why this was, so I chatted with Pippin to see why he was running that many plugins, and whether or not it was affecting his site. He explained to me that the trick isn’t how many plugins you have, but what operations they need to perform in order to render your site in a visitor’s browser. Most plugins are pretty simple, but some will perform complex actions that are “expensive” in terms of backend processing, and will slow a website down. In other words, you could have a quickly loading website with 80 plugins, and add a single, complicated plugin and lose half a second (or more) of loading time!

According to Pippin, there are four major areas he looks for when he evaluates adding a plugin to his website.

  1. Does it load lots of scripts, styles, or other assets?

  2. Does it add extra database queries to each page?

  3. Does it perform complex operations?

  4. Does it perform remote requests, like to external APIs?

Load a lot of scripts, styles, or other assets on pages.

Plugins are designed to add features or functionality to your site so that no matter what theme you install, the functionality of your site always stays the same. To do this, plugins can load CSS files and JavaScript libraries on every page, which is expensive for your resources. Even when loading those assets is strictly necessary, loading too many will impact site performance much more than having 20-30 simple plugins that each perform their own tasks would.

Each script is loaded with an HTTP request, which is basically a way of requesting data between a server and the browser. HTTP requests are simply how websites get the data from servers and put webpages together. Every CSS or JavaScript library, and every image requires an HTTP request. You can’t get rid of them, but you want to be efficient with them. Even now, when browsers can batch load up to 8 HTTP requests simultaneously, a webpage can generally have 15+ HTTP requests to load.

There are two ways to speed this process up. The first is to stop plugins from loading certain things altogether. Some plugins are set to load files on every pageload, even when they aren’t necessary for that page. You want to specify when the file is loaded.

The other way to speed pageload time is to load the assets either asynchronously, or even after everything else has been loaded on the page. A good example is loading Google Analytics asynchronously so that it doesn’t block other requests from loading in the process. Google Analytics is essential to your website’s SEO, but it’s also a big file, so you want to make sure it can be loaded at the same time other assets are loaded, rather than in serial, so it would hold everything up.

Plugins that add extra database queries to each page

Database queries have a large impact on performance, and plugins can make a lot of these requests if the plugin author wasn’t careful. For example, plugins that track post/page views by storing a value in the database every time a page is loaded will dramatically impact performance over time because the server has to make an additional MySQL request for that number on each page.

Now, the number of page views or comments on a post can be important to display, but it’s not a mission-critical enough to hit the database every time you load a page. In order to reduce this, you can reduce the frequency a plugin queries the database, or kill specific database requests altogether and save the processing power in addition to speeding your site up.

If a plugin is making a lot of database calls, it’s important to evaluate the importance of that plugin’s functionality and weigh it against the speed of your site. If you can find an alternate plugin that makes fewer database calls, you may consider using that one instead. A good developer will be able to help you work through questions like this.

Plugins that need to perform complex operations

Plugins that query large amounts of data and then perform an action with the data will impact performance. In general, plugins that perform overly complex operations should do them off server, and not in your WordPress hosting environment.

Good examples of this are the class of ‘Related Posts’  plugins that create FULLTEXT indexes on the “posts” table in MySQL. A FULLTEXT index is essentially a mechanism for making complex search queries against the content of posts, like “posts which contain A and B but not C or D.” It turns the MySQL database into a mini search engine, which really isn’t what MySQL was designed to be.

These queries become increasingly problematic as sites get larger and larger because the FULLTEXT index will continue to grow as well. At run time, the index will consume huge amounts of resources. Over time, the site slows to a crawl, and in extreme cases can crash the server if it runs out of threads.

Plugins that perform a lot of remote requests

This can include requests to external APIs from 3rd party services, and the like. Anything where your site needs to make an external request in order to run can impact performance.

Again, this comes down to the number of requests that have to be made by your site before a page can load. The more times you have to request data from an external API, the more times you have to wait for a response from that API.

You can have plugins that request data from external APIs (earning reports, page views, etc.), you just want to ensure that they don’t adversely affect performance by caching the requests. Caching the request will mean that the request doesn’t have to run every time you load a page, which will save you a great deal of time.

So how many plugins is too many?

Breaking this down, the number of plugins is less important than the quality of them. When you hear folks tell you, “running fewer plugins will make your site faster,” that’s not 100% true. Sometimes a single plugin can make all the difference in pageload time because it loads too many scripts, or hits the database with expensive requests.

If you think your site is loading slowly, and a plugin may be the culprit, there’s a very simple way to test this out, and you don’t have to be a hardcore developer to do it. To check for unscalable plugins, all you need to deactivate all of them from the plugin menu in the wp-admin and then load your site. If the site loads faster, you know that there was an issue with one or more plugins. Now, activate the plugins one at a time, loading the homepage every time to narrow down which plugin is causing the slowdown.

Once you’ve discovered which plugin is the culprit, it’s time to find a replacement. Ask around at your next Meetup, or in an online community to find a replacement. Of course, then you can write a blog post about what you’ve learned to share what you know. If you run into an issue, it’s very likely that someone else has run into the very same one. Your blog post will make a huge difference!

Hope this helps.

Austin

    Leave a Comment

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  1. says

    HiAustin
    I try and keep down the number of plugins but since I’m using a budget shared hosting provider I appreciate that my sites will never be fast.

    I’d love to go with you guys, especially now that you have servers in the UK, but cost prevents it.

    Maybe at some time in the future!

  2. says

    We really liked having chat window in the sidebar of our site. It made authors and readers feel a lot more connected. It had a unique power beyond what they got from comment conversations. We used Chatroll which worked pretty well. But it REALLY slowed our page loads down dramatically. It was a tough call, but in the end we decided to live without chat.

  3. says

    I run 46 on one site and I have to agree, it’s not the number it’s the quality of the coding that matters most. And I too use the P3 Plugin to track down the resource hogs.

    I don’t use any caching or performance enhancers but rather cloud hosting to eliminate many performance issues. It has taken 3 years to gather a list of essential plugins that don’t affect the overall performance. Others are Theme Specific and don’t really have an influence on performance but if they weren’t well written that might be different.

    My host has set his service up on Amazon with integrated Amazon SES email autoresponder and I host 10 sites for $29 a month total. I can host as many as I care to on the one account and love the performance. Cloud hosting is the only solution for me.

  4. says

    Very informative article Austin..and you simply debunked the myth of using too many plugins…. I would also like to add a plugin here “P3 profiler plugin”, which will let a user check, which plugin is taking maximum time to load, queries and other vital details… As this will help one to find a plugin which is taking ages to load……

  5. says

    So tru, the best thing to do is analyse page load speeds and performance and then start removing elements that arent required and optimising your site. I did it on my site, reduced the http requests by 60% and page load speed went up massively.

  6. says

    Thank you for this informative article! I have heard the common advice about plugins and certainly try to follow it. But I do run several plugins for things I can not code. It helps to know what I’m looking for (and to avoid) since I do need them, but really need to speed up site loading.

  7. says

    I just moved one of my sites to WPEnine at the end of August, went live last week.

    The process of removing plugins onthe do not use list was not easy, but I understood the reasons.

    I struggle though still with one. We had to get rid of Contextual Related Posts and replace it with the recommended Nrelate plugin that runs a process on their own server to determine what posts might or mit not be related.

    I understand the performance trade off here, but in reality I’m watching my bounce rate go up after this switch because the logic just isn’t as strong at nrelate as it is in an internal plugin that analyzes each and every post contextually. :(

    Speed is an important aspect uf the user interface, but so is recommending that next page to read (my site is an online version of a physical magazine).

    I’d challenge WPEngine to find some creative business or technical solutionfor those of us that need a more resource intensive plugin from time to time.

    On a related note, as I went through the migration, our biggest challenge and question was

    “Did we get all of our images transferred over to the new server?”

    Again WPEngine does not allow users to use the Broken Link Checker plugin. Alternatives are recommended. I tried them and they are saddly totally ineffectual and pail in comparison to the depth, accuracy, and ease of use of the Broken Link Checker plugin.

    I’d further challenge WPEngine to consider allowing migration related plugins like this at least for some initial period of time.

  8. says

    This is actually pretty horrible advise. I imagine people are now going to install dozens of plugins because of what they read here.
    My clients don’t understand 99% of what you wrote here. It’s far similar to tell them not to install too many plugins than explain all of this. Having to quality ensure every plugin the client installs is unrealistic. For a huge percent of people using WordPress, they have no idea which plugins are “quality” and which are not. While it does not take care of the solution of slow sites running bad plugins, it’s certainly easier and more affective to people that don’t understand WordPress to use LESS plugins.

    • says

      Great find Tyler, thanks for sharing, already discovered that SEO ultimate was a major resource now testing with Yoast plugin instead but still showing em results after scan for seo ultimate which is now deleted lol.
      Probably just needs to login again.
      Such a useful plugin though, great share!

  9. says

    I agree with Michael that most people running wordpress have no idea which plugins are “quality” and which are not.

    Can someone write a post on this, I mean how can we judge the plugins quality for better page load.

    Thanks.

  10. says

    I wouldn’t call it horrible advice. Clients hire us in order to translate/control and help them make proper decisions. Rules like “Don’t do X, Y or Z” with no reasons don’t allow us to make intelligent decisions. I appreciate the “whys” about things so I can be pragmatic and smart in my development decision-making.

    If your business model is to install WP, tell your client not to install too much, and set them free only to return for emergencies, then yea—perhaps you shouldn’t encourage them to read this. But if you are charging them for advice and continued development, you should be pleased that they understand why they will continue to need you.

    It would be great if web development were color-by-numbers, but it actually requires a bit more.

  11. says

    Thanks, great article. 83 plugins. WoW and the page loads in 2 secs per webpagetest.org

    I now get along fine with 7 plugins and get very near 1 sec page load times and good page speed scores.

    I notice that Calendar type plugins are resource hogs. In fact Tribe basic Events Calendar, which I use and recommend, uses like 70% of all resources used by plugins. Using the excellent pro version or adding the great community add-on just made resource management unwieldy for all the event management and other features those modules added.

    The lesson for me is to find the sweet spot of absolutely necessary functionality and best possible user experience via fastest page load times possible.

    P3 (plugin performance plugin) at

    http://halfwaytoconcord.com/wp-admin/plugin-install.php?tab=search&type=term&s=p3&plugin-search-input=Search+Plugins

    is a valuable tool to help you see what is actually going on with your plugin demands on resources.

    I manage sites at both WPEngine and Synthesis and am glad I made that investment in a serious hosting company.

    bgr

  12. says

    Thanks Austin! I was wondering if I am running too many plugins on my site. I don’t seem to have many issues other than the inevitable broken code when I update plugins.

    The article speaks of Pippin Willamson with 83 plugins so I think I’m OK with my 12. Lol

  13. says

    Hey,

    Thanks for the great post. I was trying to know how to speed up my website when I came across this.

    I guess I should start by installing the W3 Total Cache plugin.

    Thanks once again!

    Ken

    • Kirby Prickett says

      Thanks for your comment Ken!
      If you host at WP Engine you don’t need W3 Total Cache (because of our EverCache technology).
      If you don’t host with us though, W3 Total Cache is something you should consider. Another option (if you don’t host with us) is WP Clean Up, which should help you trim your database: http://wordpress.org/plugins/wp-clean-up/.
      Hope that helps!
      – Kirby

  14. says

    Great post in a time where I am dealing with this exact issue.

    I wanted to know how many queries is to many when dealing with a large mysql database?

    Also, on the part about not turing your mysql db into a big search engine, well then how do you get around that if you have a listing type site (real estate lets say) and you need people to filter thousands of listings by price, type, location, rooms, etc. All very standard queries…

    • Kirby Prickett says

      Thanks for your comment John.
      To answer your question, there is no definitive number to how many queries are too many, but the general rule of thumb is the less queries you have the better. When dealing with searching through your database, in most instances it is best practice to cache your database requests, so that the most common queries are not run often and don’t take up server resources.
      Hope that helps!
      – Kirby