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:
Optimisation: the process of making something as good or effective as possibleCambridge Dictionary
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.
Here’s the problem in a nutshell:
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.
Rule #3 – Optimise CSS All You Want
Broken CSS wont “break” your site, so optimise and auto-optimise it all day every day.
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.
- 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.
- If your host doesn’t provide the latest PHP version, migrate.
- If you’re on shared web hosting, invest in better performing, more dedicated hosting.
- 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.
- Always be prepared to switch hosts. If you’re getting poor performance, switch to another.
- 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.
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.
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!