Core Web Vitals assessment failed? How to fix LCP, INP and CLS

Short answer: A failed Core Web Vitals assessment means that at least one of three metrics misses its threshold for real visitors: LCP (loading) should be 2.5 seconds or less, INP (responsiveness) 200 milliseconds or less and CLS (visual stability) 0.1 or less, each measured at the 75th percentile. Find the failing metric in field data from real visitors, not in the lab score, and fix that one first. Google says its ranking systems use Core Web Vitals, but good values do not guarantee a top position.

What does a failed Core Web Vitals assessment mean?

Core Web Vitals are the part of Google's Web Vitals initiative that applies to every web page. web.dev names three metrics, one for each aspect of the experience:

The values are judged at the 75th percentile of page loads, separately for mobile and desktop. In plain words: for three out of four visits the value must be good, and phones and desktop each get their own verdict. web.dev tells tools to count a page as passing if it meets the targets at the 75th percentile for all three metrics. One red metric is therefore enough to fail.

A detail at the edge: web.dev says INP and CLS must be "or less", while Google's Search documentation says "less than 200 milliseconds" and "less than 0.1". Aim clearly below the line and the difference does not matter.

One change to know about: INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, as the web.dev announcement says. A guide that still lists FID is out of date. We read all pages named in this article on 4 November 2026; web.dev's overview was last updated on 31 October 2024.

Do Core Web Vitals affect Google rankings?

Yes, according to Google, but it gives no weight. Google's page on page experience says: "Core Web Vitals are used by our ranking systems." It recommends good values for success in Search, and it adds that there is no single page experience signal.

The same page is just as clear about the limits. Good results in the Core Web Vitals report of Search Console or in third-party tools "doesn't guarantee that your pages will rank at the top of Google Search results". It also says that chasing a perfect score only for SEO may not be the best use of your time. Google always tries to show the most relevant content, even when the page experience is poor.

What Google does not publish is how much weight the metrics carry, so we name no number either. Our reading, not a fact from Google: treat the thresholds as a quality bar for your visitors, get all three into "good", and then put your time back into content. Google's core ranking systems generally evaluate content page by page, so check each type of page that matters.

Lab data or field data: which one counts for Core Web Vitals?

The assessment is based on field data: measurements from real visits. Google's Chrome User Experience Report (CrUX) collects them from real Chrome users; PageSpeed Insights and the Core Web Vitals report in Search Console show them. According to web.dev, a CrUX report covers a 28-day period.

Lab data comes from loading the page once in a controlled setup: one device, one network, one location. That is ideal for finding causes and for testing a fix before release, but the LCP guide cautions that “lab tests alone may not be entirely representative”. When the two disagree, the LCP guide says to concentrate on the real user data first. They differ for good reasons:

• The LCP element can differ. A lab run always finds the same element. Real visits see other screen sizes, logged-in content or A/B tests.
• INP needs real people. Lighthouse and other lab tools load a page without anyone clicking, so they cannot measure INP. Total Blocking Time (TBT) is the lab stand-in; improvements to TBT may improve INP.
• CLS keeps counting after loading. Lab runs mostly see the load itself. In the field, content that appears while visitors scroll can shift the layout too.
• Caches help real visitors. Lab tests usually start with a cold cache, while returning visitors and the back/forward cache load pages faster.

How to read your numbers in four steps:

1. Run your address in PageSpeed Insights. The section "Discover what your real users are experiencing" holds field data; "Diagnose performance issues" holds the lab run.
2. Check what you are looking at. Switch between mobile and desktop and between the single URL and the whole origin. If a URL has too little data, PageSpeed Insights shows origin data instead.
3. Find the metric over its line at the 75th percentile. That is your failing metric. With too little traffic there is no field data; use the lab values and measure your own visitors with web.dev's small web-vitals library.
4. Open the lab diagnostics for that metric to see the cause, and fix that one thing first.

How to fix LCP: the largest element appears too late

LCP reports when the largest image, text block or video in the visible area is rendered. web.dev's LCP guide splits the time into four parts that add up to the LCP: the server response (TTFB), the delay before the browser starts loading the LCP resource, the time that resource needs to load, and the delay until the element is rendered. Find the biggest part before you change anything: shrinking one part can just move time into another. A compressed image does not help if the element stays hidden until a script has loaded.

The Chrome team's list of the most effective fixes includes these:

1. Make the LCP image easy to find and give it priority. Use a normal <img> with src or srcset, not a data-src that needs JavaScript. Prefer server-side rendering over building the page only in the browser. Add fetchpriority="high" and remove loading="lazy" from this one image.
2. Shorten the server response. Serve and cache content close to your visitors, usually with a CDN.

The same tag handles LCP and, through its size, CLS:

<!-- Main image: in the HTML, high priority, not lazy, with a size -->
<img src="/img/hero.webp" width="1200" height="630" alt="Short description" fetchpriority="high">

<!-- Images further down the page: lazy loading is fine here -->
<img src="/img/team.webp" width="600" height="400" alt="Short description" loading="lazy">

How to fix INP: the page reacts too slowly

INP watches every click, tap and key press during a visit and reports roughly the slowest one (for pages with very many interactions, outliers are ignored). Hovering and scrolling do not count. According to the INP guide, each interaction has three parts: the input delay, the time the event handlers run, and the delay until the next frame is shown. The usual culprit is JavaScript keeping the main thread busy. The Chrome team's top fixes:

1. Break up long tasks. A task over 50 milliseconds blocks the main thread. Hand control back often: scheduler.yield() where the browser supports it, setTimeout as the older way.
2. Ship less JavaScript. Find unused code with the coverage tool in Chrome DevTools, split code that is not needed at first, and clean out old tags in your tag manager.
3. Avoid large rendering updates. Keep the DOM small, avoid forced layout and use CSS containment for content outside the screen.

How to fix CLS: the layout jumps

CLS has no unit. It combines how much visible content moved with how far it moved. In the field it counts over the whole visit, but shifts within 500 milliseconds of a user interaction are left out. web.dev's CLS guide lists the common causes: images without dimensions, ads, embeds and iframes without dimensions, dynamically injected content and web fonts. What helps:

• Reserve space. Give images and videos width and height, or use the CSS aspect-ratio property. For content of unknown size, a sensible min-height beats the default of zero.
• Animate with transform. Animating top, left or margin shifts the layout. Cookie banners that slide in are a typical case.
• Let the back/forward cache work. It restores fully rendered pages. Common blockers are no-store caching directives and unload event listeners.
• Handle web fonts. font-display: optional, matching fallback fonts with size-adjust and preloading critical fonts all reduce font-related shifts.

How SEOgrinder checks Core Web Vitals

SEOgrinder is our tool; we build it. Enter a public address at SEOgrinder and the speed numbers come from Google PageSpeed Insights, for phones and for desktop. The Core Web Vitals card shows LCP and CLS from the Lighthouse lab run and INP from real visitors, and a separate box shows real user data from the last 28 days. If Google has too little data for the page, the report says so instead of guessing. Tasks such as "Real visitors on phones wait … for the content" name the metric, the value and the fix. A slow server response, which feeds into LCP, gets its own task.

Limits: SEOgrinder reads Google's numbers and does not replace your own real-user monitoring. It does not measure rankings. If Google's daily quota for the speed measurement is used up, the report comes without it.

Common mistakes

• Trusting the lab score alone. It cannot measure INP and can look different from what visitors experience. Start with the real-visitor values.
• Checking only one device. Mobile and desktop are judged separately.
• Lazy-loading the main image. loading="lazy" on the LCP image adds delay.
• Leaving out image sizes. Without width and height the browser cannot reserve space.
• Fixing the wrong part of LCP. Compress images only after the breakdown shows loading time is the problem.
• Expecting an instant result. Field data covers 28 days, so it changes gradually. Check the lab run right after a fix, and the real-visitor numbers in the following weeks.

FAQ

What is a good Core Web Vitals score?

There is no single score. A page passes when LCP is 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less at the 75th percentile. The 0 to 100 number you may know from Lighthouse is a lab figure and a different thing.

Why does PageSpeed Insights show no real-user data for my site?

Usually there are too few visits for CrUX to report. web.dev suggests adding your own measurement of real visitors in that case. Until then, work from the lab values.

Do I need a perfect score?

No. Passing is the goal. Google itself says that chasing a perfect score only for SEO reasons may not be the best use of your time.

Your next step

Run your most important page through SEOgrinder, open the Core Web Vitals card and look at the real-visitor values first. Fix the one metric that fails, press Check again and read the lab values. The wider picture is in our SEO audit checklist.

Keep reading

• How to rank higher on Google: 3 things Google itself recommends
• Internal linking: how to find orphan pages and fix click depth
• JSON-LD structured data: copy-ready examples you can test