“Core Web Vitals Assessment: Failed” means that real Chrome users visiting your page (or your whole site) had a poor or mediocre experience on at least one of three metrics over the last 28 days. PageSpeed Insights passes the assessment only when the 75th percentile of LCP, INP and CLS all sit in the Good range. One metric in orange or red is enough to fail.
So the banner isn’t about your lab score. It’s a verdict on field data from the Chrome UX Report (CrUX). To pass, you find the one metric that failed, on the device that failed, and fix the template behind it.
In my experience, a core web vitals assessment failed banner shows up on most small-business sites I audit. It looks scary. It isn’t. Below is the exact path I follow to read it, fix it and know when the fix has landed, and it works whether you run WordPress, Shopify or a custom build.
Why Is the Core Web Vitals Assessment Failed on My Page?
The rule comes straight from Google’s PageSpeed Insights documentation. When there’s enough data for all three metrics, the page “passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good.” Anything less is a fail.
The Good thresholds are published on web.dev: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. The 75th percentile part matters a lot. Three out of four real visits must hit each target, which means your slowest quarter of visitors decides the outcome.
There are two quirks worth knowing. If INP has too little data, PageSpeed Insights can still pass you on LCP and CLS alone. If LCP or CLS lacks data, there’s no assessment at all.
The Four Things That Change the Answer
Before touching any code, I check four variables. Each one sends the fix down a different road.
- Which metric failed. LCP, INP and CLS have completely different causes, so the colored bar under each metric is the first thing to read.
- Mobile or desktop. PageSpeed Insights reports each device separately. Mobile usually fails first because real phones and networks are slower.
- URL data or origin data. If your page doesn’t have enough traffic, PageSpeed Insights falls back to data for the whole origin. Then you’re looking at a site-wide average, not your page.
- How long ago you changed something. Field data is a rolling 28-day window, so recent fixes are only partly counted.
Get these four right and the rest is ordinary debugging. Skip them and you can spend a month fixing a page that was never the problem, which is exactly what happens when someone optimizes one blog post while the origin-level number reflects the whole shop.
The Main Path: One Metric Fails on Mobile
This is the scenario I meet most. Desktop passes, mobile fails, and one metric sits in orange or red while the other two look perfectly healthy, which tempts people to blame the whole site when the fault usually lives in a single template.
Start by opening PageSpeed Insights, running the URL and staying on the Mobile tab. Look at the “Discover what your real users are experiencing” section and note which metric carries the poor label. Then check whether the toggle says “This URL” or “Origin”, because that tells you how much of the site the number represents.
If only LCP fails, then the problem is loading. It’s usually a heavy hero image, a slow server or render-blocking CSS.
If only INP fails, then the problem is JavaScript on the main thread. Taps lag.
If only CLS fails, then something moves after the page starts rendering. Think images without dimensions, late ads or injected banners, and use the DevTools steps in finding and fixing layout shift to catch which one.
If two or three fail, then start with the one furthest into the red, because it usually shares a cause with the others. A bloated page builder can hurt LCP and INP at the same time.
Once you know the metric, scroll down to the lab diagnostics on the same report. The lab section won’t tell you whether you pass, but it will point at the exact image, script or element causing trouble.
Why Is the Lab Score Green While the Assessment Fails?
This one confuses nearly every client I work with. Fair enough.
The big 0 to 100 number comes from Lighthouse, a single simulated page load. Google’s docs say Lighthouse simulates “a mid-tier device (Moto G4) device on a mobile network” for mobile. Your real visitors aren’t one device on one network.
So a page can score 92 in the lab and still fail, because a chunk of your real audience uses older phones, weaker connections or interacts with the page in ways a lab test never does. INP is the classic example: a lab run doesn’t click anything, so it can’t measure INP directly.
I’ve covered the full relationship between the two numbers in my post on page speed vs Core Web Vitals. The short version for this problem: trust the field assessment, and use the lab only to find the cause.
Branch 1: The Failing Metric Is LCP
LCP measures when the largest image or text block in the viewport finishes rendering. When it fails, I work through the chain in order: server response, resource discovery, resource size, then render delay.
A slow server steals time before anything else can start, and no amount of image compression buys back the time your host already wasted before the browser even saw the HTML.
If your Time to First Byte is poor, caching and better hosting come before image work. After that, check whether the LCP element is an image the browser finds late, such as a CSS background or a lazy-loaded hero. Never lazy-load the LCP image. Give it fetchpriority="high" so the browser fetches it early.
Then shrink it. Hard. Serve a modern format like WebP or AVIF at the size the layout actually displays. A 2,400-pixel photo in a 400-pixel mobile slot is still one of the most common LCP failures I see on WordPress sites.
Improving LCP in depth is its own topic, and I’ll cover how to improve LCP in a dedicated guide. For this banner, those four checks fix most cases.
Branch 2: The Failing Metric Is INP
INP looks at how quickly the page responds to clicks, taps and key presses across the whole visit. The good line is 200 milliseconds. When INP fails, the cause is almost always too much JavaScript competing for the main thread.
My first move is an inventory. Count the third-party scripts: chat widgets, heatmaps, tag managers, social embeds, popup builders. Honestly, removing two or three unused tags fixes more INP problems than any clever code change. After that, look for long tasks in Chrome DevTools and break them up so the browser can respond between chunks.
On WordPress, the builder you use matters. Heavy page builders ship a lot of script on every page, which I compare in my Elementor vs block editor SEO breakdown. How to improve INP deserves a separate walkthrough, so I keep it to triage here.
Branch 3: The Failing Metric Is CLS
CLS adds up unexpected layout shifts. It fails when content jumps under the reader’s finger or eyes, like the classic moment when you go to tap a link and an ad loads above it so you hit the wrong thing. Good news: it’s usually the cheapest of the three to fix. When I debug CLS, I record the page load in DevTools and watch which box moves.
Set width and height on every image and video so the browser reserves space. Reserve fixed slots for ads and embeds instead of letting them push text down. Watch cookie banners and promo bars that slide in at the top, and check web fonts that swap in with a different size. How to fix CLS in detail is a topic for another post, but these four account for nearly every CLS failure I’ve debugged.
What If the Page Shows Origin Data or No Data?
This branch changes everything. If the toggle shows “Origin”, your specific page didn’t have enough visits, so PageSpeed Insights used all pages on the site. Fixing this one URL may barely move that number. You need to find the templates that carry most traffic and fix those.
If PageSpeed Insights shows no field data at all, then there’s no assessment to fail. Google’s docs say that when the origin also lacks data, no real-user data appears. In that case, work from the lab metrics until the site earns enough traffic to join CrUX.
Use the Search Console Core Web Vitals Report to Find Patterns
PageSpeed Insights checks one URL at a time. The Search Console Core Web Vitals report shows the whole site, split into mobile and desktop, and it uses the same CrUX data.
Google’s help page explains that URLs are grouped by similar experience, and “the status for a URL group defaults to the slowest status assigned to it for that device type.” In other words, a group with Poor CLS and fine LCP still shows as Poor. That grouping is gold, because a failing group usually means one failing template: every blog post, every product page, every category page.
My order of work: open the mobile report, sort by the Poor issues, fix the template that covers the most URLs, then move to Need improvement. For the rest of the crawl and indexing picture, my technical SEO checklist puts speed next to everything else that matters.
How Long Until Core Web Vitals Update After a Fix?
Expect about four weeks. Sometimes less.
PageSpeed Insights reports field data “over the previous 28-day collection period,” so each day of good visits pushes out one old day of bad ones. You’ll often see the number drift in the right direction within a week or two. A full pass takes the whole window.
Search Console works on the same rhythm. Be patient.
When you click Validate Fix, Google starts a 28-day monitoring session, and the issue counts as fixed only if it doesn’t show up on any URL in that window. So don’t panic if validation still says “Started” three weeks later. That’s normal, and restarting validation only resets the clock.
One practical tip. Retest in the lab right after deploying to confirm the fix worked in principle, then leave the field data alone. Rechecking PageSpeed Insights every morning won’t speed it up.
Edge Cases That Break the Normal Path
- If desktop fails but mobile passes, then check desktop-only elements like large sliders, mega menus or wide hero videos.
- If the assessment flips between pass and fail, then you’re sitting right on a threshold. Aim well inside the Good range so normal traffic swings don’t tip it back.
- If you fixed it but traffic mix changed, then a surge of visitors from slower regions or devices can raise the 75th percentile even when your code improved.
- If a single plugin update caused the fail, then roll it back first and investigate later. Taking a backup before every update, the rule my weekly-to-yearly WordPress maintenance routine is built on, makes that rollback far less painful.
The Decision Matrix
| If this fails | And the data is | Then do this first |
|---|---|---|
| LCP only | This URL, mobile | Fix server response, then hero image priority and size |
| INP only | This URL or origin | Remove unused third-party scripts, then break up long tasks |
| CLS only | Any | Add image dimensions, reserve ad and banner space |
| Two or more metrics | Origin | Fix the highest-traffic template, often the page builder output |
| Nothing (no data) | No field data | Work from lab metrics until CrUX has data |
| Passed yesterday, failed today | Any | Check recent plugin, theme or tag changes and roll back |
Does a Failed Assessment Hurt Rankings?
Google’s page experience documentation says Core Web Vitals are used by its ranking systems, and it also says relevance comes first. So a failed banner won’t sink a page that answers the query best. It can cost you where several strong pages compete closely. In my view, the bigger loss is usually the visitors who bounce off a slow or jumpy page, rankings aside.
When to Bring In a Specialist
Some failures sit below the surface: a theme that ships render-blocking code on every page, a server that can’t cache, or an INP problem buried in a custom app. At that point you need a developer who can read a performance trace, not another plugin. If you want that handled end to end, it’s part of our technical SEO service. If you just want to know which templates fail and why, request a free SEO audit and I’ll point you at the cause.
Frequently Asked Questions
Why Does My Core Web Vitals Assessment Fail When My PageSpeed Score Is 90+?
The score is a single lab test on a simulated device. The assessment uses 28 days of real Chrome user data at the 75th percentile. Real visitors on slower phones or networks can fail a metric the lab run never sees, especially INP.
Can I Pass the Assessment Without INP Data?
Yes. Google’s PageSpeed Insights documentation says that if INP lacks sufficient data, the page passes when the 75th percentiles of LCP and CLS are both Good. If LCP or CLS lacks data, no assessment is shown.
Why Does Mobile Fail While Desktop Passes?
Mobile visitors use slower processors and less reliable connections, so LCP and INP are usually worse at the 75th percentile. Google evaluates each device type separately, so fix the mobile template first.
How Often Does PageSpeed Insights Field Data Refresh?
The field data covers a rolling 28-day collection period. A fix shows partially within days and fully after roughly four weeks. Search Console validation also runs a 28-day monitoring session.
Last updated: September 2026 by Mizanur Rahman
