Core Web Vitals: Google's User Experience Metrics Explained

Core Web Vitals are three metrics Google uses to measure the experience of loading and using a page: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. They are measured on real visits, judged at the 75th percentile, and used by Google’s ranking systems. A page passes when it meets the good threshold on all three.

The Thresholds

Google’s Web Vitals reference sets the targets:

Metric	What it measures	Good
LCP	When the largest visible content element renders	2.5 seconds or less
INP	How quickly the page responds to interactions	200 milliseconds or less
CLS	How much visible content shifts unexpectedly	0.1 or less

The boundary values count as good: an LCP of exactly 2.5 seconds passes. At the other end, web.dev’s guides class an INP “above 500 milliseconds” as poor, and for CLS: “Poor values are greater than 0.25.”

How the thresholds are applied matters as much as the numbers: “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” The reference continues: “Tools that assess Core Web Vitals compliance should consider a page passing if it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics.” A page can have a fine average and still fail if its slowest quarter of visits are poor. Interaction to Next Paint replaced First Input Delay on March 12, 2024, as web.dev announced.

Largest Contentful Paint

LCP marks when the largest image or text block in the viewport has rendered. Causes of a slow LCP, in the order a page loads:

A slow server response, since nothing renders before the HTML arrives.
CSS and scripts in the head that block rendering.
A large or late-loading LCP image. Preloading it can help:

<link rel="preload" href="hero-image.webp" as="image">

Content that appears only after client-side JavaScript runs.

Find the LCP element on each template first, in Lighthouse or the Chrome DevTools Performance panel. Web.dev’s LCP guide then breaks LCP time into four subparts: time to first byte, resource load delay, resource load duration, and element render delay. Server response, how early the browser discovers the resource, and render-blocking files all move the metric, not only the element itself.

Interaction to Next Paint

INP looks at the interactions during a visit, such as clicks, taps, and key presses. Web.dev’s INP guide explains: “The final INP value is the longest interaction observed, ignoring outliers.” For pages with many interactions, “we ignore one highest interaction for every 50 interactions.”

Slow INP comes from the main thread being busy when the visitor acts. The fixes are to break long tasks into smaller ones, move heavy work into Web Workers, load less JavaScript, and audit third-party scripts such as tag managers, chat widgets, and ad code.

Cumulative Layout Shift

Each layout shift is scored as the impact fraction multiplied by the distance fraction, and CLS reports the largest burst of shifts. Web.dev’s CLS guide defines a burst, or session window, as shifts that occur “with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.”

Give images and videos width and height attributes, or a CSS aspect-ratio.
Reserve space for ads, embeds, and consent banners before they load.
Match fallback font metrics to the web font, and use font-display: swap.
Animate with transform and opacity instead of properties that change layout.

Where to Measure

The Core Web Vitals report in Search Console shows field data grouped into URL groups of similar pages. Once a group has enough data, “the URL group’s status is its most poorly performing metric,” and each group’s values describe the 75th percentile of requests “in the last 28 days.” Groups without enough data are left out.
PageSpeed Insights shows field data from the Chrome UX Report next to a Lighthouse lab test for a single URL.
The web-vitals JavaScript library lets a site collect its own measurements from real visitors.

Lab and field results differ because a lab test runs one fixed device and network, while field data comes from real visits on many devices and connections. The field data in Google’s tools comes from the Chrome UX Report, whose methodology includes only Chrome users who meet its criteria, such as enabling usage statistic reporting, and leaves out Chrome on iOS; your own real-user monitoring can cover visitors the report does not. Use lab tools to find causes and field data to judge whether a fix worked. Field data trails a fix: the report’s 28-day window has to fill with visits after the change.

Core Web Vitals and Rankings

Google’s page experience documentation states that “Core Web Vitals are used by our ranking systems,” and also sets their place: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases.” It adds that good results in the Core Web Vitals report do not guarantee top rankings.

Relevance comes first; Core Web Vitals help most where several pages answer the query equally well. Mobile and desktop are measured separately, so check both.

An Order of Work

Check the Search Console report for both mobile and desktop.
Start with the URL groups that get the most traffic and fail by the widest margin.
Find the cause on a representative page with Lighthouse and DevTools.
Check whether the URLs in a failing group share a template or a common resource; where they do, fix that source rather than each page.
Watch the field data over the following 28 days.
Recheck after new features, redesigns, or added third-party scripts.