What Are the Core Web Vitals? LCP, INP & CLS Explained (2026)

What are the Core Web Vitals?

Each Core Web Vital covers one moment of a visit. The data comes from real Chrome users:

• Loading (LCP): how long before the main content is on screen
• Interactivity (INP): how long the page takes to react to a click, tap or key press
• Stability (CLS): how much the content moves while it loads

The set changes. In March 2024, INP replaced First Input Delay (FID). FID only timed the wait before the first interaction got handled. INP times every interaction from start to finish, and a lot more sites fail it.

When do you pass the Core Web Vitals?

Google rates each metric Good, Needs Improvement or Poor. You pass when at least 75% of the page visits in CrUX have a good LCP, a good INP and a good CLS. Google looks at the URL first. When that URL has too little traffic, it falls back to a group of similar URLs, or to the whole origin. PageSpeed Insights shows the result above everything else on the page: "Core Web Vitals Assessment: Passed" or "Failed".

Why the 75th Percentile?

The median only tells you about the faster half of your visitors. A stricter percentile would let a few visits from a train with one bar of signal fail the whole page. p75 sits in between: three out of four visits need to be good.

Your own laptop on office wifi tells you very little. The visits that decide p75 are the slower phones on mobile networks.

The Three Core Web Vitals Metrics

Largest Contentful Paint (LCP): Loading

The Largest Contentful Paint measures loading: the time from the start of the navigation until the largest element in the viewport is painted.

That element has to have content: an image (background images and video posters count too) or a block of text. On most pages the LCP element is the hero image or the main heading.

Good is under 2.5 seconds. In the CrUX release for August 2026, 68.1% of origins managed that, the lowest of the three.

LCP follows what the visitor sees. Once the largest element is on screen, most people think the page is done, even when scripts are still loading. The metric was built to answer one question: 'When is the content of a page visible?'.

When the LCP element is late, the reason is usually boring. loading="lazy" on the hero image. A hero set as a CSS background, so the browser only finds it after the stylesheet is in. A slider script that has to run before the first slide shows. Fix the discovery first, then preload the image if the HTML still hides it, give it fetchpriority="high" and make the file smaller. The Largest Contentful Paint guide goes through all four LCP phases.

Interaction to Next Paint (INP): Interactivity

The Interaction to Next Paint measures interactivity: how long it takes before the screen updates after a visitor clicks, taps or presses a key. Scrolling and hovering do not count.

Each interaction is timed from the input, through the JavaScript it triggers, to the next frame on screen. The page gets the time of its slowest interaction. On pages with a lot of interactions Google skips one outlier for every 50 interactions, which comes down to roughly the 98th percentile.

A normal Lighthouse run cannot measure INP. It loads the page and never clicks anything. The closest lab number is Total Blocking Time. INP is usually a lot lower than TBT, but when TBT goes down, INP tends to follow.

Often the click handler itself is fast. The main thread is busy with something else when the click comes in: a tag manager, a chat widget, a framework still hydrating. Most of that JavaScript can be deferred or scheduled. 85.3% of origins had a good INP in August 2026, down from 87.2% in March (CrUX release notes). It is the only Core Web Vital that got worse over the last year. The Interaction to Next Paint guide shows how to find the slow interactions.

Cumulative Layout Shift (CLS): Visual Stability

The Cumulative Layout Shift measures visual stability: how much visible content moves without the visitor asking for it. You go to tap a link and the page jumps.

Every shift gets a score: the impact fraction (how much of the viewport is affected) times the distance fraction (how far the content moved, relative to the viewport). Shifts that happen close together are added up in a session window. The CLS of the page is its worst session window.

The usual causes: images without width and height; ads, cookie banners and embeds that push content down when they arrive; and a web font that is wider or taller than its fallback. For fonts, self host them and pick the right font-display setting. CLS is the metric most sites get right: 81.5% of origins had a good CLS in August 2026. More in the Cumulative Layout Shift guide.

Why Do the Core Web Vitals Matter?

• Visitors leave. A button that does nothing for half a second gets clicked twice, then abandoned. Google collected case studies of sites that fixed their Core Web Vitals and got lower bounce rates and more conversions.
• Rankings. The Core Web Vitals are a Google ranking factor. A small one. When two pages are about equally good, the faster one has the edge.
• Mobile. Most of your traffic is probably on a phone, and that is where pages fail. The 2025 Web Almanac (the latest edition) found 48% of mobile pages passing against 56% on desktop.
• Google Ads. Landing page experience is part of your Quality Score. A slow landing page drags it down and every click costs more.

Google also documents exactly how each metric is measured, down to the browser code. For a ranking factor, that almost never happens.

Vodafone Case Study

Vodafone Italy improved their Largest Contentful Paint by 31% and got 8% more sales, 15% more leads and an 11% better cart to visit rate (source: web.dev case study).

Field Data vs. Lab Data

Field data (also called Real User Monitoring or RUM data) comes from your real visitors, on their own devices and networks. Google's CrUX dataset is field data from Chrome users who opted in. The Core Web Vitals are field data only.

Lab data comes from a test on a simulated device in a fixed setup. Lighthouse and WebPageTest produce lab data. A lab test gives you roughly the same result every run, which makes it good for debugging. It does not tell you what your visitors get.

Lighthouse says 100, so why do I fail?

Because Google ranks on CrUX, and Lighthouse tests one simulated visit. Your visitors are on cheap Android phones and bad hotel wifi, and they click on things Lighthouse never touches. INP does not even exist in a Lighthouse run.

CrUX gives you a pass or a fail per URL group. To find out which page, device and element is behind the fail, I use Real User Monitoring: CoreDash, which I built for exactly this. It splits the data by device, country and page template, and points at the LCP element or the interaction that is slow.

How to Measure the Core Web Vitals

Measurement Tools Compared

CrUX Data

The CrUX dataset holds the Core Web Vitals of every site with enough Chrome traffic. It is the official dataset of the Web Vitals program. You can get to it in a few ways:

1. CrUX Vis shows how an origin or URL has scored over the last months. It replaced the old CrUX Dashboard in Looker Studio, which Google shut down at the end of 2025.
2. CrUX on BigQuery has the origin level data of every site in CrUX, with full histograms per metric, updated monthly. Good for comparing a site with its competitors.
3. The CrUX API gives you the data per page or origin, filtered by device type and metric, for when you want the numbers in your own tools.
4. PageSpeed Insights shows the CrUX data for a URL above a Lighthouse report. It opens on the mobile tab. Stay there: the desktop tab is often green and makes people think they pass.

Monitoring with RUM

RUM data comes from a small script on your own site that measures every visit. It measures the same Core Web Vitals as CrUX, with the details CrUX leaves out. CrUX is anonymized, stops at URL level and always looks at the last 28 days. RUM shows you yesterday, per page, device, country and browser, and it tells you which element caused the slow LCP or the layout shift. That is why most people who fix Core Web Vitals for a living run RUM next to CrUX.

Lighthouse

Lighthouse does not measure the Core Web Vitals. It loads one page, once, on a simulated phone with a throttled connection. It starts with an empty cache, never navigates to a second page and never clicks.

It is still the fastest way to see what blocks rendering, which image is the LCP element and which scripts keep the main thread busy. Ignore half of the list, though. Minifying CSS saves a few kilobytes and none of your visitors will notice.

Run it in PageSpeed Insights, in Chrome DevTools or with the Lighthouse command line tool.

How Many Sites Pass?

The Chrome team publishes the CrUX numbers every month, on the second Tuesday, in the CrUX release notes. These are the shares of origins with a good score, all devices together:

Compare the same month year on year. December swings every year (the Chrome team has seen it since CrUX launched), so one bad month says little. For TTFB and FCP, which are not in the release notes, see the Time to First Byte guide and the First Contentful Paint guide.

How to Improve the Core Web Vitals

Where I start: p75 per metric on mobile, then the URL group Search Console flags, then the trend. A sudden drop usually points at a deploy. A slow slide is third party scripts piling up, one tag at a time.

Every release can break something again, so keep watching your field data after the fix goes live. And the metrics affect each other. font-display: swap gets your text on screen sooner, which can help LCP, but when the web font is a different size than the fallback, the swap causes a layout shift. One guide per metric:

• Improve the Largest Contentful Paint
• Improve the Interaction to Next Paint
• Improve the Cumulative Layout Shift

Two diagnostic metrics hold LCP back:

• Time to First Byte (TTFB): the browser cannot start on the page before the HTML arrives. With a slow TTFB, a good LCP is almost impossible. Caching the HTML at your CDN is usually the quickest win.
• First Contentful Paint (FCP): the first paint of any content. Until then the visitor stares at a white screen.

For a step by step list, use the Core Web Vitals Checklist.

Core Web Vitals in Search Console

Google used to group the Core Web Vitals with HTTPS, mobile friendliness and intrusive interstitials as "page experience". Google removed the Page Experience report from Search Console in November 2024. The Core Web Vitals report is still there, under 'Experience'.

That report groups your URLs by template and shows which groups pass. It covers the last 28 days, so two weeks after a fix goes live, half of what it shows is still the old site.