Key Points at a Glance
- The green PageSpeed score is a lab value (a simulated test). It’s a good diagnostic tool, but it’s not what Google uses for search.
- For the Core Web Vitals (Google’s three user experience metrics), field data is what counts: real page loads by real visitors, measured at the 75th percentile (the value that 75 out of 100 page views reach or come in under).
- The “good” thresholds are unchanged: LCP ≤ 2.5 seconds, INP ≤ 200 milliseconds, CLS ≤ 0.1.
- INP (Interaction to Next Paint) replaced the old metric FID on March 12, 2024. It measures how quickly your page responds to clicks and input.
- What this means for you: don’t chase the score of 100. Look at the real user data: in Google Search Console or in the field section of PageSpeed Insights.
You’ve got a score of 100. Green, all boxes checked, PageSpeed Insights is thrilled. Yet the page still feels sluggish on a phone, and Search Console says “room for improvement.”
This isn’t a contradiction, it’s a measurement misunderstanding. The score most people chase measures something different from what Google actually evaluates for search.
In this post we’ll clarify three things: why a perfect score can mislead, what data Google really uses, and what you should look at instead. No need to panic over red bars.
The green score that proves nothing
PageSpeed Insights shows you two things that are easy to confuse.
The large colored circle at the top is the Lighthouse score, a lab value. Google loads your page once in a simulated environment: a throttled network, fixed computing power. That produces a number from 0 to 100.
This number is useful for spotting problems. But it’s a snapshot from the test lab, not a picture of your real visitors. Someone opening your page on an old Android phone in a dead zone experiences something completely different from the Lighthouse test.
That’s exactly why a score of 100 and a slow reality can sit side by side. The score doesn’t lie, it just answers a different question than the one that matters for your Google ranking.
Lab data and field data: the difference
There are two ways to measure speed. Both have their place, but only one feeds into Google’s evaluation.
| Lab data | Field data | |
|---|---|---|
| Source | Simulated test run (Lighthouse) | Real page views from real users (Chrome UX Report, or CrUX for short) |
| What | A controlled snapshot | 28 days of collected reality |
| What it’s good for | Finding errors, debugging causes | Judging the actual user experience |
| Does Google use this for search? | No (diagnostics only) | Yes: this is the basis of the Core Web Vitals |
The short version: lab data shows you what the problem is. Field data shows how it feels for your visitors. Google evaluates the Core Web Vitals on field data, not on the lab score.
That’s what Google’s own documentation says, and it’s why jumping from a “score of 90” to a “score of 100” often changes nothing about your rating if real users were already satisfied (or already weren’t).
What Google really evaluates
The Core Web Vitals are three user experience metrics. Google groups them under “Page Experience.” Here they are, with the official thresholds, unchanged as of June 2026:
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | When the largest content is visible (loading feel) | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s |
| INP (Interaction to Next Paint) | How quickly the page responds to input | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | How much the layout shifts while loading | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Two things matter here.
First: the 75th percentile. Google doesn’t take the average, but the value that 75 out of 100 page views reach or come in under. So a few fast load times won’t save you if the last quarter of your visitors suffer. It’s measured separately for mobile and desktop.
Second: “good” only counts when all three are in the green. A page passes the Core Web Vitals check when LCP, INP, and CLS are in the green at the 75th percentile.
An honest note on ranking: Page Experience is one factor among many for Google, not a master switch. A fast page won’t automatically catapult you to the top. But a slow, jumpy page costs you visitors before Google even comes into play, so speed pays off first on your inquiries, not on a ranking guarantee.
INP has replaced FID: what this changes
If you still have “FID” in your head: that metric no longer exists as a Core Web Vital. On March 12, 2024, INP replaced it.
The difference matters in practice. FID only measured the delay on the very first interaction. INP looks across the whole visit and measures response time on clicks, typing, and taps, exactly what users perceive as “laggy” or “smooth.”
For you, this means: heavy scripts, overloaded cookie banners, and sluggish menus now weigh more heavily. INP is the metric that has moved many previously good sites into the yellow zone in 2025 and 2026.
What this means for you, step by step
Instead of chasing the lab score, go to the real data. Here’s how:
- Open Search Console. The “Core Web Vitals” report shows how your pages perform for real users, split by mobile and desktop. That’s your truth, not the lab score.
- Read the field data in PageSpeed Insights. The field block (“real user data”) sits at the top of the report. Look at that first, and the lab score below it only afterwards.
- Mobile first. Most problems sit on the phone. If mobile is green, you’re most of the way there.
- Tackle the causes technically. Typical culprits: oversized images, blocking scripts, fonts that load late, and cookie banners that slow everything down. Here the lab score is useful again, as a tool to find the cause.
- Don’t stare at the 100. The goal is “good” for real users, not a perfect lab number. The last points toward 100 often cost a lot of effort and change little about the user experience.
What we see in projects
A candid word from practice. We’ve been looking after websites since 2007, and the score misunderstanding comes up again and again, often after someone has poured a lot of money into that last point toward 100 without anything changing for visitors.
What we regularly see as a brake in the field data: uncompressed images from the media library, a cookie banner that drives up response time (INP), and theme or extension bloat that no one needs anymore. These aren’t spectacular problems, but they’re exactly the ones that push down the 75th percentile.
The lesson we take from it: read the real user data first, then deliberately fix the biggest brake. That does more than a green circle in the test lab.
Conclusion
The PageSpeed score is a tool, not a report card. It helps you find causes, but it’s not what Google evaluates for search.
What matters is the field data: real visitors, measured at the 75th percentile, across three metrics: LCP, INP, and CLS. Whoever sits in the green there has a page that feels fast to real people. And that’s the point that counts, for your visitors first, for Google second.
Don’t know how your site performs for real users, or why the good score and the slow feeling don’t match up? That’s exactly what a short check can clarify.
→ Have your website’s load time checked against real user data
Frequently Asked Questions
My PageSpeed score is 100. Does that mean my site is fast enough for Google?
Not automatically. The score is a lab value from a simulated test. Google evaluates the Core Web Vitals on field data: real page views from real users. Check Search Console or the field section of PageSpeed Insights to see where you really stand.
What’s the difference between lab data and field data?
Lab data comes from a single, controlled test run (Lighthouse). Field data is the values collected over 28 days from real visitors (Chrome UX Report). Field data is what counts for search; lab data is there to track down causes.
What do LCP, INP, and CLS mean in simple terms?
LCP measures when the largest content is visible (loading feel); good is ≤ 2.5 seconds. INP measures how quickly the page responds to clicks; good is ≤ 200 milliseconds. CLS measures how much the layout shifts while loading; good is ≤ 0.1.
What happened to FID?
On March 12, 2024, FID was replaced by INP as a Core Web Vital. INP measures response time across the whole visit rather than only at the first interaction, giving a more accurate picture of how fluid a page feels.
Does a better Core Web Vitals score lead to higher Google rankings?
We can’t promise that. Page Experience is one factor among many for Google. But a fast, stable page directly helps your visitors, and that affects dwell time and inquiries, regardless of ranking.
Sources
- web.dev — Web Vitals: definitions and thresholds, 75th percentile, field vs. lab data, as of June 23, 2026. web.dev
- Google Search Central — Core Web Vitals & Search. developers.google.com
- Google Search Console — Help for the Core Web Vitals report. support.google.com
- Google Search Central Blog — Introducing INP. developers.google.com
- web.dev — Interaction to Next Paint, metric explainer. web.dev