What Are Core Web Vitals?

Core Web Vitals are three Google metrics for real-world user experience: loading speed (LCP), responsiveness (INP) and visual stability (CLS). A page is good when its LCP is 2.5 seconds or less, its INP is 200 milliseconds or less and its CLS is 0.1 or less, measured at the 75th percentile of visits.

They’re a subset of a wider set of web performance measures. According to web.dev, Core Web Vitals are the subset that apply to all web pages, should be measured by all site owners and are surfaced across Google’s tools.

This guide sticks to Google’s published documentation, with dates where they matter. Where Google hasn’t said something, we say so, and we label our own view.

What Are the Three Core Web Vitals and Their Thresholds?

The three metrics are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Each has a good band and a poor band that Google’s Chrome team publishes on web.dev.

Metric	Good	Needs improvement	Poor
LCP (loading)	2.5 seconds or less	Over 2.5 and up to 4 seconds	More than 4 seconds
INP (responsiveness)	200 ms or less	Over 200 and up to 500 ms	More than 500 ms
CLS (visual stability)	0.1 or less	Over 0.1 and up to 0.25	More than 0.25

The good and poor limits come from web.dev’s Defining the Core Web Vitals metrics thresholds, last updated on 7 May 2025. The middle band is simply everything between the two.

LCP: Largest Contentful Paint

LCP reports the render time of the largest image, text block or video visible in the viewport, relative to when the user first navigated to the page. Per web.dev’s LCP guide, candidates include images, video poster images, elements with a CSS background image and block-level text.

Only elements that have rendered count, and the largest element can change as the page loads. That’s why LCP is a load-timeline metric, not a single-file speed test.

INP: Interaction to Next Paint

INP observes the latency of every click, tap and key press during a visit and reports the longest, ignoring outliers. On pages with many interactions, it ignores one of the highest for every 50.

Hovering, zooming and scrolling aren’t counted. If a visitor never clicks, taps or presses a key, that visit produces no INP value at all.

CLS: Cumulative Layout Shift

CLS measures the largest burst of layout shifts across a page’s life. A burst, called a session window, is a run of shifts less than a second apart and capped at five seconds in total.

Each shift scores the impact fraction multiplied by the distance fraction, so a large element moving a long way scores badly. Shifts within 500 milliseconds of user input are flagged so they can be excluded.

When Did INP Replace FID?

Interaction to Next Paint replaced First Input Delay as a Core Web Vital on 12 March 2024. Google’s own Search Central blog records both the January 2024 announcement and the March 2024 confirmation.

What Google’s sources say

Google’s Search Central blog post was first published by Martin Splitt on 10 May 2023. An update dated 31 January 2024 says INP will replace FID as part of Core Web Vitals on 12 March 2024.

A second update dated 12 March 2024 says INP has replaced FID. The Chrome team’s web.dev launch post, last updated on 12 March 2024, says the same for Chrome’s tools.

What happened to FID in the tools

Both Google posts said Search Console would stop showing FID and use INP at the switch. Chrome gave its other tools longer: developers had until 9 September 2024 to move PageSpeed Insights and Chrome User Experience Report API consumers from FID to INP.

If an old report or agency deck still lists FID as a Core Web Vital, it’s out of date.

Why INP is the tougher metric

FID only measured the input delay of the first interaction on a page. INP observes all interactions, from the input delay through to the time it takes the browser to paint the next frame.

Chrome’s launch post says a new metric was needed to capture aspects of interactivity that FID did not. A slow checkout button, for instance, is rarely the first thing anyone clicks, so FID could miss it while INP would not.

What Is the 75th Percentile Rule and How Does a Page Pass?

Google recommends judging each metric at the 75th percentile of page loads, segmented by mobile and desktop. A page passes when all three metrics are good at that level.

How the rule works

According to web.dev, a metric is good when at least 75% of page views meet the good threshold. It is poor when at least 25% of page views hit the poor threshold.

Web.dev gives an example: a 75th percentile LCP of 2 seconds is good, while one of 5 seconds is poor.

Share of visits with LCP at 2.5 seconds or less	Result at the 75th percentile
90 in 100 visits	Good
75 in 100 visits	Good, but only just
70 in 100 visits	Not good, because the 75th percentile now sits above 2.5 seconds

The table is our own arithmetic from web.dev’s rule, not a Google example.

Why the 75th percentile

The PageSpeed Insights documentation says Google focuses on the 75th percentile so that pages give a good experience under the most difficult device and network conditions. It also says the figure is chosen so developers can understand the most frustrating user experiences on their site.

When data is missing

PageSpeed Insights says a page passes the assessment if the 75th percentiles of all three metrics are good. If there’s not enough data for INP, it passes when LCP and CLS are both good.

If LCP or CLS lacks enough data, that page or origin can’t be assessed at all.

What Is the Difference Between Field Data and Lab Data?

Field data comes from real users visiting your site. Lab data comes from a simulated test on one device and connection, so the two often disagree.

	Field data	Lab data
Source	Chrome User Experience Report (CrUX)	Lighthouse, a simulated page load
Who it measures	Real, opted-in Chrome users	One simulated device and network
Period	Trailing 28 days	A single test run
Best for	Judging whether you pass	Debugging a change before release
Where to see it	Search Console and the top of PageSpeed Insights	Lower section of PageSpeed Insights, Lighthouse

Field data

Google’s PageSpeed Insights documentation says its field data is powered by CrUX and covers the previous 28-day collection period. PageSpeed Insights updates daily, while the BigQuery version of CrUX updates monthly and is limited to origin-level data.

To appear, a URL must be public, crawlable and indexable, with enough distinct samples from real users.

Lab data

Lighthouse simulates the page-load conditions of a mid-tier device, a Moto G4, on a mobile network for mobile tests, and an emulated desktop on a wired connection for desktop tests. PageSpeed Insights runs the test in a Google data centre, so results can vary from run to run.

Use lab tests to debug a change before release and field data to judge the result.

Is the Lighthouse score a Core Web Vital?

No. The Lighthouse performance score is a weighted average of several lab metrics, and Chrome’s documentation for Lighthouse 10 gives Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10% and Speed Index 10%.

INP isn’t in that list, so a 95 in Lighthouse doesn’t mean you pass. Check which Lighthouse version your tool runs, because Chrome notes the weightings have changed over time.

Planning a rebuild and want it to pass from day one? See how our web design service builds for speed and search.

Do Core Web Vitals Affect Rankings?

Yes, to a degree Google hasn’t quantified. It says its ranking systems use Core Web Vitals, and also that relevance comes first and good scores don’t guarantee top rankings.

What Google says

Google’s page experience documentation, last updated on 22 September 2026, says there is no single page experience signal. Its core ranking systems look at a variety of signals that align with overall page experience, and Core Web Vitals are used by those systems.

It recommends achieving good Core Web Vitals, but warns that good results in reports or third-party tools don’t guarantee top rankings. It adds that chasing a perfect score just for SEO reasons may not be the best use of your time.

When page experience matters most

Google says Search always seeks to show the most relevant content, even if the page experience is sub-par. For many queries, though, there’s lots of helpful content, and in those cases a great page experience can contribute to success in Search.

The Core Web Vitals documentation also says these metrics align with what its core ranking systems seek to reward. It publishes no weighting.

What Google doesn’t say

Google doesn’t say how much weight Core Web Vitals carry, or how much a move from poor to good will change a ranking. Nobody outside Google can give you that number, and anyone who does is guessing.

Its page experience FAQ also says ranking systems generally evaluate content page by page, though some assessments are site-wide. Google’s local ranking help describes a different model for local pack results, which we cover separately.

Related: How Does Google Rank Local Businesses?

Why speed is worth fixing anyway

A Google-commissioned study by 55 and Deloitte monitored 37 European and American brand sites for 30 days at the end of 2019. A 0.1 second improvement across four speed metrics lifted lead-generation sites’ progression to the form submission page by 21.6%, and retail shoppers spent 9.2% more.

Those four metrics were not the current Core Web Vitals, and the study predates INP. Treat it as evidence that speed affects behaviour, not as a Core Web Vitals result.

How Are Most Websites Doing on Core Web Vitals?

About half of mobile websites pass. The HTTP Archive’s 2025 Web Almanac, using July 2025 data, found 48% of mobile websites and 56% of desktop websites had good Core Web Vitals.

The Web Almanac chapter draws on HTTP Archive crawl data and the Chrome User Experience Report. The table shows the share rated good for each metric.

Metric	Mobile rated good	Desktop rated good
LCP	62%	74%
INP	77%	97%
CLS	81%	72%
All three	48%	56%

The trend

The Almanac’s good-CWV share for mobile websites rose from 32% in 2021 to 36% in 2023, 44% in 2024 and 48% in 2025. Desktop moved from 41% in 2021 to 48% in 2023, 55% in 2024 and 56% in 2025.

What the gaps show

On mobile, LCP is the weakest of the three, with 62% rated good, against 77% for INP. The Almanac says mobile also has nearly double the share of poor LCP experiences of desktop, 13% against 7%.

At page level, 45% of mobile home pages and 56% of mobile secondary pages had good Core Web Vitals. The Almanac suggests secondary pages benefit from cached information and simpler templates.

How Do You Measure Core Web Vitals?

Start with Search Console for site-wide patterns, PageSpeed Insights for individual URLs and the web-vitals JavaScript library for your own field data.

Tool	Data type	Best for
Search Console Core Web Vitals report	Field (CrUX)	Finding groups of failing URLs
PageSpeed Insights	Field and lab	Checking one URL and reading diagnostics
Lighthouse in Chrome DevTools	Lab	Debugging before release
web-vitals JavaScript library	Field (your own users)	Tracking your own analytics

Search Console

Search Console’s help says the report uses real-world usage data and groups URLs by status, metric and URL group. A group takes the status of its worst-performing metric once it has enough data for LCP and CLS.

Only indexed URLs can appear, and the report is a sample of pages, not a list of every URL. If it shows “No data available”, the property may be new or CrUX may not have enough data for that device type.

PageSpeed Insights

Enter a URL to see field data at the top and lab diagnostics below. If the page has too little traffic, PageSpeed Insights falls back to origin-level data, and if that is missing too, the lab results are your only guide, with the caveats above.

Measuring it yourself

Web.dev says the easiest way to measure all three metrics in JavaScript is the web-vitals library. Metrics measured this way may differ from the ones CrUX reports, so use it to spot trends and not to argue with Search Console.

What Commonly Makes Each Metric Fail?

Slow LCP is usually a resource-discovery or server problem, poor INP is a busy main thread, and high CLS is content that loads without reserved space.

Web.dev’s optimisation guides name the causes below.

Metric	Common causes named by web.dev	First thing to check
LCP	Late-discovered hero image, render-blocking CSS or scripts, client-side rendering, slow server response	Is the LCP image in the HTML and loading early?
INP	Long tasks on the main thread, heavy event callbacks, large DOMs, layout thrashing	What runs when someone taps or clicks?
CLS	Images and embeds without dimensions, injected content, web fonts	Does every image and slot have reserved space?

Fixing LCP

Web.dev’s LCP optimisation guide splits LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay. On a well-optimised page, roughly 40% of LCP is time to first byte, under 10% is load delay, roughly 40% is load duration and under 10% is render delay.

Its fixes are concrete. Make the LCP resource discoverable in the HTML, never lazy-load the LCP image, and put fetchpriority=“high” on the image you expect to be the LCP element, but on only one or two images.

A slow server response has its own causes. Web.dev lists multiple redirects, visitors far from the server, poor network conditions and content that can’t be cached because of query parameters.

The Almanac found an image was the LCP element on 76% of mobile pages. It also found fetchpriority=“high” on only 17% of mobile pages with LCP images, so there’s room to gain.

For JavaScript-heavy product sites, such as many SaaS and tech companies, web.dev recommends server-side rendering over client-side rendering of the main content.

Fixing INP

Web.dev’s INP guide describes an interaction as three phases: input delay, processing duration and presentation delay. Long tasks block input delay, and slow event callbacks add processing time.

It recommends yielding to the main thread often, so rendering can occur sooner, and deferring work that isn’t needed for the next visual update. It also names large DOM sizes and layout thrashing as common causes.

Fixing CLS

Web.dev lists the most common causes of poor CLS as images without dimensions, ads, embeds and iframes without dimensions, dynamically injected content and web fonts. Its main fix is to put width and height attributes on images and video, or reserve space with CSS aspect-ratio.

Reserve a fixed slot for any ad or embed that loads late. Content that appears above existing content after the page has started rendering is the pattern to avoid.

What Should You Fix First?

Fix the metric that is furthest from its threshold, then the pages that carry the most traffic or revenue.

Search Console’s help says to fix everything labelled Poor first.

Work from the report

Search Console recommends prioritising either the issues that affect the most URLs or those that affect your most important URLs. URLs in a group are sorted by impressions, so the ones at the top have the most effect on the group’s status.

Start with a representative URL, run it through PageSpeed Insights and read the lab diagnostics for the cause. A single template fix can move hundreds of pages, and our SEO audit reviews Core Web Vitals alongside the rest of your technical health.

Wait out the validation window

Once you think an issue is fixed, Search Console’s Start Tracking button starts a 28-day monitoring session. It doesn’t trigger re-indexing, and it just restarts the clock on a four-week check of CrUX data.

Fixes therefore take about a month to show in the report, which is worth knowing before you judge the result.

Related: How Long Does SEO Take to Work?

Re-check after every rebuild

A redesign, theme change or platform move can undo months of tuning, so give your web design team your Core Web Vitals targets before work starts. Record your scores before the change and compare them afterwards, as part of a wider checklist for moving a website without losing rankings.

Want a site that’s fast and findable from the start? Talk to us about web design that treats Core Web Vitals as part of the build brief.

Don’t stop at three metrics

Google’s page experience documentation lists six self-assessment questions. They ask whether your pages have good Core Web Vitals, are served securely, display well on mobile, avoid excessive distracting ads, avoid intrusive interstitials, and make the main content easy to tell apart from other content.

Google says those questions don’t cover every aspect, and that beyond Core Web Vitals the other aspects don’t directly help a page rank. It says they can still make a site more satisfying to use, which is generally aligned with what its ranking systems seek to reward.

Our SEO service treats them as part of the wider technical picture.