"My site feels slow" is not a measurement, and neither is a single green score from one tool on one afternoon. Testing WordPress performance properly means measuring the right metrics, from the right places, under the right conditions, and knowing which numbers actually predict what a visitor experiences. This guide walks through a testing method that produces numbers you can trust and act on.

Decide what you're actually measuring first

There are two completely different questions hiding inside "is my site fast," and conflating them is the most common testing mistake.

Front-end load performance — what a real visitor's browser experiences: how fast content paints, how soon the page becomes interactive, whether it jumps around while loading. This is measured by Core Web Vitals.
Back-end / server performance — how quickly your server generates the HTML before the browser does anything. This is Time to First Byte (TTFB) and raw requests-per-second under load.

A site can have an excellent TTFB and still feel sluggish because of render-blocking JavaScript, and a site on a fast theme can be crippled by a 900ms server response. Test both, separately.

The metrics that matter (and the targets to hit)

Google's Core Web Vitals are the load-bearing numbers because they affect both user experience and rankings. As of 2026 the thresholds for a "good" rating are:

Largest Contentful Paint (LCP) < 2.5s — when the biggest above-the-fold element (usually a hero image or heading) finishes rendering.
Interaction to Next Paint (INP) < 200ms — responsiveness to clicks and taps. INP replaced First Input Delay in March 2024 and is far more demanding, because it measures every interaction across the visit, not just the first.
Cumulative Layout Shift (CLS) < 0.1 — how much the layout jumps around. Almost always caused by images without width/height attributes, late-loading ads, or web fonts.

For the server side, aim for a TTFB under 600ms, and ideally under 200ms for cached pages. On a properly configured host with full-page caching, an uncached WordPress page should rarely exceed 800ms.

Lab data vs. field data — use both, trust field data

This distinction separates people who test properly from people who chase vanity scores.

Lab data is a simulated load in a controlled environment — a single run from a datacenter with a throttled connection. Tools like Lighthouse and the lab tab of PageSpeed Insights produce it. It's reproducible and great for debugging, but it does not reflect your actual visitors.

Field data (also called RUM, real user monitoring) is collected from actual Chrome users via the Chrome User Experience Report (CrUX). The "Discover what your real users are experiencing" panel in PageSpeed Insights is field data. This is what Google uses for ranking, and it's the number that matters. The catch: CrUX needs enough traffic to report, so brand-new or low-traffic pages will only show lab data.

Rule of thumb: debug with lab data, judge success with field data.

A repeatable testing procedure

Inconsistent testing produces inconsistent numbers and pointless panic. Standardize the conditions:

Test a representative URL, not just the homepage. Homepages are often hand-optimized while the real traffic lands on blog posts, product pages, or category archives. Test the templates that actually get visited.
Warm the cache first, then run three times. The first hit after a cache purge is always the slowest. Discard it, then take the median of three runs — never a single result.
Pick a test server location near your audience. Testing a UK site's speed from a server in Australia tells you about latency, not your stack.
Test logged-out. WordPress bypasses page caching for logged-in users, so testing while logged into wp-admin measures a slow path real visitors never hit.
Test on a throttled mobile profile. Mobile is where Core Web Vitals are won or lost, and Google indexes mobile-first.

Which tools to actually use

You don't need ten tools. You need the right three or four for the job.

For Core Web Vitals and field data

PageSpeed Insights is the canonical source because it shows both Lighthouse lab data and CrUX field data side by side. Start here. For ongoing monitoring, Google Search Console has a Core Web Vitals report that flags failing URL groups across your whole site.

For waterfall analysis and debugging

WebPageTest is the practitioner's tool. It gives you a request-by-request waterfall, lets you pick real device and connection profiles, runs from dozens of global locations, and exposes a filmstrip view so you can see exactly when content appears. When PageSpeed flags a slow LCP, WebPageTest shows you which request is to blame. GTmetrix is a friendlier alternative with a clean waterfall and history tracking.

For server-side load testing

To answer "how many concurrent visitors can my server handle," lab tools are useless — they test one request. Use a load-testing service like k6, Loader.io, or LoadForge to simulate concurrent users and watch where response times spike and errors begin. This is how you discover that your "fast" site falls over at 50 simultaneous users because of an uncached admin-ajax call.

Reading a waterfall like a diagnostician

The waterfall chart is where vague slowness becomes a specific culprit. Look for:

A long first bar (TTFB) — server, PHP, or database problem. Check your caching plugin and host, not your front end.
A wall of blocking CSS/JS at the top — render-blocking resources delaying first paint. Candidates for deferral, async loading, or a plugin like WP Rocket or FlyingPress.
Enormous image requests — unoptimized media. The single most common WordPress weight problem; modern pages should target well under 1–2MB total, and hero images should be served as WebP or AVIF.
Dozens of third-party requests — analytics, chat widgets, ad scripts, embedded fonts. Each adds a DNS lookup and a connection. Audit whether every one earns its place.

Establish a baseline and re-test the same way

A performance test is only meaningful relative to a baseline. Record your median numbers before changing anything — TTFB, LCP, INP, CLS, total page weight, and request count for two or three representative URLs. After each optimization, re-test under identical conditions and compare. Change one variable at a time; if you enable a caching plugin, image optimization, and a CDN all at once and the score improves, you've learned nothing about which one mattered or whether one is now redundant.

Finally, treat performance as a standing metric, not a one-off audit. Themes update, plugins bloat, a new marketing tag gets pasted into the header, and an image-heavy post slips through. Monitoring CrUX in Search Console monthly catches regressions while they're still cheap to fix — long before a visitor emails you to say the site "feels slow."

How to Test WordPress Performance Properly