Core Web Vitals assessment failed: what it means and how to pass.

A failed Core Web Vitals assessment in PageSpeed Insights (shown as “Core Web Vitals Assessment: Failed”) tells you that at least one of the loading, responsiveness and stability values your real visitors experienced over the last 28 days fell outside Google’s threshold. It can also appear on a page with a high lab score, because the two do not measure the same thing.

Testing a page in PageSpeed Insights and seeing a score above 90 at the bottom but a failed Core Web Vitals assessment at the top is a common contradiction. The contradiction is only apparent: the score comes from a single lab test, the assessment from real users’ data.

This guide explains what the assessment is based on, why it fails, where to start and when it will turn green after a fix. We covered the general difference between the two ways of measuring in the guides how to measure site speed and field data and lab measurement.

What is the assessment based on?

According to the PageSpeed Insights documentation, the assessment looks at three measures: LCP, INP and CLS. If the 75th percentile of each in the last 28 days of real-user data is in the “good” range, the page passes the assessment. If any one of the three is outside its threshold, it does not pass. Mobile and desktop are assessed separately.

1. LCP · the largest content appearing on screen · good: 2.5 seconds or less
2. INP · response to clicks and taps · good: 200 milliseconds or less
3. CLS · page elements shifting position · good: 0.1 or less
4. Criterion · 75th percentile of the last 28 days · mobile and desktop separately

The 75th percentile is the point within which three quarters of visits fall. If the slowest quarter exceeds the threshold, the assessment fails; in other words, the result is set not by visitors on fast devices and connections but by those on slow ones. INP replaced FID in 2024; if you see FID in older reports, it is no longer part of today’s assessment.

There are two more details. If there is not enough data for INP, the assessment looks only at LCP and CLS. If there is not enough data for LCP or CLS, no assessment can be made at all.

Is the page or the site being assessed?

If there is not enough real-user data for a page, PageSpeed Insights falls back to the data for the whole site, that is, the experiences across all of its pages. That is why a fast page can show a failed assessment because the rest of the site is slow. The documentation says that data may be insufficient for newly published or rarely visited pages. When you look at the result, first check whether the data belongs to that page or to the whole site.

What does “not enough data” mean?

Real-user data comes from the Chrome User Experience Report (CrUX). Only visitors who use Chrome on a supported platform, have turned on usage statistics sharing and sync their browsing history are included in this report; Chrome on iOS and other Chromium browsers such as Edge do not contribute data. A page or a site must pass a certain number of visitors to be included in the report, and Google does not disclose that number.

Seeing “not enough data” on a low-traffic site is not a penalty; it only says that there is no real-user data. In that case, you look at the lab test and, if possible, at the site’s own visitor measurement.

Why does the assessment fail when the Lighthouse score is high?

The lab test runs on a single simulated device and network, with an empty cache, usually only on the home page and without anyone clicking. Real visitors, on the other hand, browse on different phones and connections, across different pages, and by actually using the page. According to web.dev’s explanation, a lab test cannot predict when a user will interact; that is why it cannot measure INP directly and looks at Total Blocking Time (TBT) instead. The same explanation also says that a page with a very good TBT can have a poor INP.

CLS in the lab likewise counts only the shifts that happen during loading and on the first screen; it does not see the shifts that happen when scrolling. The reverse happens too: on our own site the lab said 87 while real Chrome measured 98; we explained why in a separate article.

Which measure is failing, and where do you start?

In PageSpeed Insights, first look at which measure is outside its threshold. The Core Web Vitals report in Search Console shows the same data for the whole site: it groups similar pages, and a group’s status is set by the worst of the three measures. The answer to the question “in which page family, which measure, on which device?” is there.

Then proceed according to the measure. If LCP is high, there is usually a large image at the top, a request that starts late or a slow server response (how to lower LCP). If INP is high, heavy JavaScript and third-party tags are keeping the main thread busy (what INP is). If CLS is high, images without declared dimensions, banners that load later or a font swap are shifting the page (how to zero out CLS). On most sites the assessment fails on mobile; the reasons are in the mobile performance gap guide.

When does it turn green after a fix?

Because real-user data covers a 28-day window, a fix is reflected in the assessment not in a day but over weeks; the value improves as old visits leave the window. In Search Console, after fixing an issue you can start a 28-day monitoring period with “Validate fix”; if the issue is not seen on any URL during that time, it counts as fixed, and if it is seen on any of them, validation fails.

While you wait, you can see right away with a lab test that the fix is working; the lab result reflects the change the same day.

Does the assessment affect rankings?

Google Search Central writes that Core Web Vitals, together with the other aspects of page experience, align with what its core ranking systems seek to reward, and strongly recommends achieving good values. We weighed the weight of speed in search and its relation to content in the how to measure site speed guide.

Short checklist

1. Device · is mobile or desktop failing?
2. Scope · is the data for this page or for the whole site?
3. Measure · LCP, INP, CLS — the worst one sets the result
4. Page family · the URL group in Search Console
5. Verification · see the fix first in a lab test
6. Waiting · 28 days; start validation in Search Console

If you would like to read and fix your site’s assessment together, our method is on the site speed optimization page.

If you want your own site measured and fixed at the source, our Core Web Vitals optimization starts from real-user data and delivers LCP, INP and CLS against a budget.