You run the test. It says 43. You panic, spend a weekend on it, run it again — 51. Run it a third time without changing anything — 47.
Somewhere in there, most people conclude the tool is broken or the work was pointless. Neither is true. You're just reading the wrong number.
The big circle at the top is the least important thing on the page. Here's what to look at instead.
The short version
Field data — the top section, from real Chrome users. This is what Google grades you on.
Lab data — the score circle and everything below it, from a simulated test. A diagnostic tool, not a grade.
Read them differently. Field data tells you whether you have a problem. Lab data tells you what's causing it.
And your lab score swinging by ten points between runs is normal.
Field data: the part that counts
At the top of the report, if your page has enough traffic, you'll see "Discover what your real users are experiencing."
That's the Chrome User Experience Report — actual measurements from real Chrome users who visited your page, over a rolling 28-day window.
This is what Google uses for ranking. Not the score.
Four metrics, three of which are the Core Web Vitals:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP — main content appears | Under 2.5s | 2.5–4.0s | Over 4.0s |
| INP — response to interaction | Under 200ms | 200–500ms | Over 500ms |
| CLS — layout stability | Under 0.1 | 0.1–0.25 | Over 0.25 |
| TTFB — server response | Under 0.8s | 0.8–1.8s | Over 1.8s |
The threshold is assessed at the 75th percentile, which is the detail people miss. You need three-quarters of real visits to hit "good" — not your own test on a fast laptop. That's why a page can feel quick to you and still fail.
No field data shown? Your page doesn't have enough traffic for Google to report on without exposing individuals. Not a verdict — just an absence. Use lab data and check back as traffic grows.
Lab data: useful, but not a grade
Below the field section sits the performance score and the lab metrics, produced by Lighthouse running a simulated page load on a throttled mid-range mobile device.
What it's for: immediate feedback. Field data lags by weeks, so while you're actively fixing things, lab data is the only signal that responds today.
What it isn't: the number Google ranks you on.
The score is a weighted composite of several lab metrics, not a direct reflection of your Core Web Vitals. You can score 70 and pass Core Web Vitals comfortably. You can score 95 and fail INP, because a simulated test doesn't click anything.
Why your score changes every test
This drives people mad, so here's the mechanism.
The test simulates network and CPU throttling, and the simulation isn't identical every run.
The testing servers vary in load. Same page, different available resources.
Third-party scripts respond differently each time — ad networks, analytics, chat widgets all have variable response times you don't control.
Your own server varies under different loads.
What's normal: a swing of roughly ten points between consecutive runs on the same page. Sometimes more on a script-heavy page.
What to do about it: run the test three times and take the middle result. Compare like with like — same page, same device setting, ideally similar time of day. And judge real improvement on field data, not on lab movement.
If your score drops eight points after a change, that might be noise. If it drops thirty, that's real.
Is a 100 score necessary?
No, and chasing it is one of the more common ways to waste a fortnight.
What matters is passing Core Web Vitals in field data — LCP, INP, and CLS all in "good" at the 75th percentile. That's the ranking-relevant outcome.
A score in the 80s or 90s with passing field data is a finished job. Grinding from 92 to 100 typically means deferring scripts and inlining CSS in ways that risk breaking functionality, for a change no user perceives.
The worse version: people disable functionality to chase the number. A site scoring 100 because you removed your booking widget is a slower path to revenue than a site scoring 78 that works.
Mobile scores are structurally lower than desktop, because the test simulates a mid-range phone on a throttled connection. A mobile score of 65 alongside a desktop 95 is ordinary, not a fault.
The three diagnostics worth acting on
Skip most of the opportunity list. Three sections do the real work.
1 — "Largest Contentful Paint element"
Under Diagnostics, PageSpeed names the exact element it measured as your LCP.
This is the single most useful line in the report. It tells you precisely what to fix.
On WordPress it's usually a hero image, a heading in a slow-loading webfont, or a page builder container. If it's an image, check three things: is it WebP, is it sized to display dimensions, and is it lazy-loaded? That last one is a common own-goal — lazy-loading your LCP element delays exactly what the metric measures.
2 — "Reduce unused JavaScript" and "Reduce unused CSS"
Expand these and you get a list of files with sizes.
Read the file paths. They're your plugin folders. A 340KB JavaScript file from a slider plugin on a page with no slider tells you something actionable — that plugin is loading everywhere and shouldn't be.
This is the fastest route to identifying which plugins are expensive without installing anything. The full audit.
3 — "Avoid large layout shifts"
Names the specific elements that moved during load.
Usually images without width and height attributes, ads or embeds without reserved space, or webfonts swapping in and reflowing text.
CLS is generally the easiest of the three vitals to fix, and this section hands you the list.
What to mostly ignore
"Eliminate render-blocking resources." Legitimate, but the fixes — critical CSS, deferring JavaScript — are where sites break. Do it carefully, late, and test everything after.
"Serve static assets with an efficient cache policy" for third-party files. You don't control Google Analytics' cache headers.
"Reduce the impact of third-party code." Useful information, but the action is deciding whether you need each script, not a technical fix.
The score circle itself. Read the field data instead.
A five-minute workflow
- Field data first. Any metric outside "good"? That's your problem list. Nothing there? You're passing, whatever the score says.
- Note your LCP element. Diagnostics section. This is usually the fix.
- Check unused JS and CSS for plugin names you don't recognise on that page.
- Check layout shift elements if CLS is failing.
- Ignore the rest until those are handled.
Then fix one thing, re-test three times for a middle value, and wait weeks for field data to confirm it.
Frequently asked questions
Why does my PageSpeed score change every test?
Because the lab test simulates network and CPU throttling, and that simulation varies between runs — as does testing server load, third-party script response times, and your own server's load. A swing of around ten points between consecutive runs is normal. Run the test three times and take the middle result, and judge genuine improvement on field data rather than lab movement.
Is a 100 score necessary?
No. What matters is passing Core Web Vitals in field data — LCP, INP, and CLS all in "good" at the 75th percentile of real visitors. A score in the 80s or 90s with passing field data is a finished job. Pushing beyond that usually means aggressive script deferral and CSS inlining that risks breaking functionality for a change no user perceives.
What is field data?
Real measurements from actual Chrome users who visited your page, collected in the Chrome User Experience Report over a rolling 28-day window. It appears at the top of the report when your page has enough traffic. This is what Google uses for ranking — lab data below it is a simulated diagnostic. If no field data appears, your page doesn't have enough traffic for Google to report on, which is an absence rather than a failure.
What to do next
Run your most important page and read only two things: the field data section, and the "Largest Contentful Paint element" line under Diagnostics.
If field data is all green, you're passing and the score doesn't matter. If LCP is failing, that named element is your fix — and on most WordPress sites it's an image that's too large, or lazy-loaded when it shouldn't be.
Free: The WordPress maintenance checklist.
Related guides
- WordPress speed: the Core Web Vitals playbook — the full fix order
- WordPress plugin audit — acting on the unused JS list
- Image SEO — fixing a failing LCP element
- Search Console: the 5 reports that matter — vitals grouped by template
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]