5 Golden Rules For WordPress Site Optimisation

There are few things more frustrating when browsing the web than a painfully slow website.

We expect pages to load near-instantly, and when they don’t we switch off, or even sometimes forget why we went to that page in the first place.

If that’s an e-commerce site, then you’ve just lost a customer.

It is no small wonder that a whole industry has built up around the “science” of website performance, in an attempt to squeeze every millisecond out of our sites.

But there are dangers in webiste optimisation, particularly for the non-technical webmaster.

We have considerable experience in WordPress development, and we’ve fielded 1000s of questions and problems about WordPress, and errors you may encounter. Most issues arise from some sort of optimisation gone wrong. So, with all that experience, we’ve compiled 5 Golden Rules that we always adhere to that eliminate these sorts of problems.

They can help any web admin, regardless of their technical ability. There are admins who know all this already, and for them, perhaps they don’t all apply. But if you’re in any doubt as to whether or not they apply to you, then they probably apply to you and we hope they’ll help.

Let’s get started with perhaps the most important rule of them all…

Rule #1 – Apply optimisations last; Remove optimisations first;

To truly understand this rule, we must first understand the term: “optimisation”.

This word often gets thrown about without a thorough understanding of the purpose of optimisation. Taking the Cambridge dictionary definition:

There is nothing in here about changing things. It’s about improving something. The end-result should look and act in exactly the same way as before any optimisations are applied.

In the case of a website, there must only be 1 discernable difference: the page loads more quickly.

Anything else means you’ve changed the page, not optimised it.

In order to optimise a site, you need to have it working correctly, and exactly as you need it to.

This is the foundation from which any optimisations must happen – a fully working website. Trying to optimise too early will cause trouble and introduce inconsistencies as you develop and adjust the site.

So before installing any sort of optimisation plugin or using a caching tool, the website must be whole and complete.

This also applies when you make changes to a website with a plugin or theme upgrade. Upgrades always change things. This means that if you have optimisations in-place before an upgrade, they should be removed, and then reinstated only after the upgrade has been done and tested.

But often admins do upgrade plugins, and things break. It’s natural to feel that since you upgraded plugin X, and things then broke, that it is the fault of plugin X.

It might be the fault of plugin X. But if you can resolve the problem by resetting optimisations, then the fault lies in the optimisations.

And this is the 2nd-half of rule #1 – if things break, or anything goes wrong, remove all optimisations first before debugging the problem.

Regardless of the problem and no matter what is happening, if you find yourself thinking something along the lines of… “I’m doing this action, and I’m expecting a different result to what I’m seeing”, then you must begin by removing any and all optimisations/cache.

If you stick to this rule, you’ll recover a lot of time wasted on debugging.

Rule #2 – Never Auto-Optimise Javascript

A lot of folk wont like this, but if you stay well clear of tools that optimise Javascript in any automated fashion, you’ll likely eliminate practically all front-end website issues forever! Well not quite, but it just might…

Javascript can break fairly easily. And when it does, it has the capacity to break most of the rest of the Javascript on your page.

When a Javascript error occurs, there’s no way to predict what will break, or what will hobble along bravely and still display some semblence of normality.

Here’s the problem in a nutshell:

Many websites are built using off-the-shelf themes and loads of different plugins. Each of these, particuarly the themes, comes with a massive array of Javascript includes. The theme developer builds a theme and ensures that all Javascript is loaded correctly. Then you fire on a few plugins which themselves bring along more Javascript includes, and your site is loading a truck-load of scripts on every page load, which may, or may not work well together in the first place.

To top it off, you then turn-on an automatic Javascript optimisation tool that knows nothing about your particular site and what it needs to operate correctly.

Things may work, or they’ll crash and burn. The only way to know is to test everything. But do you actually test everything? Invariably most people don’t. You might load a few critical pages, and see that everything “looks fine”, so you leave it.

Then 2 weeks later you discover something is broken and instead of following rule #1, you contact the plugin author(s) and you seek help to fix a bug in their programming.

This is extremely common – we see caching/optimisation issues as the #1 source of problems on websites. And Javascript is the prime suspect every time.

There is no way that a plugin written to automatically optimise the loading of Javascript can possibly know the correct way to do this for your particular website Javascript-mix.

Yet people try to do this. Our most recent encounter was with the SG Optimizer plugin which has a Javascript Defer setting. Most non-technies believe that if there’s an option to do it, they should use it, regardless of the warnings presented when turning this on. Randomly (and it is absolutely random) defering Javascript loading can and will break your site functionality.

So the message here is clear – do not use plugins or tools that “automatically” optimise Javascript on your site. They know nothing about your site, and can’t say what is correct or what will work for it.

Also, note, we state “automatically” here. We’re not saying Javascript shouldn’t be optimised – it should be. But it should be done by the right developers in the right way.

Rule #3 – Optimise CSS All You Want

Broken CSS wont “break” your site, so optimise and auto-optimise it all day every day.

If you’re following Rule #1, optimising CSS wont pose any trouble. Sure, you might break some styles, but unlike broken Javascript, you’ll not only spot the problem more easily, it’ll not break functionality on your website in most cases.

Simple: optimise CSS as much as you want (as long as you stick to rule #1)

Rule #4 – Do not use WordPress Page Caching

Page cache is a wonderful idea, yet problematic at best for any sort of dynamic (i.e. non-static) website.

And make no mistake, WordPress websites are dynamic.

We cover the issue of WordPress Page Caching is much more detail in this article. But the simple summary is this:

If your website operates in any sort of dynamic way with custom/dynamic page content per visitor, then you can’t reliably employ Page Caching (even if you follow all the other rules).

Rule #5 – Optimise your web hosting, not your website

This is easily one of the most important of all the five rules, so much so, that it isn’t a rule, it’s plain site-building fundamentals.

Even before a webpage loads, your server and hosting play a most critical role. Hosting involves the server/VPS itself, the network that hosts the server, the software that the server runs (PHP, Apache, NGINX, MySQL). All of these are important to the final performance and come long before any page optimisations you might attempt.

Here are just a few considerations to address before using any sort of page optimisation plugin, tool, or technique.

1. Ensure your PHP version is the absolute latest, or perhaps 1 major release behind. For example, at the time of writing, PHP 7.4 has just been released, so you should be going through every website you own and ensuring they’re fit for PHP 7.4, if not, PHP 7.3.
2. If your host doesn’t provide the latest PHP version, migrate.
3. If you’re on shared web hosting, invest in better performing, more dedicated hosting.
4. Similar to shared hosting, if you’re running multiple domains under the 1 hosting account/vhost, start separating them. This has massive security implications also.
5. Always be prepared to switch hosts. If you’re getting poor performance, switch to another.
6. Use a dedicated MySQL remote database server – if you take heed of point (2.), moving to something like DigitalOcean VPSs or Rackspace etc., you can use dedicated MySQL database services which offloads this role from your website hosting server.

Of course, some of these have additional costs associated with it. I get that this might be a hinderance.

But if you feel that it’s important to spend time and effort optimising a website, then you feel that the website is actually quite important. If it’s important, then it may need the extra financial resources to get it where it needs to be.

DigitalOcean VPS cost as little as $5/month, they are blazingly fast and can host many WordPress sites with ease.

We wrote a related article that outlines what platforms and services we use to host our WordPress sites.

How To Test Your Website Speed

There are several different tools available for testing your site speed, and we’ll list a couple of them below.

It should always be understood that these are ways of trying to objectively measure your sites speed and to always remember that speed isn’t the most important factor – having a correct website that loads all the information as it should be for that visitor.

Optimising for speed is that last thing to try. Here are some of the tools you can use to tests your site speed:

• Google Page Speed Insights
• GMetrix Speed Test
• Pingdom Speed Test
• IsItWP Speed Test

WordPress Website Optimisation Conclusion

There is a lot of work involved in building a website and often times it feels like there’s just as much, if not more, in optimising it for performance.

But no matter what steps we take to improve a site’s performance, we need to ensure that the end result is still correct and functional. A slower, correct site will always be better than a fast, broken one.

Keeping these 5 rules, particularly #1 and #5, in-mind while working with our WordPress sites will reduce our time spent debugging and fixing problems that poor optimisations have caused.

And of course, there are other things we can do to better optimise our sites, and other pitfalls we can fall into. This isn’t a list of tips on how to optimise a site, but instead rules to keep us safe from breaking a site.

Note that if you “break” one of these rules and your site works. That’s great! But it doesn’t mean it’ll always work and that the rule is invalid… it just means that for your particular “plugin/theme/javascript mix”, you get away with it.

If you have any rules or dos and don’ts that you like to stick to, please do offer them below for us all to learn from your experience – we’d love to hear how you manage optimisations on this wide and varied topic.

Thanks for reading!