Performance
How to measure WordPress speed honestly
2 August 2026 · 5 min read
On this page
Most speed testing produces numbers nobody should act on — a single run of the homepage from a server on another continent, compared against a run from last month under different conditions.
Here is how to measure so the result means something.
The tools, and what each is for
PageSpeed Insights — Google's own view, and the only one showing field data: real Chrome users on your actual site. If you have enough traffic for field data to appear, that is the number Google uses and the one that matters. The lab score below it is diagnostic.
GTmetrix — the best waterfall. Shows exactly what loaded, in what order, and how long each took. This is where you diagnose rather than score.
WebPageTest — the most control. Test from specific locations, on specific connection speeds, on real devices. Slower to use, most accurate.
Query Monitor — inside WordPress, shows server-side time and which plugin owns which query. The only one that tells you why the server was slow.
The five mistakes that produce useless numbers
1. Testing once. Results vary by 20% or more between runs for reasons that have nothing to do with your site. Run three times and take the median.
2. Testing the first, uncached load. The first visitor after a cache clear triggers a full rebuild. Everyone else gets the cached copy. Test the cached experience, since that is what real visitors get — and separately test uncached when you want to measure the server.
3. Testing from the wrong place. A test from Virginia tells you nothing useful if your customers are in Manchester. Set the location to where your visitors are.
4. Testing only the homepage. Your homepage is usually the most optimised page on the site. Test a product page, a blog post, and a category page — that is where the problems live.
5. Chasing the score rather than the experience. A 100 in PageSpeed Insights with a 3-second LCP on real devices is worth nothing to anybody.
What to actually look at
Core Web Vitals — LCP under 2.5s, INP under 200ms, CLS under 0.1. These are what Google measures and they correspond to what visitors feel.
Time to first byte — under 500ms. Isolates server performance from everything else.
Total page weight — under 2MB is reasonable, under 1MB is good. If you are over 3MB, it is nearly always images.
Number of requests — under 60 is fine. Over 100 usually means plugins each loading their own assets.
The waterfall — the single most useful view. What loaded, in what order, what blocked what. Look for long bars and for anything loading that should not be.
Ignore the letter grade
GTmetrix grades and PageSpeed scores are weighted composites, and they reward things that do not always help visitors. A site can score 95 and feel slow; a site can score 70 and feel instant.
Use the score to spot direction of travel, not as a target. If you improve one thing and the score drops, check the actual metrics before undoing it.
A repeatable routine
- Pick three representative pages — homepage, a key inner page, and either a product or blog page
- Test each three times in PageSpeed Insights, take the median
- Record LCP, INP, CLS and TTFB in a note with the date
- Make one change
- Retest the same three pages the same way
The discipline that makes this worth doing is changing one thing at a time. Change five and you will never know which helped, which hurt, and which broke your mobile layout.
Also check Search Console → Core Web Vitals monthly. It groups your whole site by URL pattern, which is how you discover that your blog passes and your product pages have been failing for six months.
Our speed optimisation includes before and after numbers measured exactly this way — three pages, three runs, field data where it exists — so you can verify the result yourself rather than taking a score on trust.