WordPress Site Audit Checklist For Speed That Finds The Real Cause
A WordPress site audit is a structured review that separates backend response, frontend weight, Core Web Vitals, plugin load, media delivery, caching, and database health so you can see which layer is actually slow. I run it in a fixed order because that's how you stop guessing and start fixing the one thing that's hurting users. Get the diagnosis right and the fixes almost pick themselves.
A WordPress site audit is a structured review that separates backend response, frontend weight, Core Web Vitals, plugin load, media delivery, caching, and database health so you can see which layer is actually slow. I run it in a fixed order because that's how you stop guessing and start fixing the one thing that's hurting users. Get the diagnosis right and the fixes almost pick themselves. If I were checking this on a real site, I'd start with the page that earns traffic or money, confirm whether the issue is backend, frontend, content, or layout related, then apply one fix at a time.
What Is A WordPress Site Audit For Speed?
A WordPress site audit for speed is a structured review that measures backend response, frontend weight, Core Web Vitals, caching, media delivery, plugin load, and database health, then ranks them so you know which layer is actually slowing the page. It isn't a single score from one tool. It's a diagnosis that tells you where the time goes before you change a thing.
I treat every page load as three buckets: server time, transfer time, and browser time. A good audit measures all three separately, because a site stuck at a 1.4s Time to First Byte needs a totally different fix than one with a 2MB hero image and 40 render-blocking scripts. When you skip the audit, you end up minifying CSS on a site whose real problem is shared hosting, and the number barely moves.
If you want the underlying playbook for why these layers matter, I cover the root causes in my guide on why WordPress is slow, and the audit here is the diagnostic step that comes before any of those fixes. The whole point is to fix the dominant bottleneck first, retest, then move down the list.
Why Should You Audit Before You Optimize Anything?
You audit first so you spend your effort on the one layer that's actually costing users seconds, instead of chasing warnings that change nothing. Most slow WordPress sites have one dominant bottleneck and a dozen minor ones, and the lab report lists them all with equal-looking urgency. Without an audit you can't tell the 1.2-second problem from the 40-millisecond one.
Here's the pattern I see constantly: an owner spends a weekend deferring JavaScript and gets two PageSpeed points, because their real issue was a 1.5s server response that no frontend tweak can touch. An audit catches that in the first five minutes. It turns a vague "my site feels slow" into "TTFB is the problem, the rest is noise for now."
Auditing also stops you from breaking things. When you make ten changes at once and the score drops, you've got no idea which one did it. A proper audit gives you a baseline and a fix queue so each change is testable. That discipline is the difference between guessing and engineering, and it's why I never quote a project before I've run the full pass.
Which Tools Do You Actually Need For The Audit?
You need four sources that each see a different slice of the truth: PageSpeed Insights for lab plus Google's field data, Google Search Console for real-user Core Web Vitals across the whole site, GTmetrix or WebPageTest for a waterfall, and Query Monitor for what's happening inside WordPress itself. No single tool covers all four jobs.
PageSpeed Insights is where I start because it shows both a lab Lighthouse run and the Chrome User Experience field data when your URL has enough traffic. The field numbers are what Google actually ranks on, so they outrank any lab score. I walk through reading that report properly in my PageSpeed Insights guide, and you can run a structured pass straight from my free WordPress audit tool that pulls the same field data automatically.
Search Console matters because it groups every URL on the site into Good, Needs Improvement, and Poor buckets using 28 days of real visitor data. That's how you catch a slow blog template that PageSpeed never showed you because you only tested the homepage. Query Monitor is the inside view: it surfaces slow database queries, the heaviest plugins by load time, and HTTP API calls happening on every request. GTmetrix or WebPageTest fills the last gap with a request-by-request waterfall so you can see exactly which asset blocks the render.
Which Pages Should You Include In The Audit?
Audit your highest-traffic and highest-revenue templates, not just the homepage: the home page, your top landing or service page, a representative blog post, an archive or category page, a product page, and the cart or checkout if you run WooCommerce. Each uses a different template with different queries and scripts, so each can fail for a different reason.
The homepage-only mistake is the most common one I fix. The homepage is usually the most optimized page on the whole site because it gets the most attention, while the blog template that drives organic traffic runs unoptimized queries nobody ever looked at. Test one URL per template type and you'll often find the worst offender is a page the owner never thought to check.
Mobile deserves its own pass. Google indexes mobile-first and most field data is mobile, so a desktop that scores 95 while mobile sits at 48 is a mobile problem, full stop. If that gap shows up, my mobile speed guide is the next stop. For stores, the checkout almost always behaves worse than the catalog because cart fragments and uncached AJAX hit on every interaction, so never let it skip the audit.
What Core Web Vitals And Thresholds Should You Record?
Record six numbers per template and compare each to its pass line: Largest Contentful Paint under 2.5s, Interaction to Next Paint under 200ms, Cumulative Layout Shift under 0.1, Time to First Byte under 0.8s, First Contentful Paint under 1.8s, and Total Blocking Time as a lab proxy for INP. Pull the first three from field data wherever it exists, because that's what Google scores.
Write them down as a table, not a vibe. I log lab and field side by side for every template, because a page can pass in the lab and fail in the field when real users on mid-range phones and patchy networks hit it. When field and lab disagree, field wins, every time. The full breakdown of each metric and what moves it lives in my Core Web Vitals guide.
TTFB is the one people skip and shouldn't. It sits upstream of everything, so a 1.4s TTFB poisons LCP no matter how light your frontend is. If TTFB is over 0.8s, that's your headline fix and frontend work waits. Treat each failed metric as a flag that points at a specific layer: LCP at media and server, CLS at images and fonts without dimensions, INP and TBT at heavy JavaScript and bloated event handlers.
Is A Good PageSpeed Score Enough To Pass The Audit?
No. A 100 in the lab means nothing if your field data shows real users hitting a 4-second LCP, because the lab runs one simulated load on a clean connection while field data is thousands of real sessions on real phones. The score is a starting clue, not the verdict. The verdict is in the Chrome UX field data and Search Console.
I've audited sites that scored 95 in Lighthouse and still felt sluggish to actual visitors, because the lab test never loaded the third-party chat widget, the heatmap script, and the ad tags that fire on a real session. Lab environments strip a lot of that out. The fix is to always cross-check the lab number against field data and against your own loaded-in browsing on a throttled mobile profile.
This is why "chasing the green score" is a trap. Optimize for the metric users feel, which is field LCP, INP, and CLS, and the lab score follows on its own. Flip it around and you'll burn hours tuning a number that nobody experiences. The audit's job is to keep you honest about which number actually matters.
How Do You Audit The Server And Backend Layer?
Start with TTFB, because it's the cleanest read on whether your problem is hosting or your own code. Test a cached page and an uncached one. If both are slow, it's the server or the host. If only the uncached page is slow, it's your PHP, database, or a plugin doing too much work on each request.
My rough line is 0.8s for TTFB. Plenty of cheap shared hosts sit at 1.2s to 1.5s before WordPress even starts rendering, and no plugin fixes that. Check your PHP version too: anything below 8.1 leaves real speed on the table, and moving from 7.4 to 8.2 alone can cut backend time meaningfully. Run Query Monitor on a slow page and read the database panel for queries over about 50ms and the plugin panel for which plugin eats the most time per load.
The give-away for a hosting problem is simple. If a freshly cached static page still takes over a second to return the first byte, you're on a server that can't deliver fast no matter what you do on top of it. That's when I tell owners to look at my slow hosting guide instead of buying another caching plugin. Server first, always, because everything downstream inherits that delay.
How Do You Audit Frontend Weight, Media, And Assets?
Open the GTmetrix or WebPageTest waterfall and list your five heaviest requests, then sort them into images, CSS, JavaScript, fonts, and third-party scripts. The waterfall shows you exactly what blocks the first paint and what's just heavy, and on most WordPress sites images make up 50% to 70% of total page weight, so that's usually where the biggest win hides.
For media, flag any image over 500KB, anything served in JPEG or PNG that should be WebP or AVIF, and anything loaded at full resolution but displayed at a fraction of that size. The LCP image is the one to win first, since it's what the user waits for. My image optimization guide covers the format and sizing rules in depth. For CSS and JavaScript, note render-blocking files in the head and count third-party tags, because each external script adds a DNS lookup, a connection, and bytes you don't control.
Two more checks earn their place. Count total HTTP requests: under 50 is healthy, 50 to 100 is workable, and over 100 usually means a bloated theme or plugin stack adding files you never use. And check DOM size, because a page over roughly 1,400 nodes strains the browser on every interaction and quietly hurts INP. Page builders are the usual culprit there, which is why builder sites get their own audit angle in my Elementor and Divi guides.
How Do You Audit Caching, CDN, And Database Health?
Confirm three things: that full-page caching actually fires, that a CDN serves your static assets, and that your database isn't dragging every request. For caching, load a page twice and check the response headers for a cache hit, or look for the cache plugin's HTML comment near the bottom of the source. A surprising number of sites have a cache plugin installed and misconfigured so it never serves a cached page at all.
For the CDN, check that images, CSS, and JavaScript load from a CDN hostname rather than your origin, and that proper cache headers are set so browsers and edge nodes hold assets instead of refetching them. Cloudflare is the common free option, and I walk through the WordPress-specific settings in my Cloudflare guide. A CDN that's installed but only proxying HTML without caching assets is doing half a job.
The database is the layer owners forget. Open Query Monitor and watch for slow queries, then check your autoloaded options size, because options that load on every single page request are a hidden tax that compounds with traffic. I get worried past roughly 1MB of autoloaded data. Bloat usually comes from expired transients, orphaned post revisions, and abandoned plugin tables left behind after uninstalls. A quick database audit often reclaims more speed than any frontend tweak on an older site.
How Do You Turn Audit Findings Into A Fix Queue?
Convert the audit into one ordered list, grouped by layer and sorted by impact: server and TTFB first, then caching, then media, then CSS and JavaScript, then fonts, then database. Tackle the failed Core Web Vital that affects the most templates before any single-page warning. The order matters because fixing the server changes every downstream number, so you don't want to optimize images on top of a slow host and then redo the math.
Change one layer, then retest. This is the rule people break most. If you batch ten fixes and the score drops, you've learned nothing about which one hurt. I fix, retest the same template in the same tool, log the delta, and move on. It's slower per change and far faster to a result, because you never have to unwind a mess.
Track results in two places over time, not just on the day. Watch Search Console Core Web Vitals move from Poor toward Good over the following weeks, since field data lags real fixes by up to 28 days, and keep your PageSpeed field readings as a record. If the queue is long and the stakes are high, that's the point where bringing in a WordPress speed optimization service pays for itself, and you can see the kind of gains in my before-and-after portfolio.
What Mistakes Make A Speed Audit Useless?
The biggest mistake is treating the lab score as the goal. The lab number is a proxy, and when you optimize the proxy instead of the field metrics users feel, you can raise the score while the site still feels slow. Always anchor the audit to field LCP, INP, and CLS, and let the lab score be a secondary signal.
The second mistake is auditing only the homepage and only on desktop. You miss the slow blog template, the heavy product page, and the mobile experience that most of your traffic actually lives in. The third is fixing warnings that don't affect users, like a tiny unused-CSS flag on a page that already passes, while ignoring a 1.4s TTFB sitting right above it.
The fourth one stings: changing many things at once with no retest between them. You end up unable to prove what helped, and if something regresses you can't isolate it. Audit wide, fix narrow, retest every step. Do that and the audit earns its keep instead of becoming a wall of numbers you stop trusting.
My checklist for WordPress Speed Audit Checklist
Record mobile and desktop PageSpeed scores.
Check LCP, INP, CLS, TTFB, FCP, and total blocking time.
Review cache headers and CDN delivery.
List largest images, CSS files, JavaScript files, and third-party scripts.
Check database size, autoloaded data, and plugin load.