Core Web Vitals — field data vs the lab.
Real Chrome users beat any test we can run. But a quiet site has no real-user data at all — which is normal, is not a failure, and quietly removes Core Web Vitals from your score rather than tanking it.
Core Web Vitals are Google's three measurements of what your website feels like to use: how fast the main thing appears, how quickly the page reacts when you tap it, and whether it jumps around while you're reading. They're a confirmed ranking signal — and the section of your report people most often misread, because there are two completely different ways to measure them.
Field data vs a lab estimate
Everything in this section arrives one of two ways, and the chip at the top of the block tells you which.
| Source | What it actually is | Chip |
|---|---|---|
| Field data | Real Chrome users on your real site. Google aggregates what actual visitors experienced over the past month. This is the data Google itself uses. It's the truth. | Field data |
| Lab estimate | One controlled test, on a simulated phone. We load your homepage in a testing harness and measure it. Repeatable, instant, and not real. | Lab estimate |
Field data wins whenever it exists. When it doesn't, we run the lab test on your homepage automatically on first view, save it with the audit, and show that instead — with the blue Lab estimate chip so you're never confused about which one you're reading.
Field data also comes at one of two levels, shown as a small chip beside it:
- This page — enough real visitors to your homepage specifically. The best data you can get.
- Whole site — not enough for the homepage alone, so the numbers cover your whole domain. Still real users, just averaged more broadly.
Why a quiet site has no field data — and why that's fine
Google only publishes field data for sites with enough real Chrome traffic to anonymise it. A local business doing a few hundred visits a month will have none — not because the site is slow, but because there aren't enough visitors for Google to report on without identifying them. This is the single most common question about this section, and the answer is: nothing is broken.
So if your site is quiet, you'll see the lab estimate, and that's the right thing to look at. It's a genuinely useful signal about your homepage — it just isn't a measurement of your customers.
The other consequence matters more, and it's good news: with no field data, Core Web Vitals is removed from your SEO score entirely. It isn't scored zero. The Technical pillar reweights around it and the rest of your pillars are rescaled. You are not being punished for a measurement Google won't give us. How reweighting works →
An Essential-depth audit skips this step deliberately, with exactly the same effect. If your Core Web Vitals section is empty and you can't think why, check which depth you ran. Audit depths →
LCP, INP and CLS
Three cards, each with your number, a coloured status and a bar showing where you land between good and poor.
| Metric | What it measures | Good |
|---|---|---|
| LCP Largest Contentful Paint | How long until the biggest thing on screen — usually your hero image or headline — has actually appeared. The honest answer to “how fast does it load”. | ≤ 2.5s |
| INP Interaction to Next Paint | When someone taps or clicks, how long before the page visibly responds. Measures the lag between the intent and the reaction. | ≤ 200ms |
| CLS Cumulative Layout Shift | How much the page jumps around while it loads. The reason you tap the wrong button because an advert loaded above your thumb. | ≤ 0.10 |
Anything past the poor line is scored as a fail: LCP over 4.0 seconds, INP over 500ms, CLS over 0.25. Between good and poor is the amber middle — Google calls it “needs improvement”, and it's worth half.
In plain terms: LCP is usually your images, INP is usually your JavaScript, and CLS is usually a missing width and height on something. That's not a rule, but it's where to look first.
Why the lab shows TBT instead of INP
Look at a lab estimate and the middle card says TBT, not INP. That is not a mistake, and it's worth understanding.
INP measures a real person tapping something. It cannot exist in a lab, because in a lab nobody taps anything. There's no user. There's no interaction. There's nothing to time.
So the lab measures the cause instead of the symptom. Total Blocking Time is how long the browser's main thread was too busy to respond to anything — which is precisely why a page feels sluggish when you tap it. Same root cause, different instrument:
| Metric | Answers | Good |
|---|---|---|
| INP (field) | “When a real person tapped, how long did the page take to respond?” | ≤ 200ms |
| TBT (lab) | “How long was the page too busy to respond if someone had?” | ≤ 200ms |
A bad TBT will produce a bad INP once you have real users, and the fix is the same for both: run less JavaScript, and break up what you do run. Treat TBT as an early warning of an INP problem you can't see yet.
The section says so itself, in small print under the metrics: lab data is a controlled-test estimate, not real-user field data, and TBT is the lab proxy for INP.
How it feeds your score
Core Web Vitals is a High-severity check inside the Technical pillar. Each of the three metrics scores full marks in the good band, half in the middle, nothing in the poor band, and the check takes the average.
It's also the one check with no fix card. Its points are entirely real and they're in your score — but they're shown as a +N pts to gain chip on the heading of this section instead of as a card on the fix board, so the same points aren't counted twice in front of you. Why the board works that way →
How to improve, and what the errors mean
Under the three metric cards, How to improve lists the top opportunities the performance test found on your homepage, each with an estimated saving in seconds — biggest win first. They're the specific things on your page (an oversized image, a render-blocking script), not generic advice.
When performance data can't be fetched at all, the message tells you which of four things went wrong:
| What you see | What it means | You should |
|---|---|---|
| “Performance data isn't switched on yet” | A configuration job on our side — the Google performance key isn't finished. Nothing to do with your site. | Contact us |
| “Google is rate-limiting right now” | Too many performance tests in a short window. Temporary and self-clearing. | Wait a minute |
| “That page took too long to render” | The test gave up waiting for your homepage. Ironically informative: a page that can't finish rendering inside the test budget is a genuinely slow page. | Retry, then investigate |
| “Couldn't fetch that just now” | Something transient went wrong. | Retry |
Each of those comes with a Try again link. The test can take up to a minute, and it saves with your audit — so it runs once and stays put until your next audit, rather than re-testing every time you open the page.
If you have field data and it's poor, fix it — real users are having a bad time and Google knows. If you have no field data, Core Web Vitals is currently costing you nothing in the score, so it's rarely the best thing to work on. Go and clear your fix cards first, and come back to performance when you have the traffic to measure it.