How to Audit a WordPress Site's Performance in 30 Minutes

A performance audit is not the same as a performance fix. The goal of the next 30 minutes is not to install a caching plugin and hope — it is to leave with a ranked, evidence-backed list of what is actually slow and why. Speed up the diagnosis and the fixes get obvious. Skip it and you spend a weekend optimizing images on a site whose real problem is a 1.4-second server response.

This is a time-boxed routine. Each phase has a budget, a tool, and a specific number you are looking for. Open a blank text file before you start — every finding goes in there, because the deliverable is that list, not a vague feeling that the site "feels sluggish."

Minutes 0–5: Pull the field data first

Start at PageSpeed Insights and run your most important URL — usually the homepage and one key landing page or product page. The single most useful thing on that screen is the panel at the top: the field data from the Chrome User Experience Report (CrUX). This is real Chrome users over the last 28 days, not a synthetic test. If it says "Discover what your real users are experiencing," your site simply lacks enough traffic for field data, and you fall back to the lab score below.

You are checking three numbers against the 2026 Core Web Vitals thresholds:

• LCP (Largest Contentful Paint) under 2.5 seconds — how fast the main content paints.
• INP (Interaction to Next Paint) under 200 milliseconds — responsiveness to taps and clicks. INP replaced First Input Delay in March 2024, so if a tool still shows you "FID," it is out of date and you should ignore that metric.
• CLS (Cumulative Layout Shift) under 0.1 — visual stability as the page loads.

Write down which of the three are passing (green), needs-improvement (orange), or failing (red), and note the gap between field and lab scores. A site that passes lab but fails field usually has a real-user problem your fast laptop and fast connection hide — slow mobile devices, a heavy third-party script, or a host that buckles under concurrent load.

Minutes 5–12: Read the waterfall, not just the score

A PageSpeed score is a grade; a waterfall tells you why. Run the same URL through WebPageTest (pick a real-world profile like "Mobile - 4G" from a location near your audience) or GTmetrix. Watch the connection view load from top to bottom and look for three patterns:

• Time to First Byte (TTFB). This is the first bar. Aim for roughly 200ms; Google's "needs improvement" line sits at 800ms. A TTFB north of a second means the problem is server-side — slow hosting, an uncached database query, or a bloated theme — and no amount of image optimization will fix it.
• Render-blocking resources. Look for CSS and JavaScript files that load before the page can paint. A pile of stylesheets and scripts in the first second is the classic page-builder tax.
• The heaviest requests. Sort by size. On most WordPress sites the top offenders are unoptimized hero images, a Google Fonts pull with six weights, and embedded video or map iframes.

Note your total page weight. A lean content page should land under about 1MB; many WordPress sites running a multipurpose theme and three slider plugins quietly ship 4–6MB. Each oversized request is a line item on your findings list.

Minutes 12–20: Diagnose the WordPress layer

This is the phase generic "speed up your site" posts skip, and it is where the real culprits hide. Install Query Monitor (free) and load a page while logged in. Its admin-bar readout gives you three diagnostics nothing else does:

• Total database queries and the slowest ones. A healthy page runs maybe 30–80 queries. If you see 300+ or a single query taking 100ms+, you have a plugin doing something expensive on every page load.
• Queries by component. Query Monitor attributes load to specific plugins and the theme. This is how you catch the one related-posts or "popular posts" plugin eating 40% of your page-generation time.
• PHP peak memory and total page-generation time. If the server spends 1.5 seconds building the HTML before it is even sent, that explains your bad TTFB directly.

While you are here, audit your plugin count and image formats. Open Media and check whether images are being served as modern formats — WebP or AVIF — or as the 800KB PNGs someone uploaded straight from a phone. Count active plugins; the number matters less than what they do, but anything loading its CSS and JS on every page (not just the page it is used on) is a flag.

Minutes 20–27: Caching, CDN, and the hosting reality check

Now confirm whether the basics are even in place. Open your browser dev tools, go to the Network tab, reload, and inspect the response headers on the main document and a few assets:

• Is page caching active? Look for an x-cache: HIT header or one from your caching plugin (WP Rocket, LiteSpeed Cache, FlyingPress) or host. A cache MISS on every reload means full PHP and database work on every visit.
• Are static assets on a CDN with long cache lifetimes? Check cache-control headers on images, CSS, and JS. Assets served from your origin with no caching headers are a quick win.
• Is the server itself the bottleneck? If TTFB is high and the page is cached, the problem is raw hosting. Cheap shared hosting often delivers 600ms–1s+ TTFB no matter what you do. This is where managed hosts (Kinsta, WP Engine, Rocket.net) and Cloudways earn their price — server-level caching and faster stacks routinely pull TTFB into the 100–300ms range.

Do not implement anything yet. You are still cataloging. The header check tells you whether the fix is "turn on a feature you already pay for" or "you need to change something structural."

Minutes 27–30: Write the prioritized findings list

You now have raw notes. Spend the last three minutes turning them into a ranked list, ordered by impact-to-effort. A useful audit output reads like this:

1. Server response (TTFB 1.2s). Confirm page caching is on; if it is, the host is the constraint — evaluate migration. High impact.
2. 2.8MB of unoptimized hero images. Convert to WebP/AVIF and add lazy loading. High impact, low effort.
3. Render-blocking CSS from the page builder. Enable critical-CSS and deferral in the caching plugin. Medium.
4. Related-posts plugin adding 200ms of queries. Replace or cache its output. Medium.
5. CLS 0.18 from a font swap and an ad slot. Reserve space and preload the font. Low effort, fixes a failing metric.

That ranked list is the entire point. It tells you and any developer exactly where the next hour of work should go, backed by numbers a CrUX report and a waterfall can corroborate later. Re-run PageSpeed Insights a few weeks after the fixes land — field data updates on a rolling 28-day window, so improvements show up gradually, not the instant you flip a switch. The audit is repeatable; run it quarterly and the site never drifts far from green.