Why your site fails Core Web Vitals at 100 PageSpeed

Your developer sends a screenshot. PageSpeed Insights, 98 out of 100, three green circles. Six weeks later Google emails you: Core Web Vitals issues detected on your mobile pages.

Both are telling the truth. They measure two different things, and only one of them counts.

A PageSpeed score is lab data: one simulated load, on one modelled device, in one location. Your site fails Core Web Vitals on field data instead, which is real Chrome visits at the 75th percentile over a rolling 28 days. The metric that fails most often, INP, is not in that lab score at all, which is how the number at the top of the report stays green while Google emails you about your mobile pages.

Say you run a kitchen fitting company in Sheffield. Nine pages, a quote form, roughly 1,400 visits a month, most of them from phones after 7pm. The lab test runs on a modelled mid-range Android, throttled, inside a Google data centre. Your visitors are on four-year-old handsets on patchy 4G, with a cookie banner and a chat widget loading before they can tap anything.

The grade comes from them. Not from the test.

Why does my site fail Core Web Vitals when PageSpeed says 100?

Because the big number at the top of PageSpeed Insights is not the thing being graded. It's a Lighthouse run: one page load, with simulated network and CPU throttling, scored as a weighted blend of lab metrics. Useful for debugging. Not the assessment.

Scroll past it and there is a second panel, usually headed "Discover what your real users are experiencing". That one comes from the Chrome User Experience Report, or CrUX, Google's dataset of measurements taken from actual Chrome visits. Search Console's Core Web Vitals report reads the same source. When the two panels disagree, the field panel wins.

So stop reading the score. Read the field data underneath it, note which of the three metrics is amber or red, and work from there.

The three that count, with their published thresholds:

• LCP (Largest Contentful Paint, how long until the biggest thing on screen has rendered). Good is 2.5 seconds or less.
• INP (Interaction to Next Paint, how long a page takes to respond visibly when someone taps or clicks). Good is 200 milliseconds or less. Over 500 is rated poor.
• CLS (Cumulative Layout Shift, how much the content jumps around while loading). Good is 0.1 or less.

What the 75th percentile means for a small site

Your worst quarter of visits sets your grade. Google's write-up of how the thresholds were defined puts it plainly: if at least 75 percent of page views meet the good threshold, the site is classified as good for that metric. If at least 25 percent meet the poor threshold, it is classified as poor. The percentile was picked so that a majority of visits should have experienced the target performance, and because the 75th percentile is less likely to be dragged by outliers.

Read it from the other direction and it stings. Your fibre-connected desktop visitors can't rescue you, and neither can the office iMac you test on. A fast average is irrelevant. What matters is the visit sitting at the 75th percentile, and on a site with 1,400 visits a month that's a small, identifiable group on specific hardware.

Usually one of these:

• Older Android phones, which are most of the long tail of handsets in the US and the UK.
• Mobile data in bad spots: car parks, trains, basements, building sites.
• A hero video or an uncompressed header image nobody has looked at since launch.
• Third-party scripts firing on first tap, which is where consent tools, tag managers and chat widgets do their damage.

Why does PageSpeed Insights show no field data for my page?

Because CrUX needs enough real visits to report a percentile, and a quiet page does not have them. Google's PageSpeed Insights documentation says a page might not have sufficient data if it was recently published or has too few samples from real users. When that happens, the tool falls back to origin-level granularity, which covers all user experiences on all pages of the website. If the origin is thin as well, you get no field data at all.

That fallback has a consequence most people miss. Your homepage carries the traffic, so your homepage sets the numbers the whole domain is judged on. A physiotherapy clinic in Phoenix with twelve staff and nine pages is really being graded on its home page and its booking page. The quiet service pages inherit that result whether they deserve it or not.

Missing field data isn't a pass. It's an absence of evidence, which leaves you guessing from a simulation. For a low-traffic site the honest fix is real user monitoring: a small script that records the same three metrics from your own visitors, including the pages CrUX will never cover.

Your iPhone visitors are not in the data at all

CrUX collects from Chrome, on a defined set of platforms. The CrUX methodology sets out what a visit has to clear before it counts: usage statistic reporting enabled, browser history syncing, no Sync passphrase, and a supported platform. The supported platforms are desktop Chrome on Windows, macOS, ChromeOS and Linux, plus Chrome on Android, including mobile apps using Custom Tabs and WebAPKs.

Safari is not on that list. Nor is Chrome on an iPhone, which runs on Apple's engine rather than Chrome's own.

For a car detailing business in Al Quoz, where a large share of the audience is on iOS, that's a strange position to sit in. The grade Google publishes is drawn from your Android visitors, and the people most likely to pay you may be missing from it entirely. It cuts both ways. An iPhone-heavy audience can be having a rough time on your booking page while CrUX reports nothing unusual, and Google's tools will never tell you. The web-vitals JavaScript library will, in any browser that supports the metrics, and its attribution build names the element and the script responsible.

INP is usually the problem, and the lab score cannot see it

Lighthouse doesn't measure INP. It can't: a standard run loads the page and nobody taps anything, so there's no interaction to time. Barry Pollard, who works on web performance at Chrome, explained the gap to Search Engine Journal: Lighthouse cannot measure INP directly because of that lack of user interactions, and Total Blocking Time stands in as a proxy.

A proxy is not the metric. You can post a strong Total Blocking Time and still hand a real customer a 400 millisecond delay on the first tap of your booking form. What hurts them is the work queued on the main thread at the moment they touch the screen.

Consent banner initialising. Analytics tag loading. Chat widget unpacking itself.

That last one deserves bluntness, because we see it constantly. A chat widget is a third-party application you have invited onto your critical path, and a chat widget can slow a website down in ways no lab test will show. Overlay tools that promise to fix something else for you behave the same way: a script bolted on top of a page rarely fixes what's underneath it.

To find your own culprit, in order:

1. Open Search Console, Core Web Vitals, and switch to the mobile report. Write down the failing metric and one example URL.
2. Run that exact URL through PageSpeed Insights and read the field panel, not the score.
3. Put the web-vitals attribution build on the site, or any real user monitoring tool, and wait a week for your own numbers.
4. Look at what loads before first interaction, and cut or defer anything you can't name a business reason for.
5. Fix one thing. Wait for the window to roll. Check again.

Step five is where most people give up, which brings us to timing.

How long until a Core Web Vitals fix shows up?

About a month, and you can't hurry it. CrUX aggregates the past 28 days of visits. Deploy a fix today, and tomorrow your faster site is one day out of 28 while the other 27 still carry the old one. That window has to roll before the number moves properly. CrUX and PageSpeed Insights refresh daily, Search Console lags behind that, and several weeks is normal rather than several days.

Plan around it. Ship the fix, write down the date, look again in four weeks with the field panel open. Re-running Lighthouse the next morning and seeing 100 tells you nothing you didn't know yesterday. If you want to see movement sooner, your own monitoring is the only thing that will show it, for the same reason we argue for knowing when an automation has stopped working rather than hearing it from a customer.

What changes in 2027: soft navigations

If your site is a single-page app, where clicking a link swaps the content without a fresh page load, these metrics have never described it accurately. Google is fixing that.

Chrome published experimental soft navigation versions of LCP, INP and CLS in CrUX on 13 October 2026, built on the Soft Navigations API that shipped in Chrome 151. They count an in-app route change as a navigation in its own right. The stable scores stay unchanged while the experimental versions are evaluated beside them. Chrome has said it aims to move them out of experimental status in May 2027, subject to feedback, and that Search Console would then switch to the new data.

A site that loads a fresh HTML page on every click should see very little change. If you're running React, Next.js or Vue with client-side routing, your grade is about to start reflecting what happens after the first page, which for a lot of apps is where the slow interactions live. Worth pulling the experimental numbers now, while there's a year to act on them.

When none of this is your problem

Here is where we talk ourselves out of work. On plenty of small business sites, Core Web Vitals is not the reason the enquiries are thin.

If you get 300 visits a month, CrUX may never report on your site at all, and a four-figure performance rebuild buys you a number nobody is reading. The enquiries are being lost somewhere more boring: a quote form with eleven fields, no phone number above the fold, confirmation emails landing in spam, or nobody replying until Tuesday. We have told people to spend that budget on their intake instead of on our invoice, and we would tell you the same. A 0.4 second improvement on a page nobody is abandoning is worth nothing.

Core Web Vitals is a tiebreaker. It matters when you are up against sites that are otherwise comparable, when a slow page is visibly costing you mobile visitors, or when the site is big enough that a percentage point of abandonment is real money. It isn't a growth plan.

What to do this week

Open Search Console, go to Core Web Vitals, switch to the mobile report, and write down two things: the failing metric, and one example URL. That's the whole job for today. Everything after it follows from knowing whether you have an LCP problem (images, hosting, render-blocking assets) or an INP problem (scripts on the main thread), and no lab score will tell you which.

If the report says you have no data, that answers a different question. You need your own measurement before you spend anything on performance work.

We build fast business websites and we fix slow ones. Send the URL and the failing metric through our contact page, and we will tell you what we would look at first and whether it is worth paying anyone to do.