Performance monitoring platforms like DebugBear, SpeedCurve, and Calibre charge real money for a reason: continuous tracking, alerting, and historical trend lines are genuinely hard to build yourself. But none of that is what you need for a one-time audit. To diagnose why a WordPress site is slow, the free tools are not a compromised version of the paid ones. They surface the exact same root causes. What you give up is the polish around the diagnosis, not the diagnosis itself.

The trick is knowing that each free tool answers a different question. Run them in the wrong order, or treat them as interchangeable, and you get conflicting numbers and a confused afternoon. Run them deliberately and you get a clear picture of what is wrong and what it is costing you.

The three questions a speed audit actually answers

Every page-speed investigation is really three separate questions, and a different free tool owns each one:

"What are real visitors experiencing?" — answered by field data (the Chrome User Experience Report, surfaced in Search Console and PageSpeed Insights).
"Why is it slow, reproducibly?" — answered by lab data (Lighthouse, run from PageSpeed Insights or Chrome DevTools).
"Which specific request is to blame?" — answered by request-level forensics (a WebPageTest waterfall or the DevTools Network panel).

Field data tells you whether you have a problem worth fixing. Lab data tells you what category the problem is in. Forensics tells you the exact file to delete or defer. Skip the first and you optimize pages nobody struggles with; skip the last and you guess.

Start with field data, because it decides whether to bother

Open Google Search Console and go to the Core Web Vitals report. This is the single most important screen in the entire audit, and it is completely free. It shows the last 28 days of real-user measurements from actual Chrome visitors, bucketed into Good / Needs Improvement / Poor, split by mobile and desktop, and grouped by URLs that share the same problem.

The three metrics and their passing thresholds, as of 2026:

LCP (Largest Contentful Paint) — under 2.5 seconds. How fast the biggest visible element (usually a hero image or headline) renders.
INP (Interaction to Next Paint) — under 200 milliseconds. INP replaced FID in March 2024; if a tool or tutorial still mentions First Input Delay, it is out of date. This measures how sluggish the page feels when a visitor taps or clicks.
CLS (Cumulative Layout Shift) — under 0.1. How much the layout jumps around as things load.

If Search Console shows your URL groups are "Good" across all three, the SEO upside of further optimization is essentially zero, and you can stop. If it shows "Needs Improvement" or "Poor," it also tells you which metric and which URLs, which is exactly where to point the rest of the audit. New or low-traffic sites will see "insufficient data" — CrUX needs a real visitor volume before it reports. In that case you lean entirely on lab data, with the caveat that lab numbers are an estimate, not the truth Google ranks on.

Reproduce it in the lab with PageSpeed Insights

Next, run the slow URL through pagespeed.web.dev. PSI shows field data (CrUX) at the top when available and Lighthouse lab data below. Always read the mobile tab first — Google indexes mobile-first, the mobile score is harsher, and a passing desktop score hides nothing useful.

Ignore the big colored number at first. Scroll straight to the Diagnostics and the "passed/failed audits." The lines that matter most for WordPress are almost always the same handful: "Eliminate render-blocking resources," "Reduce unused JavaScript," "Reduce unused CSS," "Serve images in next-gen formats," "Properly size images," and "Avoid enormous network payloads." Each one names the offending files. Note the estimated savings, but treat them as directional — Lighthouse's savings math is optimistic.

One number on PSI deserves a hard target on its own: Time to First Byte (TTFB), your server's response time. Google's threshold for "good" is under 800ms. A high TTFB on WordPress almost always points at the server layer — no page caching, an overloaded shared host, or a bloated theme doing too much PHP per request — and no amount of front-end image tweaking will fix it.

The WordPress forensics: read the waterfall like a fingerprint

This is where free tooling earns its keep and where generic speed advice stops being useful. Run the page through WebPageTest (now owned by Catchpoint; the free tier is metered, so save your runs for the pages that matter), or just open Chrome DevTools, hit the Network tab, and reload. Either gives you a waterfall: every single request, in order, with its timing.

WordPress sites leave recognizable fingerprints in that waterfall. Hunt for these specifically:

Plugin assets on pages that don't use the plugin. A contact-form plugin loading its CSS and JS on every page when the form only lives on /contact. A slider library on posts with no slider. This is the most common WordPress bloat by far, and the generic tools never label it as such — you only spot it by recognizing the plugin's file path in the request list.
Duplicate jQuery or duplicate libraries. Two different plugins each bundling their own copy of jQuery, or two competing lazy-load scripts. The waterfall shows the same library fetched twice from different paths.
The emoji script. WordPress core injects wp-emoji-release.min.js on every page. If your site doesn't render emoji, that is a pure render-blocking tax.
Google Fonts loaded from Google's CDN. A separate connection, DNS lookup, and round trip to fonts.gstatic.com — usually faster self-hosted, and in some jurisdictions a GDPR concern too.
Un-deferred third-party embeds. A YouTube iframe, an ad tag, or a chat widget loading synchronously and dragging INP down. In the waterfall these show up as long, late-blocking requests to domains you don't control.

The DevTools Coverage tab (open the command menu with Cmd/Ctrl+Shift+P, type "Coverage") is the perfect companion here — it shows what percentage of each CSS and JS file actually executed on the page. A stylesheet that is 90% unused is your render-blocking smoking gun, and it confirms the "plugin asset on the wrong page" suspicion with a hard number.

Where the free tier genuinely stops

Be honest about the ceiling. Free tools give you a snapshot. They do not give you scheduled tests, alerting when a deploy regresses LCP, side-by-side trend charts over weeks, or filmstrip comparisons across builds — those are the features the paid platforms sell. For a one-time audit, or even a quarterly re-check, that gap doesn't matter. For a team shipping changes weekly to a revenue-critical site, continuous monitoring is worth paying for. Know which situation you're in before you reach for your card.

Close the loop, every time

The discipline that separates an audit from a ritual is re-measurement. After each fix, re-run PSI and re-pull the waterfall, and compare the specific metric you targeted — not the headline score, which bounces around run to run. If you deferred a script and INP didn't move, your diagnosis was wrong; investigate before you congratulate yourself. Field data in Search Console is the final arbiter, but it lags by up to 28 days, so use the lab and waterfall for fast feedback and let CrUX confirm the win weeks later.

Used in that order — field data to decide, lab data to categorize, the waterfall to convict the exact file — four free tools will diagnose virtually any WordPress speed problem you'll ever meet.

WordPress Page Speed: A Practical Audit Without Buying Tools