WordPress Optimisation Overview

WordPress optimisation overview. In this post I’ll be talking about optimising wordpress, giving an overview of what optimising WordPress is, the skills that you’ll need to be able to do this, and some common concepts when it comes to WordPress optimisation.

I’m not going to be going into specific detail in this post as there’s too much to cover (I’ll be adding posts covering individual aspects of WordPress optimisation over time) as there’s a vary wide variety of steps that you might need to take due to WordPress being a very variable environment.

This is more of an overview, giving you an idea of what WordPress optimisation is, what you’ll need to know to be able to do it, and some very generalised advice.

If youd rather not have to undertake much optimisation, considering what you use to make your site is advantageous. You can find out more about this in this post about saving yourself the hassle of WordPress optimisation.

What is wordpress optimisation?

WordPress optimisation generally consists of undertaking a variety of actions to improve the performance of your WordPress based site. That said, it’s not just a case of improving how quickly the site functions or loads, it’s also a case of improving the page output that your WordPress generates so that browsers can render your site’s pages in a lower amount of time. WordPress optimisation generally consists of optimising your page content, optimising what the browser will have to deal with (based on your page output) and optimising how the serving of your site takes place. All of these things contribute to successfully carrying out WordPress optimisation.

There isn’t one action or one specific set of actions that you can undertake when improving your site’s performance or page output. You might well ask why this is, as after all, it’s all WordPress isn’t it? Well, you’re not wrong, but WordPress is a VERY variable environment. It’s not like all WordPress sites use the same theme and plugin set now is it? You have to consider that the codebase that makes up a WordPress site has come from a variety of developers. If you’ve got one theme and twelve plugins you could potentially have fourteen different parties contributing to the codebase of your site. It’s due to this that there’s not a WordPress optimisation guide that tells you exactly what you’ll need to do. Optimising WordPress is a combined total of many actions and those actions are dictated by what you’re running in your WordPress, how the individual components work, and your page content.

For this to make sense I’m going to have to rewind a bit.

Why use wordpress?

WordPress is a content management system. We use WordPress because either we can’t code, or we can, but we don’t have the time or inclination to code our own site in entirety.

Content management systems, generally speaking, provide a management interface that allow us to focus on creating the aspects that are specific to what we want to be on our site, such as page content, and its visual appearance.

What visitors see when they visit the site is a product of what you’ve carried out in your WordPress installation, but it’s not this alone.

When someone visits your site, a page is requested. All the PHP contained in your site’s files (WordPress core, the theme, and all the plugins) then executes, interracts with the database (which is where the things that you’ve done are held), and between them they generate page output. This output is sent to the browser, which renders the HTML, JS and CSS that wordpress has provided as page output in to a page that a vistor sees.

WordPress (and other CMS’) operate in this manner to effectively generate page output for you, without you having to write code. This effectively means that the code, and therefore a lot of page output is effectively done for you.

Optimising WordPress sites, more often than not, consists of working around, or modifiying the part that’s been done for you to improve how your site performs, and to improve it’s page output so that browsers can render pages in less time, or with less processing required by the browser.

I have to modify something other people have done? What? Why?!

Yes, you did read that right. You do have to modify things that the “done for you” parts do, to optimise WordPress.

Let’s use a real world example to illustrate this.

You install a contact form plugin, and you make a contact form on ONE page of your site. All goes well, but then you check your home page in https://pagespeed.web.dev/ and you see your sites performance score drop, due to some unused javascript. You look at the javascript file being complained about, and it’s to do with the contact form.

But… there’s no contact form on my homepage! That can’t be right?

Then you check the page source code of your home page and sure enough, there it is… but why?

I can’t really say for sure, other than it’s due to how the contact form plugin has been coded. It could be because whoever coded that plugin didn’t know which page you’d put it on, to maybe the coded the plugin to put that code on all pages just in case. Who knows? Actually, who cares, it’s there, and you’re getting marked down for it.

So now you’re faced with one of these options:

Leaving things as they are and accepting the situation.
Using a different contact form plugin (which may or may not do the same thing).
Coding your own contact form plugin that doesn’t do this.
Working out how to remove that javascript from pages that don’t have contact forms on them.
Working out how to only allow the javascript on the page with the contact form.

The thing is, this one aspect of potentially many things like this that you’ll have to do to optimise your site. It’s due to this that a very general, yet effective approach is to keep things as minimal as you can when it comes to functionality or “what’s done for you”.

I’ve also mentioned a few things that might have come as an “oh, do I need to be able to do that?” such as looking at your page’s source code. So it might make sense for me to cover the things you’ll need to be able to do to be able to optimise your site.

Skills needed for WordPress site optimisation.

Bravery. You’re going to need stacks of this. You’re also going to need to be inquisative, have a sense of logic, be determined and have a lot of time on your hands. You’re also going to need to be able to validate your thinking (be able to prove what you think is happening, not just guess). You’ll need to be willing to experiment, and try things. You’ll need to be able to understand and use the tools you have available to you to look at what your site is doing (such as Google Chrome’s developer tools in the browser). You’ll also probably need to be a bit “computery”.

Now that we’ve got the personality traits out of the way, these are what you’ll actually need:

You’ll need to be able to read and understand HTML (page output).
You’ll need to be able to use the tools in your hosting (using PHPMyAdmin to index tables in databases for example).
You’ll need to know to clone your site on to a different address so that you can experiment without affecting the live site.
You’ll need to be able to understand how to check the hosting environment to see what’s available for you to use (this comes in handy with caching plugins).
You’ll need to be able to understand what’s reported as problematic in analysis tools.
You’ll need to be able to use, understand and interpret tools available in your browser (such as Google Chrome’s developer tools).
You’ll need to be able to navigate around your site’s file structure.
You may need to be able to manually edit some of your site’s files.
You’ll need the ability to learn as you go, which will mostly involve reading a lot, then working out how to apply what you’ve read.

At this point you’re probably thinking along the lines of “but I used WordPress so that I didn’t have to do all that”. Which brings me to…

The WordPress conundrum.

People use WordPress to manage their content without the need to code, or analayse page output. Then they need to be able to read page output to be able to workaround undesirable aspects of their site’s codebase, that they didn’t write, to make it perform in a manner that’s acceptable to the likes of Google! You use something so you don’t have to do something else, only to find that you do actually have to do something else, or at least part of something else.

It’s a paradox! It’s like the bit in Planet of the Apes when the main character (who’s been trying to escape the Planet of the Apes and get back to Earth) finds the ruined Satue of Liberty on the beach, and realises that he is actually on Earth and that it’s somehow become the monkey planet he’s been trying to escape from. That’s me, on the beach screaming “NOOOOOOO!” while https://pagespeed.web.dev/ displays a bunch of red circles under my site’s address… except I’m not alone (and there’s no monkeys). There’s loads of people with me, and all their laptops have the red circles of doom under them as well. Well, that was me once, and I daresay I’ll be back there again at some point.

What an undesirable situation. At this point you might wonder if it really matters, which brings me to…

Does it really matter?

Does it really matter what Google thinks of your site? Well, there was a time when things like page performance didn’t matter, and, come to think of it, there was a time when the internet existed without Google. We are talking about the late 1990s though, and a lot didn’t matter back then, like the amount of trees cut down so people could read newspapers, trainers so big that migrants could use them as boats to cross the channel or spending 45 minutes trawling through irrelevant search engine results to find drivers for a dial up modem.

If you’re making a website that consists of pictures of cats in top hats that only your friends are going to look at, and they don’t mind waiting “a bit” for your pages to load, it probably doesn’t matter.

If you’re making a site for a business and you want to both be found, and give a good impression of your company, then it probably does matter. Unless your company is called something like “the slow loading website co.”.

Seriously though, is your site’s page rank in google affected by the site’s performance? Apparently it has since about 2010.

Google helped us save the “45 minutes of trawling through search results” by giving very relevant results in searches, but this came at a cost. If you want your site to be found in those search results, this in turn dictates the need to conform to what Google thinks is good as far as websites go.

Although site performance is one factor when it comes to how much Google like your site, it’s one of many aspects that Google use to establish where your site is listed in search results. Other aspects include following best practices (such as using security headers), accessibility (such as contrasting text and background colours and listing your heading tags in sequential order), following basic SEO practices (such as putting alt tags on all your images and using <title> tags). All of what I’ve just mentioned contribute to WordPress optimisation.

One aspect with many other aspects within. Like an insane set of space-time bending Russian dolls. Most of what I’ve mentioned above isn’t enormously difficult to sort out compared to WordPress optimisation. There is SOME good news, honest.

Can’t I just ask my hosting provider to do something?

The good news is that you can ask your hosting provider to do something that might (note the use of the word “might”) help. What you’d ask them to do is to generate an invoice for an upgrade, as they don’t generally have an “increase website speed” dial that they can simply turn up for you.

What an upgrade will get you is more RAM and more CPU availability. This will provide you with more of these resources to run your site. It’s a little bit like buying a better computer to run a game that’s jittery and slow on your old computer, except in the context of hosting and site, instead of computer and game.

Do be a bit careful about this though. Getting more RAM and CPU won’t always speed things up. If your site isn’t causing RAM and/or CPU to become maxed out, then upgrading isn’t likely to have the effect you’d hoped for so could be a waste of money.

There are other resources as well as RAM and CPU, such as the number of scripts that can be run at the same time, so it’s not all about the RAM and the CPU.

The key point here is that upgrading will only have a positive effect if your site is causing hosting limits to be reached.

There’s often some kind of “resource usage” facility in hosting accounts that can be used to check to see if your site is reaching any hosting limits. If none of these are being reached, then upgrading isn’t like to make any difference.

The other thing to bear in mind is also that if your site is slow because browsers take a long time to render the page output, upgrading isn’t likely to make any difference either. The same applies to things like bottlenecks in code, or having a huge database table and code running things like wild card selects on the big table (find everything like this in this huge thing). Upgrading only goes so far if at anywhere at all.

If you’ve been running your site through https://pagespeed.web.dev/ and seeing audits fail (red circles) and are thinking of upgrading to address this, being completely blunt, it probably won’t make any difference. This is because https://pagespeed.web.dev/ isn’t reporting on how quick your site is, it’s reporting on (in the majority) how quickly your site’s page’s code can be rendered by browsers. Whilst this does sound like splitting hairs, bear in mind that how quickly a browser can render your site’s pages is dictated by your page output (which is generated by your WordPress), not by the power or resource set of the underlying hosting.

Let me put it to you like this:

If your site’s page output is full of render blocking resources, unused Javascript, the images aren’t in next generation formats (such as webp), your site will still fail audits in https://pagespeed.web.dev/ regardless of the platform it’s running on.

Your hosting provider isn’t likely to analyse what you’ve done and tell you exactly what you need to do when it comes to WordPress optimisation (because you control what’s going on in your WordPress, and therefore the page output it generates). They provide a place where a site can be operated, but they don’t control the operation of the site itself, you do that part. Expecting a hosting provider to provide specific guidance when it comes to WordPress optimisation is a bit like asking someone on the checkout in the supermarket if you could have improved how your life turned out. Whilst they may be able to provide you with good general advice, they won’t be able to tell you exactly what to click on or which setting to change, simply because they haven’t had any visibility of all the clicks and setting changes you’ve done so far.

The last thing to bear in mind with upgrading is “what are you going to upgrade to”. If, for example’s sake, you’ve made a really resource intensive site, and it’s getting a lot of traffic you could potentially find yourself in a cycle of upgrading until you upgrade to something that provides a great enough resource set to cover your site’s overhead.

Which brings me to…

Identify the cause to be able to address the issue.

This sounds like a very obvious statement to make. Nonetheless, I’ll make it. Why? To save you time.

Taking a randomised, shotgun, “I’ll just try all these things!” approach is likely to make the situation worse rather than better when it comes to WordPress optimisation. There’s not set list of WordPress optimisation actions you can undertake, you’ll have to work out what the actions are that you need to undertake to optimise WordPress.

Carefully working out what it is that’s the problem, and what’s causing that, is a lot more likely to result in the problem being addressed compared to the “try everything” approach. Also, the “try everything” approach will often involve adding more things to your site, and these things tend to have an overhead associated with them.

General WordPress optimisation advice.

I read this funny (well I found it funny) website about… er… websites, that was a modernised critique of website development, written in a style fit for the modern era. Before you click the link, I should forrewarn you that there’s a lot of swearing on this website, so if you’re offended by that it’s probably best not to click the link.

You can see what I’m referring to here.

The guy that wrote that is a full on, code-my-own-stuff developer. So whilst it is satyrical you do get an idea of things that are tempting to do that can have a negative impact on page performance. OK, nobody really wants a site that’s only times new roman text with no images, but some of the points made are valid.

There also seems to be (at the time of writing) a general acceptance of more minimal sites by Google. A page with a static picture header with relevant text on the page is more well received by google than a page with generic text, loads of sliders, carousels, spinning things next to menu items, and contact forms everywhere.

Don’t get me wrong, I can completely appreciate that if you’re making sites for customers they like to see what looks like tangible effort, rather than a minimal site, but cramming a page full of swishy things to validate that effort might keep your customer initially happy, but will it in the longer term if they aren’t getting many visitors?

Simple straight forward guidance of things to try and adhere to BEFORE you start optimising your site (this will save you less work in the longer term are):

Don’t go nuts with loads of plugins, every plugin has an overhead remember?
After installing your theme, run your site through a tool like https://pagespeed.web.dev/ and if it’s already reporting problems, you might consider using a different theme.
Do as much as you can locally. External calls have an additional DNS overhead. If you do want to use a CDN use something like cloudflare rather than an “enable CDN” type option in a plugin.
Load google fonts locally if you’re using them.
Install a plugin that converts images to webp or, even better AVIF on upload, or even better only upload webp or AVIF images, and don’t install a converter plugin.
Minimise “things that move” such as animations and carousels, these rely on javascript, so more scripts, more overhead and so on.
Use a caching plugin. WP Fastest Cache is simple and effective. W3 Total Cache does a lot more, the config is heavy and it does rely on some underlying things like object caches but if used in the right way can be a winner.
Avoid calling page elements from external sources, such as iframes for google maps or reviews (these load content including js from external sources but the browser still has to render these). If you REALLY want these have them on one page, don’t do things like put them in the footer (as this is displayed on all pages). It’s better to have one page with a high overhead than it is to have all pages with a high overhead.

If you’ve already made a site and are looking to optimise it:

Look at your homepage source code. If this is thousands of lines long, you might consider a rebuild.
Minimise your site’s plugin set. Remove any you don’t really need.
Don’t start installing plugins thinking “this might nail it!”. You’re likely to make things worse.
When analysing/debloating turn off your caching plugins to see the full picture, then use optimise/address issues, then turn caching plugins back on once you have. It’s harder to work out where the issues lie with caching plugins turned on. It’s also better to not cache problematic elements in the first place.
Use tools like https://pagespeed.web.dev/ to identify what the “room for improvement” is, work out what’s causing the issues, work out how to address it.
Take the each “room for improvement” from the reporting tools, take them a step at a time.
If you’re using google fonts there are plugins you can use to make them load locally.
If you haven’t use next gen images in the first instance, use a plugin to batch convert images and convert future images on upload.
Debloat and optimise your site’s database (I’ll cover this in more depth in a future post)
Remember that things change. What’s all good yesterday isn’t always good today. Goalposts move. Sometimes you won’t be able to make an older site pass all the pagespeed autdits, consider a rebuild.
Apply your updates, use recent PHP versions.

Good luck, and remember, once you’ve worked all the things out, you’ll know more for next time…. because there will be a next time.