Core Web Vitals Assessment Failed: What It Means and How to Fix It

What a failed assessment actually means

When you test a URL in PageSpeed Insights, the top block is headed Discover what your real users are experiencing. That block is not a test of your page. It is a summary of what real Chrome users recorded while visiting it over the previous 28 days, taken from the Chrome UX Report (CrUX). The line Core Web Vitals Assessment: Failed means that, at the 75th percentile, at least one of the three Core Web Vitals is outside the good range.

The 75th percentile means that three out of every four page loads must reach the good threshold for that metric. A page where half of visitors get a 1.8 second LCP and a quarter get 5 seconds still fails, because the slow quarter drags the 75th percentile figure over the line.

All three metrics must be good for the assessment to pass. There is no averaging and no partial credit: a page with an excellent LCP and CLS but an INP of 240 ms fails. If there is not enough INP data, the assessment is made on LCP and CLS alone. First Contentful Paint and Time to First Byte appear in the same block as diagnostic figures, but they do not decide the result.

Mobile and desktop are assessed separately. PageSpeed Insights opens on the mobile tab, and mobile is where most sites fail, because real phones have slower processors and less reliable connections than the machines the site was built on.

Why a high performance score can still fail

Below the field data block sits the Lighthouse performance score, the number out of 100 most people look at first. It comes from a single simulated page load on a throttled connection, run from Google's servers, with no real visitor involved. It is a lab test. The assessment above it is field data. The two often disagree, and when they do, the field data is what Google uses in its page experience signals and in the Search Console report.

A site can score 95 in the lab and fail in the field because real visitors arrive through slow advert redirects, use older Android phones, or interact with a menu that runs heavy JavaScript the lab never clicks. The reverse also happens: a score of 50 next to a passed assessment usually means most real visitors have the page cached or are on fast devices.

Use the lab report to find causes, because it shows which element, script or file is slow. Use the field data to decide whether you have fixed anything. Our guide to field and lab mismatches covers this gap in more depth.

How to find which metric and which pages are failing

Start in PageSpeed Insights on the mobile tab. Look at the three Core Web Vitals and note which one is amber or red. That metric is your target. Fixing one that is already green will not change the result, however much effort it takes.

Next, check which data you are looking at. Above the metrics there is a choice between This URL and Origin. If the page does not have enough Chrome traffic of its own, PageSpeed Insights says so and shows figures for the whole origin instead. In that case the failure may come from completely different pages, such as a slow blog template, while the page you tested is fine.

To see which pages are failing, open the Core Web Vitals report in Search Console. It sorts URLs into Poor, Need improvement and Good for mobile and desktop, and lists issues such as LCP issue: longer than 2.5s (mobile). Click an issue to see example URLs, each standing for a group of pages that behave alike.

Pulling the figures yourself

The Chrome UX Report API returns the same 75th percentile figures for a URL or origin. With a free API key from Google Cloud:

curl -s "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"origin": "https://www.example.com", "formFactor": "PHONE"}'

Swap origin for url to query a single page. A 404 response saying no data was found means the page or origin does not have enough traffic to be included, which is common for small sites and new pages.

Recording real visitors on your own site

CrUX tells you that a metric fails, not why. Google's web-vitals library with its attribution build reports the element, the script or the interaction responsible:

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name,
    value: Math.round(metric.value * 1000) / 1000,
    page: location.pathname,
    detail: metric.attribution
  }));
}
onLCP(send); onINP(send); onCLS(send);

A week of this data, grouped by template, usually points straight at the cause.

Common causes for each failing metric

For LCP, the LCP guide explains how to split the time into its four parts, and the high TTFB guide covers the server side. On phones in particular, see high LCP on mobile.

For INP, record an interaction in the Chrome DevTools Performance panel with CPU throttling at four times slower, then look for long tasks during the click. The INP guide and the long tasks guide show how to break work up and defer it.

For CLS, the CLS guide walks through reserving space. Remember that CLS is measured across the whole visit, so shifts caused by content loading as the visitor scrolls count as well, not just the first screen.

Fixing templates rather than pages

Search Console does not list every slow URL. It groups pages that look alike and perform alike, then shows example URLs with the group's figure. A group of 1,200 product pages failing on CLS is almost never 1,200 separate problems. It is one product template with one missing image dimension, or one widget that loads late.

Work out which template each failing group uses: home page, category, product, article or landing page. Fix the template, deploy it, and every page built from it improves together. This is also why hand-tuning one landing page rarely moves the report.

Some practical points for common platforms:

• WordPress. Page builders, sliders and stacks of plugins are the usual cause of poor INP and LCP. Check the rendered HTML, not the settings screens. See Core Web Vitals in WordPress.
• Shopify. Apps inject scripts into every page, including ones that do not use them. Remove apps you no longer use and check that their code has gone from the theme. See Core Web Vitals in Shopify.
• Next.js and other frameworks. Large client bundles and hydration work hurt INP. Render on the server where you can and mark the hero image as the priority image. See Core Web Vitals in Next.js.
• Cloudflare or another CDN. Caching HTML at the edge can cut server response time sharply for LCP, but it does nothing for INP or CLS.

A worked example

A small holiday cottage business sees Core Web Vitals Assessment: Failed on its home page, mobile tab. LCP is 3.4 s, INP is 160 ms and CLS is 0.04. Only LCP needs work. The lab performance score is 78.

The lab diagnostics name the hero photograph as the LCP element. The page source shows:

<img src="/uploads/cottage-hero.jpg" loading="lazy" width="2400" height="1350" alt="Stone cottage at dusk">

The file is 1.8 MB and lazy-loaded, so the browser waits for layout before requesting it and then downloads far more than a phone needs. The template is changed to:

<img src="/uploads/cottage-hero-800.webp"
  srcset="/uploads/cottage-hero-800.webp 800w, /uploads/cottage-hero-1600.webp 1600w"
  sizes="100vw" width="1600" height="900"
  fetchpriority="high" alt="Stone cottage at dusk">

The phone-sized file is now 120 KB. Lab LCP on mobile drops to 1.9 s across five runs. The owner starts validation in Search Console. After two weeks the 75th percentile is 2.7 s, because half the window still holds old visits. After four weeks it is 2.1 s, the assessment shows Passed, and the Search Console group moves to Good.

The fix, step by step

Edge cases worth knowing

• No field data at all. Small or new sites may show no assessment, only the lab report. That is not a failure. Use the lab report and your own monitoring until there is enough traffic.
• Origin fails, page passes. If the URL view passes but the origin fails, other templates are at fault. Find them in Search Console rather than tuning the page you tested.
• Passing on desktop, failing on mobile. Treat them as separate problems. A desktop fix may do nothing for phones, where the processor and network are the limit.
• Results vary between lab runs. Lighthouse can differ by several points or a few hundred milliseconds from one run to the next. Compare the median of three to five runs, not a single result.
• Logged-in areas. Field data includes everyone using Chrome, so a slow account area or members' dashboard on the same origin counts towards the origin figure.
• Back and forward navigation. Pages restored from the back/forward cache are very fast. Avoiding unload handlers so pages stay eligible improves field figures without any other change.

Keeping the assessment green

A passed assessment drifts back to failed when a new plugin, a new tag or a redesigned template arrives. A few habits stop that:

1. Keep real-user monitoring running so you see a change within days, not when the 28-day window has filled.
2. Check the Core Web Vitals report in Search Console every month, and after any release that touches templates, scripts or hosting.
3. Run Lighthouse on one page from each template before releasing changes, and compare the result with the previous release.
4. Review every new third-party script, chat widget or tracking tag for its effect on INP before it goes live. The third-party tags guide shows how to load them later.

The Core Web Vitals guide explains each metric in more depth if you want the background.