Modernising Wordpress

WordPress can be notoriously bad to work with, especially in cases where you have to work with a client that has an existing install of the software. Between monolithic themes that have been developed using bad practices, and the prevalence of poorly performing hosting, you can spend more time loading pages than doing your job. This was an experience of mine recently, and I've taken the liberty of outlining my process for bringing WordPress installs into the present.

You will likely need to sell your client on a lot of your proposed changes, and this should be easily enough done. What this process offers is top-notch performance, security, and price. The process has three main stages, and each one has the potential to severely impact the performance of WordPress.

Hardware, Software, or Theme

Simply put, poor hardware means poor performance. In the client case mentioned earlier, initial load times were 8-20 seconds depending on bandwidth. Of that time loading, 4-6 seconds were spent generating the initial response on the server. When you consider that over 40% of people will close a tab if it doesn't load within 3 seconds, you can see that this type of situation is dire. Your first hurdle as a developer is to find these problem points and address them appropriately.

Addressing the Hardware

Generally you will eliminate any and all hardware issues by moving away from "shared hosting" plans, these plans typically share resources between a large amount of websites. What this means is that if you're placed on a block with a large website, you get less of a share of the resources, leading to performance problems. With a VPS you don't only get top-notch hardware, but you can choose your own 'stack', and usually this means you can benefit from the latest technologies.

How to Move

Invest in a Virtual Private Server, as a developer you should be confident with being able to deploy and set up a VPS. If you choose providers such as DigitalOcean1 or Vultr you can get very competitive plans, starting at $5 a month. That's extremely cheap for the level of performance you get, it competes with even the cheapest shared plans.

Ideally, each client will have their own VPS, they're not expensive and you can spin them up effortlessly. Once you've done that you need to configure your server. There are tools available such as ServerPilot, or Docker that make this really easy even for individuals inexperienced with managing their own servers. Once you've done this, it's a simple matter of migrating your WordPress install across. A tip with ServerPilot is that you can very easily modify their basic install to include SSL.

1 - This is a referral link that will give you a free $10 on signup, click here if you aren't cool with those.

Addressing the Software

Software problems are a lot more granular than hardware problems, to address them you must ensure that your point of fault isn't at a hardware level. Once that is done and you're confident the problem is not the hardware, you can then continue to the software. As well as this, your fault could exist at one point in software, or across several points - fixing one problem might not entirely solve your performance issues.

It's also important to realize that any software problems can exist with your server-side tools, such as with your NGINX configuration - or on the WordPress install itself through the avenue of plugins.


Plugins are a point of fault for a lot of users, there is no strict guarantee with plugins for WordPress that dictates they will work well with others. I would advise installing a plugin profiler, and seeing where the most time is spent in generating your pages. In some cases you may not even be able to disable the problematic plugin in question. Prepare for that eventuality, and realize that there's no golden gun for this situation, however there are ways to reduce the impact.

Serving WordPress

If you're certain the problem isn't with a plugin alone, the best option is to go full nuclear on your software stack and re-implement it. For Wordpress in particular this isn't a problem because your content is completely separate from your stack, and you should have a backup system in place. For the problem client mentioned earlier, this was the single best thing I had done, and switching to PHP7 reduced TTFB by a factor of ten in most cases. The theme was an absolute monster and included many proprietary plugins for functionality, but PHP7 chewed through this and gave an acceptable level of performance.

On top of this, a strict caching policy for users who aren't logged in will perform miracles. A user visiting the front page of your website for the first time can have a response ready in under 50ms, compared to maybe 400ms for a non-cached page. This is a pretty huge advantage, especially if your server is coming under heavy load from an influx of visitors, as the server won't have to generate a response individually for each visitor.

My Server Configuration

The configuration I use for client sites is something of a combination of all the suggestions so far:

  • WordPress on PHP7 with MariaDB.
  • A strict caching policy.
  • A SSL and HTTP2 enabled reverse proxy.
  • Image optimization.

With this configuration you eliminate almost all concerns, you get the best security with SSL and you can provide it at no cost to yourself using LetsEncrypt. On top of this, you have caching to provide fast and low-burden responses, along with optimized images, which you can do in bulk using the CLI of your VPS, and then use a plugin to ensure future media is optimized. You also don't have to worry as much about having a poorly developed theme with no concatenated resources, because HTTP2 multiplexing deals with that issue. This configuration should offer up very competitive performance, at very little cost.

Addressing the Theme

The theme is something that may not be negotiable, you can do your best to clean it up; my advice is to not bother with concatenation and let HTTP2 multiplexing deal with that. On the other hand, you do need to consider some users may have a browser that does not support HTTP2, in that event you might wish to continue on with that.

This is my checklist to handle the majority of problems:

  • Does the theme have significantly oversized images?
  • Can I replace any images with SVGs? If yes I proceed to do so. This can save you hundreds of KB.
  • Has the client used PNGs where it's not appropriate? If so convert to JPG.
  • Are any redundant files being loaded in?

Usually this will address most performance problems, I would typically also attempt to dissuade the use of video backgrounds. If you wish to go into further detail with this, you can run a benchmark of the website using the Chrome developer tools, here's an idea of what you're looking for:

  • Huge file sizes under the network tab.
  • Scrolling performance problems, these can be profiled using the timeline.
  • Repaint issues, again profiled under the timeline.

Wrapping Up

I realize after writing this that it's less of a guide and more of a general guideline, that's fine, a lot of the tips are very solid for guaranteeing a performance level above and beyond what typical shared hosting would give. It's also a great place to start learning the basics of server management. VPS providers like DigitalOcean have a wealth of documentation available for people working stuff out, and also have a very powerful snapshot feature to ensure you can experiment without worrying about losing everything.

There is another solution that would be almost free and guarantee top percentile performance. Ask yourself if you need to be using WordPress, if the answer is no, you can always make use of static site generators and GitHub pages. Take a look at my article about building this website to get a more in depth perspective on the advantages!