A slow WordPress website can create a strange kind of pressure. Everyone can feel that something is wrong, but the explanations usually arrive before the evidence. It must be the hosting. It must be the theme. It must be the plugins. It must be the images. Any of those things might be true, but guessing usually wastes time.
When I audit a slow WordPress site, I try to separate the feeling from the cause. The site might feel slow because the server is taking too long to respond. It might feel slow because the page is downloading too much. It might feel slow because JavaScript is blocking the interface after the page appears. Those are different problems, and they need different fixes.
The first decision is therefore to measure before changing anything. I want a clear baseline, even if it is imperfect. Without that, it is too easy to make a change, feel like the site is better and then realise later that the improvement was only visible on one page or one connection.
Starting With The Page People Actually Use
I do not start with the homepage automatically. I start with the page that matters. That might be a service page, a product category, a booking page or a landing page that receives most of the paid traffic. The homepage is important, but it is not always the page where slow behaviour is costing the business the most.
Once I know which page matters, I test it in a few different ways. I look at the network requests, the document response time, the size of the assets and what happens after the page becomes visible. I also use the page manually because reports do not always describe frustration very well. A page can score acceptably and still feel awkward when someone opens a menu or interacts with a form.
I usually write down the first observations before fixing anything. That stops me from losing track of the original condition of the site. It also makes the eventual improvement easier to explain to someone who is not looking at developer tools all day.
Checking The Server Before Blaming The Front End
If the initial document response is slow, I look at the server side before spending too much time on CSS or JavaScript. WordPress has to assemble the page, run plugins, query the database and send the response. If that part takes too long, compressing an image will not solve the real problem.
Caching is usually the first practical question. Is page caching enabled? Is it working for logged-out visitors? Are dynamic pages being excluded properly? Is the cache being cleared at the right moments? I have seen sites with caching plugins installed where the cache was not actually serving the important pages correctly.
Database queries, plugin behaviour and external API calls can also affect the first response. A page that waits for a third-party service before rendering can feel slow even if the front-end assets are reasonable. That is why the first response needs to be understood on its own.
Looking At What The Browser Has To Download
Once the server response is understood, I move to the assets. Images are usually easy to inspect. Are they the right dimensions? Are they compressed sensibly? Is the mobile layout downloading desktop-sized media? Are images below the first screen being loaded before they are needed? These are basic questions, but they still catch a surprising number of issues.
CSS and JavaScript need a slightly different review. I want to know which files are loaded globally and which are only needed on specific pages. WordPress sites often accumulate plugin assets that appear everywhere, even when the feature only exists on one section of the site. That kind of waste becomes more noticeable as the site grows.
Third-party scripts get their own check. Analytics, embeds, chat widgets and marketing tags can all add work to the page. Some of them may be important. Some may no longer be used. I do not remove them without understanding why they are there, but I do question whether they need to load immediately and everywhere.
Testing Interactions After The Page Loads
In 2024 I am also paying more attention to interaction performance. A page that appears quickly but responds slowly is still a poor experience. This is especially true on mobile, where a menu, filter or form might be the first meaningful thing someone tries to use.
I click through the page and watch for moments where the browser feels busy. If a button takes too long to respond, I look at what the click triggers. If opening a menu feels sticky, I check whether the script is doing more work than necessary. If a filter causes a delay, I look at how much of the page is being updated.
This part of the audit often leads to smaller, more targeted fixes. Remove a duplicate listener. Delay a non-essential script. Simplify an animation. Avoid rebuilding a section of the page unnecessarily. These changes can make the website feel better even when the initial load score does not move dramatically.
Making The Fixes In The Right Order
I try to fix the largest known problems first. If the server response is poor, caching and hosting need attention before small front-end tweaks. If images are clearly oversized, they should be fixed before spending time shaving a few lines from CSS. If third-party scripts dominate the main thread, that needs a business conversation rather than a hidden technical change.
The order matters because performance work can become endless. There is always another minor improvement available. The question is whether it changes the experience enough to justify the time. A good audit should help decide where the effort belongs.
After each meaningful change, I retest the same page and record the difference. That makes the work easier to trust. It also helps avoid breaking something in the process because the site is being checked as it changes, not only once at the end.
Retrospective Thoughts
A good WordPress performance audit is not a hunt for a single villain. It is usually a series of smaller discoveries. The server might need caching, the images might need resizing, the scripts might need loading later and the interface might need less JavaScript doing work after the page appears.
The important part is not to guess. Measure the page people actually use, understand where the delay is coming from and fix the problems in an order that matches their impact. That gives the work a much better chance of improving the site in a way visitors can actually feel.
For me, that is the difference between performance work and performance theatre. The first one changes the experience. The second one changes the report and hopes nobody notices the difference.