“Core Web Vitals assessment failed” in PageSpeed Insights means that, in the last 28 days of real Chrome visits, at least one of LCP, INP or CLS was worse than the good threshold at the 75th percentile. It is a verdict on field data, not on the Lighthouse score shown below it. To fix it, find which metric failed, check whether the result is for the URL or the whole origin and for mobile or desktop, locate the template that causes it, fix the cause and then wait for the 28-day window to roll over before you judge the result.
I get this question more than any other, usually with a screenshot that shows “Failed” in red at the top and a green 90-something lower down. Both are true at once. The green number is one simulated visit. The red word is your actual audience.
What does “Core Web Vitals assessment failed” actually mean?
PageSpeed Insights reads the 75th percentile of each Core Web Vital from the Chrome User Experience Report (CrUX). The assessment passes when all three are in the good band:
- LCP at 2.5 seconds or less.
- INP at 200 milliseconds or less.
- CLS at 0.1 or less.
If any one of them is above that line, the assessment fails, even if it only lands in “needs improvement” and not in “poor”. When there is not enough INP data, PageSpeed Insights can still pass the page on LCP and CLS.
Two details change how you read it. First, there is a toggle between “This URL” and “Origin”. A URL with little traffic may only have origin data, which means the verdict is about the whole site. Second, mobile and desktop are separate reports. Failing on mobile and passing on desktop is the most common pattern I see on WordPress.
Why does it fail when my PageSpeed score is high?
Because the score and the assessment come from different data. The performance score is calculated by Lighthouse from one lab run: one emulated device, one simulated network, no real interactions. The assessment comes from real visits on real phones.
Some gaps I find again and again:
- INP problems never show up in a lab load, since nobody clicks. Lighthouse shows Total Blocking Time, which only hints at the problem.
- Real visitors arrive with cold caches, on older phones, sometimes with consent banners and ad slots that the lab run never sees.
- Layout shifts that happen after load, while people scroll, are missed by a lab test that stops early.
- The lab run may hit a cached page while many real visitors, logged in or with query strings, bypass the cache.
The tools themselves are compared in PageSpeed Insights vs Lighthouse, and the general idea behind the gap is in field data vs lab data.
Step by step: how to fix a failed assessment
- Identify the failing metric. In the field data section, look for the metric in orange or red. Note the device and whether you are looking at URL or origin data.
- Find the affected templates. In Google Search Console, open the Core Web Vitals report. It groups URLs with similar problems and lists an example URL for each group. On WordPress, a group usually maps to a template: single post, product page, category archive.
- Reproduce it in the lab. Open the example URL in Chrome DevTools, throttle the CPU and network, and record with the Performance panel. Find the LCP element, the long tasks or the layout shifts.
- Fix the cause, not the symptom. A fix in the theme or server helps every page that uses it. A fix applied to one page rarely moves a whole group.
- Validate. Confirm in Lighthouse that the lab metric moved. Then, in Search Console, use “Validate fix” on the issue. Search Console tracks the group over 28 days.
- Wait for the field data. CrUX is a 28-day rolling window, so the 75th percentile moves gradually. Checking every day only produces anxiety.
Which metric is failing? Where I look first
| Failing metric | Usual causes on WordPress | Where to read more |
|---|---|---|
| LCP | No page cache or slow TTFB, lazy-loaded hero image, oversized images on mobile, render-blocking CSS and JavaScript | LCP in WordPress |
| INP | Heavy builder or plugin JavaScript, third-party tags (chat, analytics, ads), very large DOM | INP in WordPress |
| CLS | Images and embeds without dimensions, font swaps, banners injected above content, ads without reserved space | CLS in WordPress |
When LCP fails, I always check TTFB in the same field section. It is not a Core Web Vital, but a first byte above 0.8 seconds eats most of the LCP budget before the browser can even request the image. The TTFB guide for WordPress covers that.
Why is the origin failing when my page passes?
The origin result is an aggregate of every page on the site that gets traffic. A fast home page does not help if most visits land on slow product pages or old blog posts with heavy embeds. If the origin fails and your tested URL passes, the problem lives in other templates. Search Console is where you find them.
The reverse also happens. A specific URL fails while the origin passes, usually because that page has a unique element: a video hero, a huge table, a form plugin that only loads there.
What does not fix a failed assessment
A few things I see people try that do not change field data, or change it the wrong way:
- Chasing the Lighthouse score. Deferring every script until the score hits 100 can make INP worse once real users start clicking, because all that JavaScript runs at the moment they interact.
- Testing only the home page. The assessment for the origin depends on where traffic actually goes.
- Installing a second optimization plugin on top of the first. Two plugins minifying, combining and delaying the same files tend to break things, and the overlap is hard to debug.
- Re-running PageSpeed Insights hoping for a different verdict. The field section will not change between runs on the same day.
How long does it take to pass after a fix?
If the fix is right, the 75th percentile starts improving as new visits replace old ones in the 28-day window. A full turnover takes about four weeks. Search Console validation runs on a similar timescale. Traffic matters too: a low-traffic URL may drop out of URL-level data and be judged on the origin instead.
During that wait I watch real user monitoring if the site has it. The web-vitals library from Google can report LCP, INP and CLS from your own visitors, so you see the trend daily instead of waiting for CrUX.
Frequently asked questions
Does a failed assessment hurt my rankings?
It can be a small factor, but relevance comes first. I explain how Google uses page experience in are Core Web Vitals a ranking factor? A failed assessment is a better reason to worry about bounce and conversion on slow phones.
My page shows “no data”. Did it fail?
No. “No data” means CrUX does not have enough visits for that URL. Check the origin view. If that is empty too, there is no assessment at all, and you need lab tests plus your own field measurement.
Should I fix mobile or desktop first?
Mobile, in almost every case. It is usually the worse of the two, and fixes that help a slow phone tend to help desktop too.
For the full fix order across all three metrics, see Core Web Vitals for WordPress. If your assessment keeps failing and you want someone to find the cause in the field data, that is what I do as a Core Web Vitals expert, and the WebOption team can implement the fixes when you need hands on the code.