Plugins and Fast WordPress Sites – It’s not the Number of Plugins, It’s the Quality
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:
Speedy managed WordPress hosting – Investing in fast hosting like WP Engine offers is one of the simplest ways to get a big win here.
Streamlined code in your theme – Googling for “free WordPress theme” is not the best way to find a well-coded theme that loads quickly.
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.
Does it load lots of scripts, styles, or other assets?
Does it add extra database queries to each page?
Does it perform complex operations?
Does it perform remote requests, like to external APIs?
Load a lot of scripts, styles, or other assets on pages.
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.