Core Web Vitals Assessment Failed? How to Find and Fix the Cause

The red "Core Web Vitals Assessment: Failed" banner in PageSpeed Insights is a verdict on the last 28 days of real visits to your site. The test you just ran plays no part in it, and that one fact explains most of the confusion around it. If you're searching for core web vitals assessment failed how to fix, start by finding out which metric failed and on which pages, because the three metrics break for different reasons and need different fixes.

What "failed" actually means

Google judges the assessment on field data from the Chrome UX Report: timings collected from real Chrome users who visited your page, pooled over a rolling 28-day window. It looks at the 75th percentile, so three out of four visits need to be in the good range for a metric to count as good. A fast experience on your office Wi-Fi doesn't help if a quarter of your visitors are on slow phones.

The good thresholds are:

• Largest Contentful Paint (LCP): 2.5 seconds or less. How long the biggest image or text block above the fold takes to appear.
• Interaction to Next Paint (INP): 200 milliseconds or less. How long the page takes to respond visibly after a tap, click or key press. INP replaced First Input Delay as a Core Web Vital in March 2024.
• Cumulative Layout Shift (CLS): 0.1 or less. How much the layout jumps around while people are reading.

To pass, every metric needs to be good. One bad metric fails the whole assessment, even if the other two are comfortably green. Mobile and desktop are assessed separately, and mobile is usually the one that fails.

Find the failing metric and the page groups

PageSpeed Insights has two halves that people mix up. The top section is field data, the real-user numbers that decide pass or fail. The bottom section is lab data from Lighthouse, a single simulated load on a throttled device. The two can disagree, sometimes badly. A Lighthouse score of 95 sitting under a failed assessment is common, and it isn't a bug.

Lighthouse can't measure INP at all in a standard page load, because nobody is clicking anything. It reports Total Blocking Time as a stand-in. So if INP is your failing metric, the lab score may look fine while real users are waiting on every tap.

Here's the order we work in:

1. Open the Core Web Vitals report in Search Console and pick mobile. It lists issues such as "LCP issue: longer than 2.5s (mobile)" with the number of URLs affected.
2. Click into an issue. Search Console groups similar URLs together, so you'll see groups like product pages or blog posts with an example URL for each. A group's status comes from its slowest metric.
3. Run one example URL from each failing group through PageSpeed Insights and read the field data at the top.
4. If the page doesn't have enough traffic for its own field data, PageSpeed Insights falls back to data for the whole origin. Note when that happens, since a fix on one page won't move an origin-wide number much.
5. Use the Lighthouse diagnostics at the bottom, plus the Performance panel in Chrome DevTools, to find the cause.

Templates matter more than individual pages. If every product page fails LCP, the cause is almost always in the product template, and one fix clears the whole group.

Fixing LCP

On most sites, the LCP element is the hero image. Sometimes it's a large heading, and that's worth checking first in the Lighthouse diagnostic called "Largest Contentful Paint element", because the fix depends on which one it is.

For a hero image, work through these:

• Size it for the screen. A 3,000-pixel-wide photo shown at 400 pixels on a phone is pure waste. Serve responsive sizes with srcset.
• Use a modern format. WebP or AVIF files are usually far smaller than the same image as a JPEG or PNG.
• Never lazy-load it. Lazy loading tells the browser to wait, which is the opposite of what you want for the biggest thing on screen.
• Give it priority with fetchpriority="high" or a preload hint, so the browser requests it before scripts and below-the-fold images.
• Avoid hero sliders that build themselves with JavaScript. The image can't appear until the script runs.

Then look at the server. If the HTML itself arrives late, everything after it is late too. Slow server response usually comes from uncached pages being rebuilt on every request, a database query doing too much, or hosting far from your visitors. Page caching and a CDN fix most of it.

Render-blocking CSS and JavaScript come next. Every stylesheet and synchronous script in the head has to download before the page can paint. Inline the small amount of CSS needed for the top of the page, load the rest without blocking, and add defer to scripts that don't need to run first.

Fonts can hold up a text-based LCP. Self-host them, load only the weights you use, preload the main one and set font-display so text shows in a fallback font instead of staying invisible.

Fixing INP

Picture a shopper tapping "Add to cart" and nothing happening for half a second. That's an INP problem, and the cause is nearly always JavaScript hogging the browser's main thread. While a long task is running, the browser can't respond to the tap or paint the result.

Record an interaction in the Chrome DevTools Performance panel and look for long tasks, which show up flagged in red. Then trace them back to the script responsible. The usual culprit is a mix of the site's own code doing too much at once and third-party scripts nobody remembers adding.

For your own code, ship less JavaScript and split it so each page loads only what it needs. Break big chunks of work into smaller pieces and yield back to the browser between them, so a tap can be handled in the gap. Do the visible part of an interaction (opening the menu, showing a spinner) before the expensive part (recalculating totals, sending analytics).

Third-party scripts are often the bigger problem. Tag managers stuffed with old tags, heatmap tools, A/B testing scripts, chat widgets and review widgets all run on the same main thread as your buttons. Chat widgets are a frequent offender because they load a whole application on every page view. Replace the widget with a plain button that loads the chat only when someone clicks it. Review widgets can usually wait until the visitor scrolls near them. And remove any tag you can't name a current use for.

Fixing CLS

Layout shift has a short list of usual suspects.

Images and videos without dimensions are the classic one. Without width and height attributes (or a CSS aspect ratio), the browser reserves no space, then shoves the text down when the image arrives. Add the dimensions to every image and embed.

Font swaps cause smaller shifts that add up. When the web font replaces the fallback, the text reflows if the two fonts have different widths. Matching the fallback's metrics to the web font, which tools like next/font do automatically, removes most of it.

Then there's anything injected after the page loads: cookie banners pushed in at the top, promo bars, "free shipping" strips, ad slots and newsletter pop-ins that sit in the page flow. Reserve space for them in the layout, or overlay them so they don't push content. If you animate things, move them with CSS transforms, which don't count as layout shifts.

Why the fix doesn't show up straight away

You ship the fix, rerun PageSpeed Insights, and the banner still says failed. That's expected. The field data covers the previous 28 days, so the day after a fix you're looking at 27 days of old, slow visits and one day of new ones. The number improves gradually and can take up to 28 days to fully reflect the change.

Use the Lighthouse lab result to confirm the fix worked on the day you ship it. Then, in Search Console, click "Validate fix" on the issue so Google tracks the affected URLs over the following weeks. Resist the urge to keep changing things during that window, or you won't know which change helped.

When the platform is the bottleneck

Sometimes you do everything above and the scores barely move. That usually means the slowest code on the page is code you don't control. On hosted platforms and page-builder themes, the theme's scripts, the platform's own scripts and every installed app or plugin load on each page, and you can only trim around the edges. To be fair to Shopify, its servers and CDN are fast; the weight usually comes from themes and apps stacked on top.

We wrote up how that plays out in our Next.js vs Shopify Core Web Vitals comparison. The short version: on a hand-coded site, you decide what JavaScript ships, so the fixes above are fully in your hands. The sites we build are made to pass Core Web Vitals from launch. If yours keeps failing and you'd like us to look at the cause, send us a message through the contact form.

Questions people ask

How long does it take to pass the Core Web Vitals assessment after a fix?

Up to 28 days, since the assessment uses a rolling 28-day window of real-user data. Pages with more traffic tend to show the change in the trend sooner.

Why does Lighthouse give me a high score when the assessment failed?

Lighthouse runs one simulated load in a lab. The assessment uses real visits from real devices and networks at the 75th percentile. They measure different things and can disagree.

Does a failed assessment hurt my rankings?

Core Web Vitals are part of Google's page experience signals, but relevance to the search matters far more. Treat a fail as a conversion problem first; slow pages lose buyers whatever the ranking effect.

Why does PageSpeed Insights say there's no field data for my page?

The Chrome UX Report only includes pages with enough real Chrome visits. Low-traffic pages fall back to origin-level data, or show none at all for small sites.

Which should I fix first, LCP, INP or CLS?

Whichever is failing on the page group with the most traffic. On mobile store pages that's often LCP from the hero image or INP from third-party widgets.