How a WordPress Site Becomes Unusable and How to Prevent It

I’m sure many of us have been there: Loading times on your site are terrible, perhaps you’re getting a few timeout errors, the admin is sluggish, and the overall experience of using your WordPress site is declining. Rapidly.

Unfortunately, small annoyances can quickly build up and  turn into financial issues. A slow website can directly affect conversions and sales on the front-end and lead to frustration and stress on the management side of things.

In this article I want to take a look at why these slow-downs happen and what you can do to prevent them. As a result, you should be able to better manage your website to ensure that it runs as efficiently as possible for as long as possible.

Why Websites Become Slow and Unusable

Throughout this article I will be talking about “slow websites” quite a bit. I want to make it clear that I am talking about slowness as a result of some kind of fault, which can be fixed, rather than conscientious efforts of speeding up websites by optimizing them.

An example will make this clear: Deleting a plugin, which loads 50 Javascript files in your website’s header would fall under the purvey of this article. Moving your images to a CDN for faster loading times would not.

So what can cause a website to become unusable? In my experience there are three basic issues we need to investigate. I’ll go through the causes first and then provide some actionable solutions in the next section:

  • Plugin overload
  • Sloppy code
  • Flawed processes

1. Plugin Overload

Having too many plugins can be the curse of an otherwise perfect website. Each plugin you use may add its own scripts and styles, considerably increasing the requests made per page load. The number of requests made is extremely important because two requests to download 100kb files will take a lot less time that 20 requests to download 5kb files.

You may also end up with duplicate functionality. If you use Easy Foundation Shortcodes you get a lot of shortcodes for using Foundation elements. However, you may already have shortcodes installed for grids and alerts. These don’t chew up too much processor time and memory, but each plugin is still loaded and initialized whether it is used or not.

…You’re now looking at 800,000 requests a day. That’s 9.3 requests a second, or two requests in the time it takes for you to blink.

The idea here is that little things can add up very quickly if your website has a generous number of visitors. If you have the absolute minimum number of plugins your website may make 20 requests per page load. If you have 100 visitors a day that would be 2,000 requests fulfilled.

If one of your articles is shared on social media you may have a day with 20,000 visitors. Suddenly you get 400,000 requests to you server, which still may be fine but imagine if you have tons of plugins, which all need to be loaded, and each makes another 20 requests. You’re now looking at 800,000 requests a day. That’s 9.3 requests a second, or two requests in the time it takes for you to blink.

2. Sloppy Code

If we would figure out the percentage of speed decreases caused by each of the issues we listed, sloppy code would win comfortably. While plugin overload is a problem, the majority of speed decreases experienced by installing lots of plugins can be boiled down to sloppy code.

Let’s put the number of requests made into perspective: If you optimize the heck out of your website you could push the loading time down to 600ms on a capable server. If you have lots of requests this may be increased by as much as 200ms, which is a whopping 33% of the base loading time. However, the base loading time is so small that the number of requests is not such a huge problem.

If you have a base loading time of 8 seconds and you apply the same logic, you are looking at an extra 2.64 seconds of loading time, which is huge. In real life the ratio isn’t so drastic but the gist of it holds up well.

The fact that your plugins load assets is not the problem, the problem is when they do this unnecessarily or wastefully. Plugins should concatenate scripts and styles where possible to reduce the number of requests.

Plugins also have a tendency to put unnecessary pressure on the database. This is especially true for products that retrieve posts based on complex criteria or add some sort of statistics to your site. All these tasks can be done efficiently but plugin authors have a tendency to do things quickly rather than thoroughly.

All the problems above increase exponentially when talking about themes. Since themes provide the forward-facing functionality of your website you may have the need to modify things in there regularly. Regular changes to code will inevitably cause the downfall of any website unless managed closely, we’ll take a look at this soon.

Multiple developers with multiple methods of working will write wildly different looking code, muddying up the theme, making it impossible for a developer to make sense of it as a whole.

The reason it causes problems is that code will become unreadable. Multiple functions may exist for the same functionality, old functions may not be removed by new developers since they may not know what they are for. Multiple developers with multiple methods of working will write wildly different looking code, muddying up the theme, making it impossible for a developer to make sense of it as a whole.

This results in patchwork of code instead of proper development. When replacing the share section in your posts, the proper way to do it would be to identify all the functions which contribute to it, remove them all and implement the new functionality. If the code is a mess it’s easier to either comment out the hook that displays it all or to remove the functions in the template. This will leave all other functions that contribute to counting the number of shares, figuring out the Twitter text, etc intact and in the code base, even though they aren’t used at all now.

3. Flawed Or Missing Processes

Let me describe a situation which may sound familiar: You have a new website based on a commercial, free or custom-made theme. Everything works perfectly but you would like custom-made share buttons.

A developer comes in and implements this for you by modifying the functions file, adding some images and modifying the single post template. It works perfectly but you would now like users to be able to log in via Facebook. Pretty easy, there’s a plugin for that!

A few months later you decide to change the logo and you want to feature a key element of it in the share buttons. In comes another developer. He removes the code from the single post template and adds his own, using fancy SVG to draw the share icons.

Even over the course of these three changes, several problems could be introduced: The share button and the login may require loading external JS from Facebook, and perhaps adding Facebook tags to the page. If done hastily all three features may add it independently, potentially loading the script three times. At best this will slow down the website, at its worst it may break your Javascript altogether. When implementing the third feature the developers may take all sorts of shortcuts. If they can’t find how it works they may just remove the relevant code from the single post template and add their own functions. This will work fine but may leave unused functions in the functions.php file. Over time this leads to mangled code that no developer would want to work with.

Flawed processes are not just relegated to the development side of your website. Admins and editors can be just as sloppy. They don’t lay out clear guidelines for formatting resulting in random headers, sometimes image alt text and titles are defined, sometimes they aren’t. Images are sometimes beautifully formatted, other times not so much. These little inconsistencies add up and in contrast to coding issues, they are much more difficult (or laborious at least) to fix.

Keeping Your Website Usable

In my opinion, preventing your site from becoming unusable comes down to strictly enforcing processes. This won’t really help you if you already have a sluggish website, so let’s look at some immediate remedies first:

Removing Unnecessary Plugins

Are you sure you’re using each and every one of your 50 plugins? Did you install BuddyPress to test it out rather than actually use it? Perhaps you have a number of admin tools such as importers, image regenerators and so on activated. Weed out these “obvious” ones first. If something isn’t being used and you’re not planning to use it in the near future, get rid of it. For admin plugins, which are needed but rarely used, consider deactivating them until they are needed.

Plugins
Do you use all of the plugins installed on your site?

What about plugins you aren’t sure of? Do you need Contact Form 7, Advanced Custom Fields, Layer Slider, etc? A good place to start is installing two plugins (I hope you appreciate the irony here): Unused Shortcodes and Shortcode Lister. Shortcode Lister will list all registered shortcodes, while Unused Shortcodes allows you to enter a shortcode to see if it is used. Track down the plugins responsible for the unused shortcodes and get rid of them.

Keep an eye out for plugins that perform the same function. I see a lot of cases where an admin installed Contact Form 7 for a contact page and then six months later needed a form for something else and, forgetting Contact Form 7 was already installed, searched and installed Ninja Forms or Visual Form Builder. These plugins use shortcodes so you can figure out where they are used with the plugins mentioned above and modify your forms to use the same plugin – delete the rest.

A third category of unnecessary plugins is spawned by unnecessary website features. Do you really need avatars to turn into hover cards. Do any of your visitors use this? Are you sure you need the homepage slider or is it just eye candy? Try and scan your site with a critical eye to find plugins you’re using that detract from the site’s usability instead of adding to it.

Optimizing the Database

If your database tables have lots of entries they may become defragmented, i.e. they operate with a lot of overhead. This can be the case for data-intensive postmeta and usermeta tables. I worked on a site recently that was suspended for using too many resources on its server. A rebuild of the whole site is coming soon but a simple optimization of the database tables allowed us to speed things up in the short term to get us through the rebuild.

To optimize your tables you will need access to your MySQL database. This can usually be accessed from your domain/host control panel. Getting access may require a username and password. Some hosts provide this information in the control panel somewhere. In other cases your developer may have created the database for you and written down the access in an email. If all else fails, try opening the wp-config.php file in your root directory. This file has database access credentials, which look something like this:

define( 'DB_USER',     'username_here' );
define( 'DB_PASSWORD', 'password_here' );

Once you gain access to the PHPMyAdmin interface you should see a list of databases on the left. Choose the one related to your website. You can find the database name in the wp-config.php file if needed. If you click on the database you should see a list of tables within on the right.

MySQL Database
The bottom of the database – click for a larger view

In the larger view the right-most column shows the overhead, while the second-last column shows the amount of content stored. Before we optimized the database for the rebuild project I’m working on, the overhead was something like 50Mb – ripe for optimization. If you have an overhead, which is a significant percentage of your stored content, I recommend you optimize your database. Select the tables to optimize using the checkboxes on the left, then select “Optimize Table” from the dropdown on the bottom.

Be aware that this may only be a temporary measure. All databases acquire overhead as time goes by but how much and how fast is a factor of code quality. The more wasteful your queries, the more temporary tables needed the quicker overhead is amassed.

Getting a Server Upgrade

If you are desperate to speed things up a server upgrade may help you out. Code issues often cause memory problems, which can be dealt with by throwing more memory at the problem. You can contact your host to ask for this but it will cost you. Most VPS hosting plans have upgrade options, so check out the prices with your current host or consider finding a new host.

While this may provide some breathing space it is the absolute worst way to solve the problem of an unusable website. It is the equivalent of using duct table to hold your car’s bumper in place. Sure, it may hold out until you get to the mechanic, and then again, it may not. In some cases a temporary option is better than nothing, just be aware that this is a crisis-aversion technique, not a solution.

Use a Caching Plugin

Again, not a solution, but a useful addition to your website nevertheless. Caching can take a load off your server by essentially storing the state of a page and serving it as static HTML. This reduces processor and memory load, which can buy you some time while working on the core issues.

WP Super Cache or W3 Total Cache are both great options.

Code Overhauls

Code overhauls can provide benefits almost instantly but are more difficult to orchestrate, especially with a muddied codebase. There are some techniques that can help. I recommend looking for slow queries first. You can do this in a couple of ways, the quickest would be to install Debug Queries, which lists all queries from the front-end and allows you to identify wasteful ones.

MySQL has a built-in slow query log but you may need to ask your host where this is, or you may even need to get it turned on.

Wasteful queries are the cause of most sluggish websites. Not only do they have an immediate speed impact, the problems are amplified over time, especially with increasing traffic. Once you’ve found where they are you can rewrite them in your code, disable the functionality or get rid of the offending plugin.

Some authors have the tendency to use the database a lot more than needed. Some plugins and themes may use multiple rows to store settings as discrete data. In most cases this isn’t needed – you can aggregate them into arrays and store them in one row.

Code overhauls are very difficult to pull off on a completely wasted site. Even though code can be taken apart into functionally independent sections the whole tends to be more than the sum of its parts. With a severely jumbled website a complete re-coding can take less time and effort and produce 200% better results.

Management Policies and Processes

I think by far the most effective solution to preventing your website from ageing is putting management policies in place which cover all aspects of the business. Standardizing everything you do leads to countless benefits, surpassing even your original goals:

  • Your business will be more transparent
  • Tasks can easily be taken over by others
  • Everyone’s understanding about the site will increase
  • Implementing new features becomes much easier
  • Backtracking is built into the system
  • Mass changes become easier
  • Security will increase
  • Website speed will stay fast

I recommend creating at least two documents, which will govern two main areas related your site:

  1. Development guidelines should dictate the method development, testing, deployment, the style of code, and so on. It serves to standardize the coding process so any developer can take over after reading the guidelines.
  2. Administration guidelines are all about how you manage the website. This can include the editing guidelines for content creation, image guidelines, SEO actions taken per post, update policies, plugin usage policies and so on.

If you have any other major processes such as advertising, sales, etc. you can create detailed guides for those as well. For any process that requires the same tasks over and over I recommend creating a step-by-step guide, describing what to do. Ideally a newcomer should be able to sit down with the guide and a computer and do what you do.

Learn Some Code

I try and stress wherever I can that learning code will make everyone’s lives so much easier. You don’t have to become a developer but knowing roughly what’s going on behind the scenes will provide you with benefits you never knew were there in the first place.

You’ll be able to choose your plugins better, you can keep a closer eye on your site’s code, communicate with developers more easily, spot potential problem points ahead of time, and much more.

Conclusion

If we take a step back and take a bird’s eye view, there really is only a single factor that contributes to websites slowing down: Human habits (not necessarily errors).

WordPress itself is fairly efficient, but plugin and theme authors introduce smaller and larger issues through negligence, the excitement to publish a product, carelessness and so on. Users then enhance this problem by throwing unnecessary plugins at their site, being inconsistent, and sometimes just being a bit lazy.

If you found that a bit offensive, take comfort in the fact that everyone does it. I preach about perfect websites with perfect guides but I don’t always follow my own advice either. Take into account the type of website you have. If it’s a small personal website then you can get away with a lot less. If you’re making thousands of dollars with your eCommerce site, paying more attention to these things will not only prevent headaches down the road but probably directly increase sales.

Do you have unused plugins activated on your site? Is your site running slow and this post has offered a lightbulb moment? Let us know your thoughts in the comments below.