How to Run a WordPress Performance Audit (Without Guessing)

Most WordPress performance work starts backwards: someone installs a caching plugin, the score goes up, and nobody can explain why the site still feels slow on a phone.

An audit fixes that by finding causes before anyone changes settings. Here's a version you can run yourself in an afternoon.

Measure first — and in the right conditions

Test on a mid-range Android phone over mobile data, not on your laptop over office fibre. Your developer's machine is the least representative device that will ever visit your site.

Record these, for your three most important pages — homepage, a product or service page, and whatever your ads point at:

• Largest Contentful Paint (LCP). When the main content becomes visible. Under 2.5 seconds is the target; this is the number that correlates most closely with people leaving.
• Interaction to Next Paint (INP). How quickly the page responds to a tap. Under 200ms.
• Cumulative Layout Shift (CLS). How much the page jumps around while loading. Under 0.1. This is the one that makes people tap the wrong button.
• Time to First Byte (TTFB). How long the server takes to respond at all. Over ~600ms points at the server or database, not the frontend.

Write the numbers down. An audit without a baseline is just an opinion with charts.

The four things worth checking

1. Request count and payload. Open your browser's network tab and count. A typical WordPress page pulling 120 requests and 4MB is usually loading assets for plugins that aren't used on that page. This is the single most common finding.

2. Database queries. Query Monitor (free) shows every query the page runs and how long each takes. Look for pages running hundreds of queries, or any single query over ~50ms. Site search is a frequent offender — if that's yours, moving search off the server fixes performance and search quality at once.

3. Caching, honestly assessed. Having a caching plugin installed is not the same as having caching configured. Check whether pages are actually being served from cache for logged-out visitors — the response headers will tell you. A cache that misses on every page view is decoration.

4. Images. Still the biggest single win on most sites. Look for images served larger than their display size, and anything still in PNG or unoptimised JPEG rather than WebP or AVIF.

Reading the waterfall without a computer science degree

The waterfall chart in your browser's network tab shows every request as a bar. Three shapes tell you almost everything:

Turning findings into a plan

Rank by effort against impact, and resist starting with the interesting problem instead of the big one.

• Do first: image optimisation, enabling and verifying page caching, removing plugins you no longer use. Hours of work, large effect.
• Do next: dequeue assets on pages that don't need them, add a CDN, tune your caching layer properly rather than accepting defaults.
• Do when justified: object caching for query-heavy sites, moving search to a dedicated engine, database cleanup and index work.
• Do reluctantly: rebuilding the theme. Sometimes correct, rarely the cheapest path, and easy to talk yourself into. If your site was built with a page builder, the honest answer about builders and speed is worth reading first.

What a good audit actually produces

Not a screenshot of a score. A ranked list that reads like: "LCP is 4.8s on mobile. 2.9s of that is a hero image served at 3000px wide for a 700px slot. Fixing that alone should get you under 2.5s."

If your audit doesn't name causes and estimate their contribution, it hasn't finished. A number without a reason isn't a diagnosis — it's a thermometer reading.

If you'd rather not run this yourself, our Speed & Performance service starts with exactly this audit and fixes what it finds — from $650, and you see the numbers before and after.