Core Web Vitals assessment: failed

What “failed” literally means

The Core Web Vitals assessment is pass/fail, and it is judged on field data only: measurements collected from real Chrome users and published as the Chrome UX Report (CrUX). The lab score — the 0–100 number from Lighthouse — plays no part in it. To pass, the 75th percentile of real visits over the last 28 days must be in the “Good” range for all three metrics at once:

• LCP (Largest Contentful Paint) — main content visible within 2.5 s
• INP (Interaction to Next Paint) — taps respond within 200 ms
• CLS (Cumulative Layout Shift) — the page moves less than 0.1

Two good and one “needs improvement” is a fail. The 75th percentile means the slowest quarter of visits decides; your median visitor can be fine and the assessment still fails. And mobile and desktop are assessed separately— the Search Console report has a row for each, and a site routinely passes desktop while failing mobile, which is why this checker tests mobile.

It is judged per URL group, not per page

Search Console does not assess every URL individually. It clusters pages it considers similar — usually the same template: all product pages, all blog posts, all category pages — into a URL group, and the group shares one verdict drawn from the combined visits. This is why a page you personally fixed can still sit inside a failing group: the group’s number is dominated by whichever pages in it get the most traffic, and if those are still slow, so is the group.

To find what the group actually is: in the Core Web Vitals report, open the mobile row, click an issue (say, “LCP issue: longer than 2.5s”), and the table lists each group by an example URL with the count of similar URLs beside it. Click the group and Search Console shows a sample of the URLs it contains. Those sample URLs — not the one you were thinking of — are the ones to test.

Why a 90+ lab score and a failed assessment are both true

The lab score is one simulated load: a mid-range phone, a throttled 4G connection, an empty cache, no logged-in state, run once. The assessment is thousands of real loads on whatever your visitors actually own — including the ones on three-year-old Android phones on a weak signal in a car park. The lab cannot see them; the assessment is mostly about them. A site whose lab score reads 95 while its assessment fails is not a contradiction, it is the normal gap between a good device and a bad one, and why sites that fly on desktop crawl on phones is the same story. The lab score also moves between runs; the field number, being an aggregate of a month, barely does.

Which metric caused it — and what to do for each

In the report, the failing URLs are grouped by issue, and the issue names the metric. That gives you a short decision path:

• LCP issue — the main content arrives late. It is a server, image or render-blocking problem, and which of the three depends on where the time sits. The LCP guide walks the phases; the checker’s timeline shows which phase is yours.
• CLS issue — things move while loading: images without dimensions, late-loading fonts, banners and ads inserted above content. The CLS guide covers each cause and the space-reserving fix.
• INP issue — taps and clicks respond slowly, almost always because JavaScript is busy on the main thread. The INP guide explains how to find the long tasks.

INP replaced First Input Delay as the responsiveness metric in March 2024, and it is much stricter: FID measured only the delay before the first tap was handled, INP measures every interaction through to the next frame. That change is now the single most common reason a site that passed for years flipped to failed with no code change — the same JavaScript, judged by a harder rule.

Why the verdict can change when you changed nothing

Because the input is your visitors, not your code. Three things move it on their own:

• Traffic mix. A campaign, a viral post or a new market brings a different audience — a higher share of low-end devices or slow networks pushes the 75th percentile past the line with the same pages.
• Device share. Seasonal and regional shifts in who visits change the slow quarter. Sites that sell into emerging markets see this constantly.
• A new URL group crossing the reporting threshold. CrUX only publishes a group once it has enough visits. A section of the site that was too quiet to be measured starts being measured, arrives failing, and the site-level verdict follows.

The 28-day window, and what “Validate fix” does

Every number in the report is a rolling 28-day aggregate. Ship a fix today and tomorrow’s report still contains 27 days of pre-fix visits; the verdict moves as the old days age out, and flips only when the whole window is clean. Clicking Validate fix does not re-test anything — it tells Search Console to watch that issue for 28 days and email you whether the group’s field number reached Good by the end. It is a timer with a notification, not a measurement. The reporting-lag guide covers how to confirm a fix today rather than in a month.

When the report says failed but the pages say “no data”

This happens on smaller sites: the site-level or group-level verdict is failed, yet inspecting an individual URL shows no field data. The group has enough visits to be assessed in aggregate; no single URL in it has enough to be reported alone. Nothing is broken. Test the group’s example URLs with the checker — the lab result plus the origin-level field data is the best view you can get — and read what “no field data” means for the rest of that situation.

Next step

Take one URL from the failing group in your report — an example URL from the issue table, not your favourite page — and run it through the checker. You get the field values for that page against the thresholds, and the one lab fix that would recover the most time, with the phase it acts on. Free, no signup; the result is kept for 30 days under a random link so you can send it to whoever has to do the work.