Core Web Vitals: the three metrics, the thresholds, and how to fix each failure

Core Web Vitals are three metrics Google uses to describe the experience of a real page load. Largest Contentful Paint (LCP) measures loading, Interaction to Next Paint (INP) measures responsiveness, and Cumulative Layout Shift (CLS) measures visual stability. A page passes when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, measured at the 75th percentile of real visits over a 28 day window, with mobile and desktop assessed separately. INP replaced First Input Delay as the responsiveness metric in March 2024.

This page covers what each metric measures, the difference between field and lab data, how to read the Core Web Vitals report in Search Console, and the usual cause behind each kind of failure.

The three metrics and their thresholds

Metric	What it measures	Good	Needs improvement	Poor
LCP	How long until the largest element in the viewport, usually a hero image, video poster or block of text, is painted	2.5s or less	2.5s to 4.0s	Over 4.0s
INP	The latency of the slowest interaction on the visit, from tap or click or key press to the next frame being painted	200ms or less	200ms to 500ms	Over 500ms
CLS	The largest burst of unexpected layout movement during the visit, as a unitless score	0.1 or less	0.1 to 0.25	Over 0.25

The 75th percentile matters as much as the number. Three quarters of your visits have to be inside the good band, so the slow quarter of your audience, older phones on mobile data, is what decides the result. Google's own reference pages on LCP, INP and CLS hold the definitions.

Field data and lab data answer different questions

Two kinds of number get called a Core Web Vitals score, and mixing them up is the most common reason teams argue about whether a page is fixed.

• Field data comes from real Chrome users and is collected in the Chrome User Experience Report. It is what Search Console shows and what the assessment is based on. It is a rolling 28 day view, so it moves slowly after a fix and it needs enough traffic to exist at all.
• Lab data comes from a single simulated load, usually Lighthouse inside PageSpeed Insights or Chrome DevTools. It is repeatable and immediate, which makes it the right tool for diagnosis and for checking a fix before release.

So a page can show a high Lighthouse score and still fail the assessment, because one test on a fast connection is not the slow quarter of your real audience. Use lab data to find the cause and prove the fix, and field data to decide whether the page passes.

How to read the Search Console report

The Core Web Vitals report has a mobile tab and a desktop tab, and they frequently disagree. Start with mobile.

• It reports URL groups, not single URLs. Google bundles pages that behave alike, usually meaning pages from the same template, and the example URLs are samples from the group.
• Each group is labelled poor, needs improvement or good, with the metric that caused the label.
• That grouping is useful: it tells you to fix a template once rather than a hundred pages individually.
• When you ship a fix, open the issue and use Validate fix. Google re-measures over the following 28 days, so expect the report to confirm a change about a month after release, not the same week.

A practical habit: note the group, open two or three of its example URLs in PageSpeed Insights, and work from the lab diagnostics there.

LCP: the usual causes

LCP breaks into four parts, and finding which part is large tells you what to fix: time to first byte, the delay before the LCP resource starts downloading, how long it takes to download, and the delay between it arriving and being painted.

• Slow server response. Uncached dynamic pages, a distant origin, heavy database work on render. Fix with caching, a CDN and faster origin work.
• The hero image is discovered late. It is referenced in CSS, injected by JavaScript, or lazy loaded. Put it in the HTML, load it eagerly, and raise its priority.
• Render blocking CSS and JavaScript. Large stylesheets and synchronous scripts in the head delay the first paint. Inline what the top of the page needs and defer the rest.
• Oversized images. A 2MB photograph scaled down in the browser. Serve a modern format at the size it is displayed.
• Client side rendering of main content. The text appears only after JavaScript runs. Server render or pre render the part of the page people see first.

For the hero image, this is usually the whole fix:

<img src="/hero-1200.webp" width="1200" height="630" alt="..." fetchpriority="high">

No lazy attribute on it, explicit dimensions so nothing moves, and a high priority so it is fetched before decorative assets.

INP: the usual causes

INP fails when the main thread is busy at the moment somebody taps. The causes are almost always JavaScript.

• Long tasks that block the main thread for more than 50 milliseconds, often during hydration or on first interaction.
• Third party tags. Chat widgets, consent banners, analytics and A and B testing tools that execute on load. Audit the tag list and remove what nobody reads.
• Event handlers doing heavy work before the next frame. Update the UI first, then do the work, yielding back to the browser in between.
• A very large DOM, which makes every style and layout recalculation expensive. Virtualise long lists.
• Expensive rendering after input, such as re rendering a whole page component when a filter changes.

Measure it on the interactions people actually use: the menu, the filter, the add to cart button, the search box.

CLS: the usual causes

• Images and video without width and height attributes or an aspect ratio in CSS, so the browser reflows when they arrive.
• Ads, embeds and iframes with no reserved space. Give the slot a fixed minimum height.
• Content injected above existing content: cookie notices, promotional bars, personalisation banners. Reserve the space or overlay it instead of pushing the page down.
• Web fonts swapping and changing text metrics. Preload the font, use a size adjusted fallback, and keep font-display sensible.
• Animating properties that trigger layout. Animate transform and opacity instead.

CLS is measured across the whole visit, including scrolling, so test by scrolling the page the way a reader would rather than only looking at the first screen.

Where Core Web Vitals sit in ranking

Core Web Vitals are part of what Google describes as page experience, and content relevance still does the heavy lifting. Treat these metrics as something that helps a strong page win a close contest, and as a direct lever on conversion. That second effect is usually worth more than the ranking effect.

This page covers the three Core Web Vitals, their thresholds and their causes. For the wider question of how much speed work is worth doing and in what order, see a guide to site speed and SEO. For crawling and indexing problems, those are a separate diagnosis.

What people ask about Core Web Vitals

Why does PageSpeed Insights disagree with Search Console?

They are showing different things. The top of the PageSpeed Insights result is field data from real visits over 28 days, which is what Search Console reports. The lower part is a single Lighthouse run in a simulated environment. Use the lab section for diagnosis and the field section for the verdict.

My report says there is not enough data. What now?

That means the page or group has too few Chrome visits to form a field sample. Work from lab diagnostics on your main templates, add a small real user monitoring script so you build your own field history, and fix the causes listed above.

How long after a fix should the report change?

The assessment uses a 28 day rolling window, so expect the curve to start moving within a week or two of release and the group to settle about a month after. Click Validate fix so Google re-checks on its own schedule.

What happened to First Input Delay?

INP replaced it as the responsiveness metric in March 2024, and FID was retired from Google's tools later that year. INP is stricter in a useful way: it looks at the full latency of the slowest interaction rather than only the delay before the handler starts.

Do I need a perfect 100 score?

No. The target is the three field thresholds at the 75th percentile on mobile. Chasing the last few Lighthouse points usually costs more engineering time than it returns, while a 2MB hero image or four unused tag manager scripts are worth fixing today.

A measurement this report leaves out

Lab and field data tell you how a page behaves in a browser. Neither says whether an assistant visiting the same page can read it. A fast page that builds its text with script after load, or hides it behind a consent wall, can look excellent here and arrive empty to a crawler that does not run script.

Check by asking an assistant a question your page answers and see whether the page is cited. AI Knows Us lists the sources under each answer, so a fast page that never gets cited stands out from the ones that do.