Core Web Vitals assessment failed: which metric to fix first
The assessment fails when LCP, INP or CLS misses Good at the 75th percentile of 28 days of real Chrome data. How to read it and which metric to fix first.
LLaunchScaler·Published ·8 min read
"Core Web Vitals assessment: Failed" means that in the last 28 days of real Chrome user data, at least one of the three metrics missed the Good threshold at the 75th percentile: Largest Contentful Paint above 2.5 s, Interaction to Next Paint above 200 ms, or Cumulative Layout Shift above 0.1. Fix the failing metric that affects the most traffic first, then expect up to 28 days before the assessment turns green.
The assessment is a verdict on field data, not on a test you just ran. That is why it can fail while the Lighthouse score below it is green, and why a fix deployed today does not change it today. The sections below explain how the verdict is computed, how to read it, and the order to fix things in.
How is the Core Web Vitals assessment calculated?
PageSpeed Insights takes three metrics from the Chrome User Experience Report (CrUX): LCP, INP and CLS. For each, it finds the 75th percentile of real visits over "the previous 28-day collection period." The assessment passes "if the 75th percentiles of all three metrics are Good. Otherwise, the aggregation does not pass the assessment."
The thresholds, as PageSpeed Insights sets them:
Metric
What it measures
Good
Needs improvement
Poor
LCP (Largest Contentful Paint)
Loading: when the largest element renders
2.5 s or less
Over 2.5 s up to 4 s
Over 4 s
INP (Interaction to Next Paint)
Questions, answered
What people ask about this
01
What does 'Core Web Vitals assessment: Failed' mean?
It means that, in the last 28 days of real Chrome user data for that page or origin, at least one of LCP, INP or CLS was not Good at the 75th percentile. Passing needs LCP at 2.5 s or less, INP at 200 ms or less and CLS at 0.1 or less.
02
Why does PageSpeed Insights say failed when my performance score is green?
Two rules cover missing data. If a page or origin "has insufficient data for INP, then it will pass the assessment if both the 75th percentiles of LCP and CLS are Good." And "if either LCP or CLS have insufficient data, the page or origin-level aggregation cannot be assessed," which is when you see no verdict at all.
Why the 75th percentile: Google says it "ensures that pages provide a good user experience under the most difficult device and network conditions." In plain terms, three out of four visits must be Good. A page that is fast for most people and slow for a large minority on older phones fails.
How do you read a failed assessment?
Look at which metric is red or amber, whether the data is for the page or the whole origin, and whether you are on the Mobile or Desktop tab. Each of those changes what you fix. PageSpeed Insights shows the 75th percentile value above each metric's distribution bar, and the bar shows what share of visits was Good, Needs improvement and Poor.
Work through the report in this order:
Check the tab. Mobile and desktop are assessed separately, each with its own verdict, so a page can pass on one and fail on the other.
Check the scope. If the page lacks enough data, PageSpeed Insights "will fall back to origin-level granularity, which encompasses all user experiences on all pages of the website." An origin-level failure may come from other pages, not the one you tested.
Find the metric that is not Good. Note its 75th percentile value and how far it is from the threshold.
Read the distribution. If 70% of visits are Good, you need a small improvement for a quarter of visits; if 30% are Good, the problem is structural.
Only then scroll to the lab diagnostics, which explain why the metric is slow on a simulated device.
Search Console gives the site-wide view. Its Core Web Vitals report groups similar URLs, and "once a URL group has a threshold amount of data for both LCP and CLS, the URL group's status is its most poorly performing metric." The worst metric sets the status of the whole group. Tools for each view are compared in Core Web Vitals checker tools.
Why does the assessment fail when the lab score is green?
Because they measure different things. The assessment uses 28 days of field data from real Chrome users on their own devices and networks. The performance score comes from one Lighthouse run on a simulated mid-tier phone. Google's own FAQ says "having good lab data does not necessarily mean real-user experiences will also be good."
The mismatch has predictable causes:
Situation
Why lab and field disagree
INP fails in the field, lab looks fine
Lighthouse does not interact with the page; INP only exists when real users click and type
LCP fails in the field, lab LCP is fast
Real users arrive on slow networks, from far away, with cold caches, or on pages whose LCP element differs from the one tested
CLS fails in the field, lab CLS is low
Shifts from cookie banners, ads or late content appear after the lab run ends or only for some visitors
Field is Good, lab is poor
Your real audience uses faster devices than the simulated phone
Treat field data as the verdict and lab data as the diagnosis. PageSpeed Insights says so implicitly by putting the assessment on top: the lab section tells you where time goes, but only the field data decides pass or fail.
Which Core Web Vital should you fix first?
Fix the failing metric that affects the most traffic, not the one with the worst number. In Search Console, sort the Poor and Needs improvement URL groups by the number of URLs affected and start with the largest group, because one template usually produces the whole group and one fix clears it.
Then choose by metric, using the one that is not Good:
If LCP is failing, start with the server and the hero image. Break LCP into its sub-parts to see whether time goes to the server response, the image request starting late, the download, or rendering. Improving Largest Contentful Paint gives the budget for each sub-part.
If INP is failing, find the specific slow interaction, usually a click handler or a heavy hydration, and break up the long task behind it. Fixing a poor Interaction to Next Paint shows how to find it with the web-vitals library.
If CLS is failing, find the element that moves. Images without dimensions, web fonts swapping, and banners inserted above content are the usual suspects. Fixing Cumulative Layout Shift pairs each cause with its CSS or HTML fix.
If TTFB is high alongside a failing LCP, fix the server first. TTFB is not a Core Web Vital, but it is part of every LCP, so a slow server makes a Good LCP hard to reach. Reducing Time to First Byte walks the request path.
When two metrics fail on the same URL group, start with the one furthest from its threshold, unless the other has a single obvious cause. A CLS failure traced to one element is often a one-line fix and is worth clearing first.
How long does it take for a fix to show in the assessment?
Up to 28 days. The field data behind PageSpeed Insights and Search Console covers a trailing 28-day window, and PageSpeed Insights' data is updated daily. After a fix, each day adds good visits and drops old ones, so the 75th percentile moves gradually rather than switching on deploy.
Search Console follows the same clock. When you click Start Tracking on an issue, it starts "a 28-day monitoring session," and "if this issue is not present in any URLs on your site during the 28-day window, the issue is considered fixed." Starting validation before the fix is live wastes the window.
Use lab data to confirm the fix the same day, then let the field data catch up:
Deploy the fix to production.
Run PageSpeed Insights and check the lab metric and diagnostics you targeted.
If you collect your own real-user data, watch the 75th percentile of the metric daily.
Start validation in Search Console for the affected issue.
Re-check the assessment after two to four weeks, when most of the 28-day window reflects the new code.
Keeping it green after that is a monitoring problem, since a regression takes up to 28 days to show in the same data. Core Web Vitals monitoring covers catching one early.
Why is there no Core Web Vitals assessment for my page?
There is not enough real-user data. CrUX "requires that a URL must be public (crawlable and indexable) and have sufficient number of distinct samples." A new or low-traffic page falls back to origin data; if the origin lacks data too, PageSpeed Insights is "unable to show any real-user experience data." Search Console shows "No data available" for the same reason.
What to do without field data:
Use the lab metrics as your guide, knowing they are an estimate of one device. Aim well inside the Good thresholds, since real devices vary.
Collect your own field data. The web-vitals JavaScript library reports LCP, INP and CLS from real visits to your analytics, which gives you a 75th percentile before CrUX has one.
Check that the page is indexable. A page blocked by robots.txt or carrying noindex is excluded from CrUX regardless of traffic.
Check your field data and the causes behind it
To see where a page stands now, run the free scan on LaunchScaler with its URL, no account needed. Its speed checks read the same Chrome field data at the 75th percentile for LCP, INP, CLS and TTFB, say whether page-level field data exists or the result falls back to the origin, and run lab diagnostics for the usual causes: a lazy-loaded LCP image, render-blocking resources, unused JavaScript, third-party script cost, images without reserved dimensions and fonts that block text. Fix the metric with the most traffic behind it, then give the field data its 28 days.
The assessment uses field data from real users, while the performance score comes from a single Lighthouse lab run on a simulated device. Google's PageSpeed Insights documentation says good lab data does not necessarily mean real-user experiences will also be good.
03
How long does it take to pass the Core Web Vitals assessment after a fix?
Up to 28 days. The field data covers a trailing 28-day window, so the 75th percentile only moves as new visits replace old ones. Search Console's validation also runs a 28-day monitoring session.
04
Why is there no Core Web Vitals data for my page?
The Chrome UX Report needs a public, crawlable and indexable URL with enough real-user samples. Pages without enough data fall back to origin-level data, and a site with too little traffic shows no field data at all.
05
Does failing Core Web Vitals hurt rankings?
Google says good Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward, and recommends achieving them. It does not publish a weight, so treat a failed assessment as a user experience problem first.
Two curl commands show whether your .env or .git folder is public. What a leak looks like, why deleting the file is not enough, and the rotation steps.
