What are the Core Web Vitals thresholds?

Largest Contentful Paint should be 2.5 seconds or less, Interaction to Next Paint 200 milliseconds or less, and Cumulative Layout Shift 0.1 or less. These are measured at the 75th percentile of real page visits, separately for mobile and desktop, using field data from Chrome users.

Are Core Web Vitals a ranking factor?

Google uses page experience signals, including Core Web Vitals, in ranking, but describes relevance and content quality as more important. In practice they work as a tie-breaker between similar pages and a floor that very poor experiences fall below. Their commercial impact on conversion is usually larger.

What replaced First Input Delay?

Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. INP is stricter: it considers responsiveness across interactions throughout the visit, not only the first one, so script-heavy pages that respond slowly later in a visit are now measured.

Why does PageSpeed Insights show different numbers from Search Console?

PageSpeed Insights shows both field data, from real users over recent weeks, and lab data from a single simulated test. Search Console shows field data grouped across similar URLs. Lab and field figures often differ because real devices and networks vary. Field data is what counts.

My site has little traffic. How do I see Core Web Vitals?

Low-traffic pages may lack enough field data to report. Search Console may group them with similar pages or show nothing. Use lab tests to find obvious issues, consider adding real-user monitoring through your analytics, and focus on fixing templates rather than individual pages.

Core Web Vitals Explained: LCP, INP and CLS in Plain English

What Core Web Vitals measure

Speed used to be measured with technical timings that meant little to visitors. Core Web Vitals try to measure what people actually feel: how quickly the main content appears, how quickly the page responds when they tap or click, and whether things jump around while they read.

There are three metrics. Google can change the set over time; Interaction to Next Paint replaced First Input Delay in March 2024. The principle is stable: measure experience from the user's side, using data from real visits.

Metric	What it measures	Good	Poor
Largest Contentful Paint (LCP)	Time until the largest visible content element, usually a hero image or heading block, has rendered	2.5 seconds or less	More than 4 seconds
Interaction to Next Paint (INP)	How quickly the page visibly responds to interactions across the whole visit	200 milliseconds or less	More than 500 milliseconds
Cumulative Layout Shift (CLS)	How much visible content moves unexpectedly while the page is in use	0.1 or less	More than 0.25

Between good and poor sits 'needs improvement'. To pass, a page or group of similar pages must meet the good threshold at the 75th percentile of real visits, separately on mobile and desktop. In plain terms: three in four visits must have a good experience.

Field data versus lab data

This distinction causes more confusion than any other in performance work. Field data comes from real Chrome users visiting your site, aggregated in the Chrome User Experience Report and shown in Search Console and PageSpeed Insights. It is what Google uses for page experience. Lab data comes from a simulated test run on demand, such as a Lighthouse report.

Fig. 01 · Comparison

Tap to explore

Field data and lab data

Field dataLab data

SourceReal users on real devices and networksA simulated device and connection

Used for page experienceYesNo

Speed of feedbackRolling window of recent weeksInstant

Best forJudging actual experienceDiagnosing causes and testing fixes

LimitationNeeds enough traffic to reportMay not match real conditions

Use lab tests to diagnose and verify fixes; use field data to judge whether users, and Google, see an improvement.

A common trap is chasing a perfect lab score while field data stays poor, or celebrating a good lab score while real users on mid-range phones and patchy mobile networks suffer. In markets with many budget Android devices, the gap can be large. Trust the field.

Field data also depends on who your visitors are. A site whose audience is mostly on fast office connections may pass easily, while the same template serving customers in smaller towns on older phones may struggle. Segment real-user data by device and region where your analytics allows, and optimise for the customers you actually have.

How much do Core Web Vitals matter for SEO?

Google has said page experience signals, including Core Web Vitals, are used in ranking, and also that great content relevant to the query will generally outrank a faster page with less relevant content. Our reading: Core Web Vitals act more like a tie-breaker and a floor than a lever. Failing badly is a disadvantage; going from good to excellent rarely moves rankings.

The stronger case is commercial. Slow loading, sluggish taps and shifting layouts frustrate people, and frustrated people leave or mis-click. Improving experience usually helps conversion, which is reason enough on key templates regardless of rankings. See website speed for the conversion view.

Myth vs reality

Core Web Vitals myths

Improving LCP: getting the main content on screen

LCP is usually dominated by one element, often a large image or a block of text waiting for a font. Find that element for each key template, then remove everything that delays it.

Serve the hero image in a modern format at the right size, and do not lazy-load it.
Give the LCP resource high priority and make sure it is discoverable in the initial HTML, not injected by script.
Reduce server response time with caching and a content delivery network.
Remove or defer render-blocking scripts and styles that are not needed for the first view.
Avoid slider carousels at the top of the page; they often delay the largest element.

Improving INP: responding when people tap

INP suffers when the browser's main thread is busy running JavaScript, so it cannot respond to a tap or keypress. Heavy frameworks, large bundles and third-party scripts are the usual causes. Because INP considers interactions throughout the visit, problems after the page loads count too.

Audit third-party scripts: analytics, tag managers, chat, heatmaps, A/B testing and ad tags. Remove what nobody uses.
Break long tasks into smaller pieces so the browser can respond between them.
Give immediate visual feedback on interaction, then do expensive work afterwards.
Reduce the amount of JavaScript shipped, especially on content pages that barely need it.

Improving CLS: keeping the page still

Layout shift happens when something appears or resizes after nearby content has rendered, pushing it out of the way. Images without dimensions, late-loading adverts and banners, and web fonts swapping in are the familiar culprits.

Set width and height, or an aspect ratio, on images, videos and embeds.
Reserve space for ad slots, cookie notices and promotional bars before they load.
Avoid inserting content above existing content unless the user asked for it.
Use font loading strategies that minimise size changes when the web font arrives.

A working cycle for performance

Fig. 02 · Cycle

Tap to explore

The Core Web Vitals improvement loop

Read field data

Field data lags by weeks, so expect a delay between shipping a fix and seeing it in Search Console.

The last step matters most. Sites rarely stay fast by accident: every new script, widget and campaign banner adds weight. A simple performance budget, a limit on page weight and script count checked before release, protects the gains. Make it part of technical SEO governance.

Compare scenarios

Who owns which part

Controls many of the heaviest elements on a page.

Hero images and video
Tracking and advertising tags
Pop-ups, chat and promotional bars

Where to look first

Open the Core Web Vitals report in Search Console. It groups URLs with similar issues, which usually means similar templates. Start with the groups that include your highest-value pages, such as product, category, service and landing templates, rather than the groups with the most URLs.

Then pick one representative URL per group and run it through a lab tool to find the specific cause: which element is the LCP, which scripts create long tasks, what shifts. Fix the template, verify in the lab and wait for the field data to follow. Resist the temptation to start with the home page; it is often the least representative page on the site.

Finally, set expectations with stakeholders. A good Core Web Vitals result removes a disadvantage and improves the experience for real customers. It is worth doing for those reasons. It is not a substitute for relevance, content quality or authority, and it should never be sold internally as a ranking cure.

Key takeaways

01Core Web Vitals measure loading (LCP), responsiveness (INP) and visual stability (CLS) from real users.
02Passing means three in four real visits meet the good threshold for each metric.
03Judge success on field data; use lab tools to diagnose and verify.
04Vitals are a modest ranking signal and a meaningful conversion factor.
05Fix issues at template level and protect gains with a performance budget.

Frequently asked

What are the Core Web Vitals thresholds?: Largest Contentful Paint should be 2.5 seconds or less, Interaction to Next Paint 200 milliseconds or less, and Cumulative Layout Shift 0.1 or less. These are measured at the 75th percentile of real page visits, separately for mobile and desktop, using field data from Chrome users.
Are Core Web Vitals a ranking factor?: Google uses page experience signals, including Core Web Vitals, in ranking, but describes relevance and content quality as more important. In practice they work as a tie-breaker between similar pages and a floor that very poor experiences fall below. Their commercial impact on conversion is usually larger.
What replaced First Input Delay?: Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. INP is stricter: it considers responsiveness across interactions throughout the visit, not only the first one, so script-heavy pages that respond slowly later in a visit are now measured.
Why does PageSpeed Insights show different numbers from Search Console?: PageSpeed Insights shows both field data, from real users over recent weeks, and lab data from a single simulated test. Search Console shows field data grouped across similar URLs. Lab and field figures often differ because real devices and networks vary. Field data is what counts.
My site has little traffic. How do I see Core Web Vitals?: Low-traffic pages may lack enough field data to report. Search Console may group them with similar pages or show nothing. Use lab tests to find obvious issues, consider adding real-user monitoring through your analytics, and focus on fixing templates rather than individual pages.

Published by Fabulous.Media, a network of specialist marketing agencies. Updated 9 October 2026. Platform features change often; check current official documentation before acting on platform-specific detail.