WordPress optimisation save yourself the hassle.
WordPress optimisation is something I’ve written quite a lot about on this blog, and I’ve been doing some experiments to try and help save you the time and effort involved with optimising your WordPress site. In this post I’ll be covering what I’ve worked out, with the objective of making your life a bit easier. Fingers crossed, eh?
Just to make mention of it, this isn’t likely to be much help if you’re looking to optimise a site that’s already been made (you’d probably want to check the optimisation category on my blog page for advice for an existing site). What I’m about to mention is for a NEW SITE as in, “if you read this before you start making your site, it will save you a lot of time and effort later on”.
If you’d like to skip the preamble and supporting explanations, you can click here to skip to the part that actually saves you the hassle of optimisation.
Optimisation, what is it?
Optimisation if generally an improvement in performance in the context of websites.
There are different types of optimisation.
One type of optimisation is what’s effectively “in WordPress”, such as debloating your site’s database, and reducing the overhead of plugins.
The other type (which is mostly what I’ve covered in the optimisation category on my blog is the optimisation of page output.
Page output is what tools that use lighthouse analyse. Examples of these tools are:
They both use lighthouse to do the same job, which is essentially to analyse how friendly your site’s page output is to browsers and to users (it’s users, using the browsers, so that make sense) or site visitors.
These tools highlight issues in your site’s page output to identify how your sites pages could be improved to make browsers render pages faster, and to make the experience of site visitors better.
If we use Google’s pagespeed insights as an example, all you’d do is run the address of your site (or a page on your site) through this tool and pagespeed will use lighthouse to analyse page output, and present a report. Hopefully, you’ll see something like this:
If you do see the 100’s and all green circles then your site is effectively already optimised, and browsers can render it quickly and visitors to your site will have a good experience. In reality, though, you’re not likely to see the above (unless you’ve read and applied what’s in this blog post from the offset!).
An example of poorly optimised page output would look something like this in pagespeed:
If you do see something like the above in pagespeed, then you need to go through the process of optimising your website to improve your page output, to make your site more friendly to browsers, and to provide a better user experience.
Therefore, optimising page output is the process of improving page output to make your site friendlier to browsers, and to site visitors.
What is browser rendering?
I guess I’d better explain what browser rendering is seeing as I’ve mentioned it a couple of times above.
I’ve written a post that explains browser rendering in more depth if you’re interested, but a quick explanation is as follows.
Browser rendering is the process a web browser undertakes to turn page output in to the web page you see and interact with. There, that wasn’t to bad was it?… oh… wait. It’s not quite as straight forward as that.
If you visit a web page, then right click on it and then click on “view page source” (if you’re using Google Chrome, it might be a bit different in other browsers), the page output of the page will then be displayed. It’s this that the browser turns in to the page that you see.
But how does it do that? And where does all that come from?
Let’s, for example, say you’ve made a site using WordPress. When someone requests a page on your site, your WordPress installation, as a whole, executes, interacts with the sites database, the two combine, and generate page output. This gets passed back to the browser (via the web server).
So WordPress, and what you have installed in it, and what you have as page content stored in the site’s database… that’s where the page output comes from.
The page output that’s generated contains:
- HTML (hypertext markup language)
- CSS (cascading style sheet)
- JS (Javascript)
The browser uses these three things to display a page. It might help to think of the way that it does this in three steps.
First of all, the HTML is used to generate a “document object map” (DOM). This is the HTML that’s used for layout and some formatting. A web page made using just HTML (with no CSS or Javascript) would look quite “late 1990’s”, fonts would be times new roman, and it would look like it’s been drawn with a pencil and a ruler.
Then, the CSS is used to create the “cascading style sheet object model” (CSSOM). The CSSOM is then applied to the DOM to provide colours for certain portions of the page, fonts, and styling information. When the CSSOM is applied to the DOM, the page (at this point) looks more colourful, has some nice swanky fonts (not times new roman), and the layout is improved. No more pencil and ruler, more like a poster.
Then, the JS is downloaded, evaluated, and executed by the browser. This is used to manipulate the page to make it “do things that move”. That’s nice and vague isn’t it? Let’s put this in a bit of context. If you’ve got a page with drop down menus on it, they move. That’s Javascript doing that. If you view the page on a phone, the page is automatically resized to appear in a friendly way on the phone’s screen. That’s Javascript doing that too. If there’s any animation (image carousels, graphics that slide in from the side or things that change when you put your mouse over them), that’s Javascript doing that as well.
Although I’ve described this as a three step process, there can be some parts of each step happening at the same time, some parts waiting for other parts to do things, and there can also be a lot of unused aspects of things like Javascript and CSS.
If just the words “unused” and “Javascript” in the same sentence made your heart sink, you’ll probably know where I’m going with this. Let’s say your site has a JS file, but only part of this is actually used to display a page, that’s unused Javascript (one of the things that pagespeed flags as a problem).
If the browser is having to wait for CSS to download to be able to render the page, that’s a render blocking resource (another thing that pagespeed flags as a problem).
These problems that pagespeed flags, aren’t a good thing because (for example):
- The page output being generated causes a delay causes a delay in rendering.
- The page output contains code that isn’t used, but still has to be downloaded and evaluated (so the browser is effectively tasked with doing something it doesn’t need to).
- The page being rendered bit by bit can cause elements on the page to move around while the page loads (layout shift).
These are just examples, and are some of many things that can make your page not that great for browsers. Anyway, I hope you get the picture.
Is this page output business really a problem?
I wouldn’t blame you for thinking “this sounds like facetious nerd business!” at this point. Maybe even wondering if this is worth even sorting out. I mean, why would you take the time and effort to sort this out if people can just “wait a bit” and get served my site’s pages.
Well, yes… and no.
Google do take performance in to account when ranking pages in search results. To what degree, I’m not completely sure, but a poorly performing site can have a negative effect on page ranking.
True story coming up.
I work in web hosting. I answer the phone as part of my job. When I first started getting in to this WordPress business, I started pimping myself out to customers in an “extra pair of hands” kind of way (hey, I’m cheap they’re busy).
One day I took a call from a customer who had a site that, for some reason, had gone from ranking well in Google search results, to pretty much completely dropping off Google search results. Neither of us knew for sure why that was, but one thing that was very obvious was that pages loaded slowly, and the performance metric in page speed was shocking. I offered to optimise the site (at a reasonable cost) to see if that would help. The customer took me up on the offer, I did my thing, pages loaded quickly, the performance metric was good, the site started to rank well again.
I had a similar thing happen with this site. An update to the caching plugin I was using at the time, somehow managed to turn my site (yes, this one you’re looking at) in to a morphine sedated tortoise.
I’ll be honest, I don’t live and breath this site, so I’m not keeping an eye on it all the time, but I do regularly check things like Google Search Console, and Google Analytics, and that was where I noticed the problem… like no impressions (not showing up in search results) and no visitors kind of problem.
I took a look and my site, and that was when I noticed it’s tortoise on morphine like performance. If I disabled the caching plugin it ran quicker (ironically), so I ended up just switching to another caching plugin, and things started to go back to normal, both for page loading times, and for impressions and visitors.
So there’s two examples right there that do appear to make a difference.
Then again, I’ve seen sites made by creative design agencies that run like dogs, but rank OK, but who knows what they’re doing in addition to the site’s performance for that to be the case. Voodoo? Paid adverts? Praying? Fake Google SEO fodder? Who knows.
Approximate optimisation for existing sites.
As I’ve already mentioned, this post isn’t much help for optimising an existing site.
That said, I do have to provide some information about optimising an existing site to give some context. So here goes.
Optimising an existing site usually consists of:
- Uninstalling things you don’t need (plugins).
- Loading your google fonts locally (if you’re using them).
- Switching your images to next gen formats.
- Removing bloat (code in page output that doesn’t need to be there).
- Reducing your DOM size (that would be reformatting pages, then).
- Shuffling CSS around to make it more appropriate to browsers.
- Adding directives such as defer or async to scripts to make them be loaded in a more appropriate manner.
- Unloading all the JS and CSS that isn’t used but that’s been inserted all over the place by plugins, themes and page builders.
What you’re doing when carrying out the above, is effectively undoing a load of things that either don’t really need to be done (or be there in your page output), or could have been avoided by working in a specific manner in the first place. The latter is really the purpose of this post.
I’m not having a go here (honest!), and I can totally see how the above comes about. I mean it’s not like you install a contact form plugin and it comes up with a warning saying “this plugin will put it’s JS on all your site pages because we don’t know which page you’ll use it on, you’ll have to unload all that later, good luck” now is it? You only really find out what’s going to happen by doing things in WordPress, and my hope of writing this post is that I can save you a lot of time and effort by you not doing the “things” that result in the need to optimise in the first place.
Both optimisation and caching are generally used to make something that’s not desirable better. Now imagine that it was just “better” from the offset. This would eliminate the need to optimise your site, or use caching plugins. OK, maybe that’s a bit of an overstatement but think of it like this:
It’s better to not have aspects that need optimising in the first place. The same applies to caching; if your page output is (for example) full of bloat, although a caching plugin may help to a degree, using a caching plugin will result in bloat being cached. The caching plugin will be more effective if bloat is removed first, then caching applied (as the caching plugin isn’t then caching bloat). Roughly the same applies to optimisation. If you work in a certain way using certain plugins and themes, the amount of optimisation required is minimised.
You wouldn’t necessarily know how things are going to pan out, and therefore how much optimisation you’ll need to do until you’ve created your site. Consequently it’s a bit of a chicken and egg situation. The purpose of this post is to help you avoid doing things that will result in you having to undertake a lot of optimisation. So here goes…
WordPress optimisation save yourself the hassle.
Key concepts:
- Use a fast theme.
- Don’t use a page builder that bloats your site with unused CSS and Javascript.
- Control as much as you can, rather than relying on plugins and themes doing things for you. That’s right, I’m talking about using a child theme, so that you can control the site’s CSS. You’ll need to pick up a bit of CSS (sorry).
- Identify the functionality of the site that you require first, don’t make it up as you go along.
- Keep things as minimal as you can, both internally (plugin sets for example) and externally (think twice before adding animations, for example).
- If you can achieve as much as you can without a plugin (even if it’s a bit more effort). Optimising images using an image editor before uploading them would be an example of this.
Some of the above you’ll have read and thought something like “that makes sense”, some of it you might have read and thought “but I don’t know how!”, and some, such as the “fast theme” and the “don’t use a bloaty page builder” you might well think “but how would I know!?”. So let’s move on to the theme and page builder aspect.
Fast theme and efficient page builder.
I’m going to cut straight to the chase with this one. The best combination I’ve found are:
Theme: Astra
Page builder: Spectra
I’ll hold my hands up to not having entirely found this out myself, although I did have to do a few experiments and try a couple of things out to come to this conclusion.
The more sharp eyed of you will have probably noticed this site has mostly been made using Elementor. Hypocritical, I know, I just haven’t got round to doing anything about this yet. Now I like Elementor as far as creating page content goes. The free version provides plenty to build an adequate site, and it will do most things you want it to. Some people I know use Elementor pro to do the whole shebang, including the theme.
Whilst Elementor is good for making page content, I’d been reading more and more on the internet about Elementor bloating page output with code that doesn’t need to be there. Also, using the free Elementor is highly likely to result in pagespeed complaining about “ensure text remains visible during webfont load”, and all that’s needed to fix this is font-display: swap; being added to a file, which I’ve covered in this post. Why Elementor and Fontawesome couldn’t have just done that by default is beyond me, and I’ll admit when I worked that out, I did start to think “is Elementor all it’s cracked up to be?”.
There has recently been a major update to Elementor, so they might have addressed a lot of the negative noise about it (including my own), but it concerns me that the noise has to be made for some action to be taken. Does it work? Yes. Does it work well? Only if everyone makes a fuss.
Anyway, enough about that kind of thing…
I was put on to Astra by a design agency. As not all designers are page output orientated I didn’t think much of this to start with, then I gave it a try and I was pleasantly surprised. One of the more horrific parts of getting a site together is the customising a theme part. I think I’ve had more urges to throw computers out of windows when customising themes, than under any other circumstances. I have to say, Astra makes that a walk in the park compared to a lot of other themes. So that was nice.
It was actually installing the Astra theme that suggested using Spectra as the page builder. I must admit, when I read “Spectra enhances the WordPress blocks editor” I did think that it might not be much fun getting used to using that, but it hasn’t been too bad. OK, there isn’t any drag and drop, OK, you have to work it out a bit, OK you can find yourself working around what it does, but the results of having that overhead are worth the effort.
Those things that Elementor makes easy do come at a cost, and that cost takes quite a lot of effort to sort out further down the line. It’s one thing to become amazing at playing the guitar by making a pact with the Devil at a crossroads at midnight, but it’s another thing living with that in the ling run (not that I think Elementor are the Devil, just to be clear, but I hope you take the point). Blocks with Spectra? Try it, you might like it… you’ll like the performance metric in pagespeed!
Child Theme.
Did I just hear you sigh? Don’t worry, I used to do that as well whenever I heard “child theme”.
The I researched it and wrote this post about creating a child theme, and found that it wasn’t all that bad. I actually use Astra as the parent theme in that post, so you can follow that like for like if you do decide to use Astra as the theme. If you can’t be bothered with all the coding part, you can download a zip of the child theme I made here.
After downloading that file, you can use these instructions to install the downloaded child theme.
The child theme I’ve made is ULTRA basic, and you might want to do something like download your own font files, then adjust the styles.css to bring them in to effect.
The reason installing a child theme helps, is because it allows you to control your site’s CSS without hacking it (modifying the existing theme). The reason this is a good practice is because even if the parent theme updates, changes you’ve made to your. child theme won’t be lost.
The downside of using a child theme, is that to be able to get the most benefit from operating in this manner you’ll need to learn a bit of CSS. CSS isn’t that tricky to get your head around, and there are tutorials covering how to use CSS available.
After installing the child theme, set all font options to “inherit” in the theme customisation options, and you’re now in control of the CSS, albeit at file level and by actually writing CSS.
The advantage that using a child theme provides in this context is that you can keep things very minimal and light. You’ll be operating in a “just use my skinny customisation” manner, rather than a “hey, let’s call fonts externally with an associated overhead and subsequent optimisation effort” manner (for example).
Identify site functionality, use a plugin set to match.
It’s VERY easy to get carried away with installing plugins.
When optimising a site, you’ll probably have to do things like install a plugin to unload JS or CSS that isn’t required that a different plugin has bought in to effect.
The other thing to bear in mind with plugins, is that they make up part of the WordPress installation that is your site, and the WordPress installation executes as a whole.
If you do end up using a lot of plugins, you increase the code base of your site (so more code is executed when your site is visited) and you’re more likely to inadvertently bring code you don’t need in to effect just by using a lot of plugins.
This site uses 16 plugins. 4 of them (so 25%) are optimisation and performance specific. Had I read this post before I made this site, I’d most likely only have 12 plugins, possibly even less if I’d thought “can I do that without using a plugin”.
Now, there are some plugins you’ll need, just because you’re using WordPress, which are:
- A security plugin. My preferred security plugin is Solid Security.
- An updates manager plugin. My preferred updates manager plugin is Easy Updates Manager.
You’ll need these just to keep your site secure. Updates often patch against vulnerabilities, hence an updates manager plugin being required. You could manually update and not use the updates plugin, but let me ask you this:
Do you ever go on holiday?
Oh, you do? Are you going to check for WordPress updates every day that you’re on holiday?
I went in to hospital once (out of the blue), got put in an induced coma for 10 days, couldn’t speak, walk, move or even breath unaided when I woke up, and eventually got home 6 months later. What I thought when I woke up out of the coma was, “lucky I installed that updates manager”. I’m joking… about the updates manager bit, the rest is true.
You’ll probably also want (because you would like the website to be found in search results… I guess):
- An SEO Plugin. I used to use Yoast, but I switched to Rank Math because Yoast wouldn’t do something (I have subsequently heard “Yoast makes it slow” noises from people).
And also, because everyone wants one (and you’ll get spammed if you put mailto links and email addresses on sites):
- A contact form plugin. I like Contact form 7, although you might find you need to unload its JS on pages that don’t contain a contact form. Remember to integrate a captcha!
And to improve the email deliverability of the contact form emails, you’ll probably need:
- An SMTP plugin.
And (although I’ve already mentioned it):
So that’s a total of 6 plugins. That’s all you’ll need for a fairly basic site with a contact form.
Obviously, if you want additional functionality, you might need additional plugins. The above covers the “what people usually want for a site as the minimum”, but choose wisely, research your plugins, read the reviews, and KEY POINT HERE, don’t use plugins that haven’t been updated for long periods of time. They’re probably no longer being updated and maintained.
Keep things as minimal as you can.
What I’ve mentioned above about the plugins is quite minimal, but that’s just the plugin side of things.
You’ve also got what’s on pages and what’s in the database. Did you know post revisions are kept in the database? As in, historical edits? Well, they do. There are also things called ‘transients” that get stored in the database, these are variable pieces of information that are either in use for a short period of time, or information that part of your site has generated that might need to be referred back to later. The bigger your database gets, the more overhead it has (in plain english; a big database can result in slower page load times).
A good plugin for removing this bloat from the database is WP Optimize. You’ll probably want to take a backup before doing what I’m about to mention (just in case anything goes wrong). You can used the WP Optimize plugin to clean up transients and post revisions in the database by:
- Installing WP OPtimize
- Activating WP Optimize
- Clicking on: WP Optimize > Database > Run all selected optimisations
- Then uninstall WP Optimize (plugins, deactivate, delete)
That’s the database cleaned up!
This next part is probably going to be a bit of a balance. Page content.
I can see how people keep adding things to pages to make them “look good”, but bear in mind, if those things move, that’s extra Javascript, and if all of that Javascript library isn’t being called, that’s unused Javascript, which pagespeed is going to complain about.
So you’ve got a bot of a balance here, especially if you’re making the page for someone that’s paying you to do so.
The balance is essentially “nice code/page output” against “something someone will pay you money for”. People expect a bit of “swishy” for their buck, but too much swishy, and too any HTML elements, and that’s you stuck with a big DOM and a bunch of unused Javascript.
If I could offer a bit of advice in this capacity it would be to spread your content. It’s better to have a higher number of smaller pages (to reduce the chance of a big DOM), and it’s better to only really animate what you need to. Do you need to mouse-over-animate all the buttons AND an image carousel? Could you just animate an image carousel? Do people really click on the carousels? Apparently only about 1% of site visitors actually click on image carousels! Maybe you don’t need a carousel at all… then again, maybe the customer expects one. See what I mean about balance?
Do as much as you can without a plugin.
There’s a plugin for this, there’s a plugin for that. I’m surprised there’s not a plugin that takes your dog for a walk. They all add up, and they can all add to page output.
The child theme method above eliminates the need to use google fonts, which in turn eliminates the need to use a plugin to to load google fonts locally.
Using an image editor (such as Photoshop or GIMP – the latter is free) to make webp images before uploading them eliminates the need to use a plugin to make images load in next gen formats.
I could go on, but you’re probably getting the picture by now. Here are some other things you can do really easily without a plugin:
OK, sure, this might sound like a hassle, but ask yourself this:
What’s more hassle? You doing things a plugin could do, or optimising your site?
Personally, if I had to weigh one against the other the optimising is more hassle AND it’s more technical. So not only is it more net work to go down the “do it with a plugin” route, it might make your brain hurt sorting out the optimisation afterwards. For example:
Yes, it is going to mean more up front work, and it is going to involve learning some things or getting your head around some things, but (and trust me on this), if you’re not massively nerdily inclined, it’s actually less work to do it without a plugin, than it is to clean up all the bloat that installing loads of plugins is likely to create.
Bear in mind…
Although there are some very well written plugins out there, there are also some not so very well written plugins out there, and you don’t know which is which. You also don’t know if that particular plugin is going to do something like add code to all your sites pages.
Using plugins is a bit like playing russian roulette. Sure, you might end up with a nice lean, well performing site, but then again, you might get shot in the head poor pagepseed performance metrics, which may well negatively affect page output.
The more plugins you use, the more code bases you integrate with your site. The more you do this, the more likely you are to have to optimise your site. The more plugins you use, the more updates get applied, and the more chance there is of one of these accidentally borking your site. There’s also an increased risk of plugin conflicts with higher numbers of plugins.
Does it work in practice?
Let me take you back to the pagespeed graphic I used right at the beginning of this article:
This was a screen shot taken of pagespeed results for a site I was recently making.
I used the methodology covered in this post to make that site. This site hasn’t had any optimisation work done on it. There is no caching plugin. And look! 100’s all round!
OK, so I did have to try out a lot of themes and page builders, and sure, I had to bring GZip compression and a caching policy in to effect manually by editing the site’s .htaccess file, but that was all.
I’ll admit I was surprised myself, so surprised that I had to write it all down. Thanks for reading!