How I Audit a Slow WordPress Site

A WordPress speed audit is not me running one tool, exporting a PDF, and circling some red scores. A proper audit is a shortlist of causes, ranked by impact and effort, with enough evidence that you know what to fix first and what can wait.

That matters because slow sites rarely suffer from one dramatic problem. They usually suffer from a pile of medium problems that need sorting in the right order.

The tools and what each catches

I use a few different tools because each one sees a different part of the story. PageSpeed Insights is useful for real-world signals and Core Web Vitals context. GTmetrix or a waterfall view is useful for the loading sequence. Browser inspection helps spot render-blocking files, layout shifts, and third-party scripts. Inside WordPress, plugin and theme review helps trace where the weight is coming from.

No single score tells the whole truth. A site can have a decent score and still feel clumsy to use. It can also show a rough score while having one or two easy wins that change everything. That is why I care more about the evidence trail than the headline number.

Reading a waterfall like a story

A waterfall looks technical, but the logic is simple once you know what you are looking for. I read it like a timeline of delays.

First, how long does the server take to answer. That helps split hosting problems from site problems. Second, what blocks the page from painting quickly. That is where big CSS files, render-blocking JavaScript, or font loading issues show up. Third, what keeps loading after the page feels like it should have been done already. That is where sliders, tracking scripts, chat widgets, and builder extras often expose themselves.

The point is not to admire the chart. The point is to find the few items causing the most drag. Owners do not need a hundred observations. They need the six that matter.

The audit findings on a real site

On a typical slow WordPress site, the findings are usually familiar. Hero images are too large. Fonts are loading from too many places. A page builder is carrying assets that the page barely uses. There are several plugins solving related jobs. A marketing script that someone installed months ago is still loading on every page. Cache helps a little but is covering symptoms, not the root cause.

I also look for structural issues: templates doing too much, archive pages that are heavier than they need to be, or forms and popups adding unnecessary requests. Sometimes the surprise finding is that the host is fine and the build is not. Sometimes it is the reverse. That is why I do not like selling “speed” as a generic service without diagnosis.

Posts like hosting vs optimisation and font loading come directly from patterns I see in these audits.

What made the cut in the fix list and why

The fix list is the useful part. I rank items by what they cost and what they move. If compressing and resizing images saves a large chunk of page weight in one afternoon, that rises quickly. If replacing a bloated slider with a static hero removes a big script chain, that usually makes the cut too. If a fix is technically elegant but low impact, it moves down the list.

This is where tool-export audits often fail owners. They hand over dozens of notes without helping decide what matters now. A business owner does not need twenty-seven warnings with equal visual weight. They need a rational sequence.

My fix list usually separates quick wins, medium work, and structural work. Quick wins might be images, fonts, or plugin cleanup. Medium work might be caching, script delays, and template adjustments. Structural work might be replacing a builder-heavy page or rethinking how a feature is implemented.

What the client saw a month later

The best outcome is not “the score went up”, though that is nice when it happens. The best outcome is that the site feels faster on a real phone, pages stop jumping around, forms feel cleaner, and conversions stop leaking because the site no longer irritates people before they even read it.

That is also where honesty matters. Not every site can or should chase a perfect score. Some sites carry real functionality that will always involve trade-offs. The right goal is a site that feels quick, loads reliably, and supports the business. Chasing 100 for vanity can waste money that belongs elsewhere.

When I audit a site, the client gets a story they can understand. What is slow. Why it is slow. What to fix first. What can wait. What is worth paying for. What is not. That is the whole service.

If you are wondering whether you need an audit or just a few direct fixes, the answer usually depends on whether the cause is already obvious. If not, diagnosis is cheaper than guessing. That is why I recommend an audit before deeper work on complicated sites.

If you want me to look at a slow WordPress site and tell you what the fix list would really look like, send the URL on WhatsApp. I will tell you if it needs an audit, a few direct fixes, or a rebuild of one problem section. You can also read more about speed optimisation, performance technical SEO, and browse real examples on my work page.

Quick answers

How long does an audit take?

For a normal business site, the audit itself is usually measured in hours, not weeks. The size and messiness of the site decide how deep it needs to go.

Audit vs just fixing, why pay twice?

Because fixing blind is often slower and more expensive than diagnosing first. The audit makes sure the work happens in the right order instead of guessing through symptoms.

What if my site is beyond saving?

That happens sometimes, especially when a site is heavily builder-dependent or held together by plugin overlap. A good audit should say that plainly instead of selling endless patchwork.