Core Web Vitals: thresholds, measurement and levers

What do Core Web Vitals measure?

Search Console reports them under the name “Core Web Vitals”. They are the Web Vitals that Google applies to all pages. Each covers one facet of the experience: loading, responsiveness, visual stability (web.dev, Web Vitals, October 31, 2024).

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	Time to display the largest visible element: main image, text block, video	≤ 2.5 s	> 4 s
INP (Interaction to Next Paint)	Delay between an interaction (click, tap, key press) and the next paint, over the whole visit	≤ 200 ms	> 500 ms
CLS (Cumulative Layout Shift)	Extent of unexpected layout shifts	≤ 0.1	> 0.25

The threshold is read at the 75th percentile of page loads, with mobile and desktop kept separate (same source). In practice, three visits out of four must fall below the limit for the metric to turn green. The Search Central documentation on Core Web Vitals (December 10, 2025) uses the same targets for Google Search.

Two other indicators often appear alongside them. FCP measures the first paint (good under 1.8 s). TTFB measures server response time (good under 0.8 s). These are diagnostic metrics. They help explain a poor LCP, but they are not part of the official trio.

Are Core Web Vitals a ranking factor?

Yes, but one factor among others. Google writes it on its page experience page: “Core Web Vitals are used by our ranking systems” (Google Search Central, September 22, 2026). The same page states that good results in Search Console do not guarantee the top spot.

Google adds that Search always shows the most relevant content, even if the page experience is subpar. In practice, these signals break ties between pages of similar relevance. They do not make up for content that answers the query poorly.

The strongest argument is often user experience. A page that shifts under your finger or freezes on click loses visitors, whatever its ranking. Measure this link with conversion on your own data, as part of a conversion rate optimization approach. Market averages will not tell you.

How do you measure Core Web Vitals: field or lab?

Two families of tools coexist, and they do not answer the same question.

Data type	Tools	What it tells you	Limit
Field (real Chrome visitors)	CrUX report, top part of PageSpeed Insights, Core Web Vitals report in Search Console	What your users really experience, over a rolling 28 days	No data for a low-traffic page or site; a few days’ delay
Lab (simulation)	Lighthouse, bottom part of PageSpeed Insights, Chrome DevTools	Why a page is slow, with leads for fixes	A single simulated visit; Lighthouse does not measure INP without real interaction

Field data is what counts for rankings. The Lighthouse score out of 100 is for diagnosis. A page can show 95 in the lab and fail in the field, or the other way around (web.dev, section on measurement tools).

What does “Core Web Vitals Assessment: Failed” mean?

PageSpeed Insights shows this message when at least one of the three metrics is not good. The calculation is done at the 75th percentile, on field data. The verdict applies to the URL if it has enough traffic, otherwise to the origin (the whole site). It does not depend on the Lighthouse score shown further down.

Reading the Search Console report

The Core Web Vitals report groups similar URLs. It gives them a shared status: good, needs improvement or poor. It is used to spot a failing template, not an isolated page. To get to grips with the other reports, see our Google Search Console guide.

How do you improve LCP, INP and CLS?

LCP: display the main element faster

Google breaks LCP down into four parts (web.dev, LCP, September 4, 2025). They are the server response, the delay before the resource starts loading, the loading time itself, then the render delay. First measure which one dominates, then address it:

• slow server: page caching, CDN, lighter database queries;
• main image discovered late: place it in the initial HTML, preload it, never lazy-load it;
• heavy image: WebP or AVIF format, dimensions matching the display size;
• blocked rendering: inline critical CSS, fonts and scripts that do not delay display.

INP: respond quickly to every interaction

A poor INP almost always comes from JavaScript tying up the browser’s main thread (web.dev, INP, September 2, 2025). Break up long tasks and remove unnecessary scripts. Defer third-party scripts (chat, tags, widgets) and limit the size of the DOM. On a site built with a framework, the topic overlaps with JavaScript SEO.

CLS: stabilize the layout

Shifts come from elements that arrive without reserved space (web.dev, CLS). Specify width and height on images and videos. Reserve space for ad slots and embedded content. Do not insert a banner above content that is already displayed, and choose fallback fonts with similar dimensions.

Where should you start on an existing site?

The method used in audits fits in five steps. It avoids randomly fixing the home page while product pages fail.

1. Collect field data: Core Web Vitals report in Search Console, mobile first, then desktop.
2. Group by template: home page, category, product page, article. A template defect affects hundreds of URLs at once.
3. Diagnose in the lab: one representative URL per template in PageSpeed Insights, to identify the resource or script at fault.
4. Fix in order of return: images, browser caching, CSS and JS minification, CDN, server time, lazy loading below the fold.
5. Validate over 28 days: field data takes about a month to reflect a fix. Start validation in Search Console once the fix is live.

These metrics are only one block of a technical SEO audit. If Google does not crawl or index your pages, their speed is useless. Server response time also weighs on crawling. On large sites, it is part of the crawl budget.

To place this topic among the other crawling, indexing and performance workstreams, see the technical SEO guide.