What are the Core Web Vitals: LCP, INP and CLS explained with thresholds

The Core Web Vitals are three metrics defined by Google that measure the real loading and interaction experience of a page: LCP (Largest Contentful Paint) measures how long the main content takes to appear, INP (Interaction to Next Paint) measures how long the page takes to respond to user interactions and CLS (Cumulative Layout Shift) measures how much content moves unexpectedly. A page passes the assessment when 75 % of its real visits fall within the “good” thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1.

This article explains what each one measures, where the data comes from and what usually breaks them, without making ranking promises Google does not make.

The three metrics and their thresholds

Metric	What it measures	Good	Needs improvement	Poor
LCP	Time until the largest visible content element is painted	≤ 2.5 s	2.5 – 4 s	> 4 s
INP	Latency of interactions (clicks, taps, key presses) across the whole visit	≤ 200 ms	200 – 500 ms	> 500 ms
CLS	Sum of unexpected layout shifts	≤ 0.1	0.1 – 0.25	> 0.25

The thresholds apply to the 75th percentile of visits: the page passes a metric if at least three out of four user experiences are in the good range. It is a deliberately demanding measure so that being fast on a powerful computer with a good connection is not enough.

LCP: when the important part appears

LCP marks the moment the browser paints the largest element inside the viewport: usually a featured image, a video with a poster or a large block of text. What delays it most:

• Heavy or low-priority main images (see lazy loading and fetchpriority).
• Slow server response (high TTFB).
• Render-blocking CSS or JavaScript.
• Web fonts delaying text display.

INP: how the page responds

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. Unlike FID, which only measured the first interaction, INP observes every interaction of the visit and reports one of the worst (in practice the slowest, ignoring some outliers on pages with many interactions). It measures from the moment the user interacts until the browser paints the next frame.

What breaks it is almost always JavaScript: long tasks on the main thread, heavy event handlers, frameworks hydrating the whole page before responding, third-party scripts (advertising, analytics, chats) competing for the CPU.

CLS: nothing should jump

CLS adds up the shifts of visible elements that happen without the user causing them. The classic causes:

• Images, videos or iframes without width and height.
• Ads or embeds inserted without reserved space.
• Web fonts changing the text size when they load.
• Content inserted dynamically above what is already visible (notices, banners).

If a site is going to show advertising, reserving the height of each ad slot before it loads is the most effective measure against CLS.

Where the data comes from: field and lab

There are two kinds of measurement and they should not be confused:

• Field data (real). It comes from real Chrome users who have agreed to share statistics, collected in the Chrome UX Report (CrUX). This is what Google Search Console uses in its Core Web Vitals report and what counts for the assessment. It only exists if the page has enough traffic.
• Lab data (simulated). Produced by a tool such as Lighthouse or PageSpeed Insights in a controlled environment. Useful for diagnosing and reproducing problems, but it does not reflect the variety of real devices and connections. INP, moreover, cannot be measured in the lab because it depends on user interactions (Lighthouse offers TBT, Total Blocking Time, as an approximation).

PageSpeed Insights shows both: CrUX field data at the top (when available) and the lab analysis below.

How to measure them on your site

1. PageSpeed Insights (pagespeed.web.dev): enter the URL and look at the real-data section first.
2. Google Search Console, “Core Web Vitals” report: groups the site’s URLs by status (good, needs improvement, poor) based on CrUX.
3. Chrome DevTools, Performance panel: shows LCP, INP and CLS live as you browse and points to the element responsible for each.
4. The web-vitals library (npm install web-vitals): lets you collect the metrics from your own users and send them to your analytics.

How they relate to ranking

Google states in its Search documentation that Core Web Vitals are part of the page experience signals and recommends that site owners achieve good results, but it also makes clear that relevant, quality content remains the main thing and that excellent Vitals do not make up for poor content. It is reasonable to treat them as what they are: a measure of quality for users which also avoids a disadvantage against competitors with equally relevant but faster pages.

Common mistakes when optimising

• Optimising only for Lighthouse. A score of 100 in the lab does not guarantee good field data if your real users are on modest phones.
• Deferring the LCP image. Applying loading="lazy" to the main image makes LCP worse.
• Loading third-party scripts without control. They are the most frequent cause of high INP. Load only the essentials and, when something depends on user consent, do not load it until you have it.
• Ignoring ad CLS. Reserve space with min-height on every ad slot.

Conclusion

LCP, INP and CLS summarise in three numbers whether a page appears quickly, responds fast and does not jump. They are assessed with real user data at the 75th percentile, and improved through concrete decisions: prioritising the main image, minimising and deferring JavaScript, declaring dimensions and reserving space for everything inserted late. Measure in the field before optimising; then use the lab to find the cause.