Most WordPress speed optimisation starts in the wrong place. Someone installs a caching plugin, compresses the images, watches the page speed score climb, and assumes the job is done. Then the site still feels slow and nobody knows why.
The problem is not the fixes. The fixes are fine. The problem is applying them before knowing where your load time is actually going. This guide covers the seven checks that tell you that, so you stop guessing and start improving the thing that is genuinely costing you seconds.
Why WordPress speed optimisation fails without measurement
A page speed score is a single number covering dozens of separate delays in your loading time: how fast the server answers, how much work PHP does, how heavy the database query is, how large the images are, how much JavaScript blocks rendering.
Improve the wrong one and the number barely moves. Improve the right one and it drops noticeably. Without measurement you cannot tell which is which, so you end up installing plugins and hoping one of them helps.
That is also why two sites with identical setups can differ so much in website performance. The bottleneck is rarely in the same place twice.
7 checks before you change anything
1. Server response time, first and always
Time to first byte is how long your server takes to begin answering. It happens before a single image or script loads, so every other part of your loading time is stacked on top of it.
If this is high, nothing you do on the page will make the site feel fast. It is also the check that points straight at the cause: hosting that is undersized, a database doing too much work, or PHP running heavy code on every request.
Start here. If your server response time is fine, the page load speed problem sits in the page itself. If it is not, the problem lives underneath, and no amount of front end work will hide that.
2. Field data, not just your lab score
Testing tools give you two different things. Lab data is a simulation: one page, one device, ideal conditions. Field data is what real visitors actually experienced over the past month.
They often disagree, and the field data is the one Google uses. You can see both in Google PageSpeed Insights. If your lab score is green while the field data is not, you are optimising for the test rather than for people.
3. The pages you are not testing
Almost everyone measures the homepage. It is usually the lightest page on the site and the best cached, which makes it the least useful thing to test.
Check the pages where people actually do something: a deep content page, a form, a search result, an account page. On a shop, the cart and checkout. Those bypass the cache and run live, which is exactly why their website speed behaves differently.
4. Database size and clutter
Every post revision, expired session, orphaned option and leftover table from a deleted plugin stays in the database unless something removes it. Years of that adds weight to queries that run on every page load.
Check the size before you assume it is fine. Once a database passes a couple of gigabytes it is usually contributing to your slow loading times, and no caching layer touches it. A bloated database shows up on the front end and behind the scenes, which is why a slow WooCommerce admin is often the first warning sign.
5. Which plugins actually cost you
Plugin count tells you almost nothing. Twenty light plugins can outperform five heavy ones.
What matters for site performance is what each plugin loads and when. The expensive ones are usually those loading scripts and styles site wide for a feature used on a single page. It is almost never the plugin owners suspect, which is why this needs measuring rather than guessing.
6. Image weight against display size
Images are still the single biggest drag on loading time for most pages. The check is simple: compare the file being served with the space it appears in.
A 4000 pixel image shown in a 400 pixel slot is wasted bandwidth, and compression only softens that. Modern formats and correct dimensions do more for page speed here than any plugin setting.
7. What your caching is not covering
Caching serves ready made copies instead of rebuilding pages, which is why scores improve so quickly after enabling it.
The check is what stays outside it. Anything personal to a logged in visitor must never be cached, or people see each other’s data. On a shop that means cart, checkout and account pages. Those run live every time, so if your slow page loads are there, caching was never going to help.
Reading the results
Once you have run the seven checks, the pattern usually points at one of three layers.
If your server response time is high, the problem sits underneath the site: hosting, database, or code running on every request. On a webshop that layer causes most of the trouble, which we break down in why your WooCommerce store is slow. If response time is fine but the page renders slowly, it is front end weight: images, scripts, render blocking resources. And if everything tests well but people still complain, you are almost certainly measuring the wrong pages.
That is the whole point of measuring first. WordPress performance optimisation is not a fixed list of tasks. It is finding which of those three layers is costing you time, then improving that one properly.
When to hand it over
The checks above tell you where your site performance is actually breaking down. Some of what they reveal is straightforward to act on. Hosting, images and unused plugins are all within reach if you have the time.
Other findings are not. Restructuring a database, reconfiguring a server, or tracing a plugin conflict on a live site are jobs where a mistake costs more than the slow load times did. If your checks point there, or if you have already applied the obvious fixes and the numbers have not moved, that is the moment to stop researching.
Woosa improves the full stack, hosting, database, configuration and front end, working on a staging copy first so your site keeps running while it gets faster. Every project comes with before and after measurements, and we see an average revenue increase of 18% after an optimisation. If you would rather have it fixed than keep digging, our speed optimisation service is where to start.
FAQ
What is WordPress speed optimisation?
WordPress speed optimisation, also called WordPress performance optimisation, is the process of finding and removing whatever is hurting your page speed and load time. That covers hosting, server response time, database, plugins, images and front end code. Done properly it starts with measurement, because the bottleneck is rarely in the same place on two different sites.
How do I know what is making my WordPress site slow?
Check your server response time first, then compare your field data with your lab score, then measure the pages people actually use rather than just the homepage. Those three checks narrow it down to the server layer, the front end, or something your tests were never looking at.
Why is my WordPress site still slow after installing a caching plugin?
Because caching only helps pages that can be served as copies. If your server response time is high, your database is bloated, or the slow loading happens on pages that cannot be cached, caching improves your score without improving the experience.
What is the difference between lab data and field data?
Lab data is a simulated test of one page under ideal conditions. Field data is the website speed real visitors experienced over the past month. They frequently disagree, and Google uses the field data, so that is the number worth acting on.
How big is too big for a WordPress database?
There is no hard limit, but once a database passes a couple of gigabytes it is usually adding measurable delay to queries that run on every page load. Cleaning it up helps site performance, though it needs care because plugins can depend on data that looks unused.
Should I do WordPress speed optimisation myself?
The obvious layers are worth doing yourself: hosting, images, and removing plugins you no longer use. Hand it over once the checks point at the server, the database or a plugin conflict, because those are the ones where trial and error on a live site does real damage.