Core Web Vitals explained: LCP, INP and CLS
·4 min read
Core Web Vitals are three Google metrics for how a page feels to real visitors. Largest Contentful Paint (LCP) measures loading, Interaction to Next Paint (INP) measures responsiveness and Cumulative Layout Shift (CLS) measures visual stability. A page passes when, at the 75th percentile of real Chrome visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. Google's ranking systems use them, but relevance still wins, so treat a pass as a tiebreaker.
Most confusion comes from mixing up which number counts. A Lighthouse score of 98 can sit next to a failing assessment, and that is usually the field data telling the truth.
What are Core Web Vitals?
Core Web Vitals are the subset of Google's web vitals that apply to every page and that Google treats as stable. These are the thresholds from web.dev.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Time until the largest image or text block in the viewport renders | 2.5 s or less | Up to 4 s | Over 4 s |
| INP | Delay from a click, tap or key press until the next frame paints | 200 ms or less | Up to 500 ms | Over 500 ms |
| CLS | The largest burst of unexpected layout shifts | 0.1 or less | Up to 0.25 | Over 0.25 |
LCP stops the clock when the hero image or headline appears, not when the page finishes loading.
INP replaced First Input Delay on March 12, 2024, per Google Search Central. FID timed only the first interaction's input delay. INP observes every click, tap and key press during the visit and reports roughly the worst one, ignoring one outlier per 50 interactions. Scrolling and hovering do not count.
CLS is a score, not a time. Web.dev defines it as the biggest session window of shifts, where each shift follows the last within one second and the window lasts at most five seconds. Shifts within 500 ms of a tap or key press are excluded, so an accordion opening on click is fine. A cookie banner pushing the article down is not.
The 75th percentile rule
Google judges each metric at the 75th percentile of page loads, separately for mobile and desktop. A page passes only if all three metrics are good at that percentile.
The 75th percentile means three in four visits must hit the target. A median LCP of 1.8 seconds still fails if more than a quarter of mobile visitors wait over 2.5 seconds, which happens on sites with a fast office connection and slow real customers. Check mobile first. It almost always fails before desktop.
Field data vs lab data
Field data is what real Chrome users experienced over the past 28 days, collected in the Chrome User Experience Report (CrUX). Lab data is one Lighthouse load on a simulated device. Only field data decides whether you pass.
Lab data is still useful because it shows causes, such as which script blocks the main thread or which image loads late. It has one blind spot. A lab page load has no user, so it cannot measure INP. Lighthouse reports Total Blocking Time instead, which tracks the same main-thread problems but is not the same number.
CrUX has a record for a URL only when it gets enough traffic. Without one, PageSpeed Insights falls back to the whole origin, and shows nothing when the origin is too small. The LCP guide covers field vs lab in more depth, and the Core Web Vitals test guide covers running the test itself.
Do Core Web Vitals affect rankings?
Yes, but less than most audits imply. Google's page experience documentation states that Core Web Vitals are used by its ranking systems, and that there is no single page experience signal. It also says Search shows the most relevant content even when the page experience is poor.
In practice that makes Core Web Vitals a tiebreaker between pages that answer a query equally well. Moving from poor to good can help on a competitive query. Moving CLS from 0.08 to 0.02 will not. Google also says it evaluates pages mostly one by one, with some site-wide assessments, so fix the templates that carry your money pages first.
Users are the stronger reason. A layout that jumps while someone taps "Buy" costs sales at any rank.
One-line fixes for each metric
Each metric has a few causes that account for most failures.
- LCP. Serve HTML from a cache, add
fetchpriority="high"to the hero image and never lazy-load it. The full LCP guide splits it into subparts. - INP. Break up long JavaScript tasks and defer third-party scripts so clicks do not wait behind them.
- CLS. Give images, embeds and ad slots explicit width and height, and reserve space for banners that load late.
Fix whatever is poor in the field before touching anything rated needs improvement.
Check your Core Web Vitals on one URL
The Core Web Vitals Snapshot runs Google's PageSpeed Insights for one public URL on mobile or desktop. It shows real-user LCP, INP and CLS at the 75th percentile from CrUX, using the URL's own record when there is one and the origin's when there is not, and says plainly when neither exists. Next to that it shows the Lighthouse lab run, with the performance score, LCP, CLS, Total Blocking Time, first contentful paint, TTFB and Speed Index, plus up to eight opportunities ranked by estimated savings.
Field and lab stay separate, and the verdict uses field data whenever it exists. The lab run never stands in for INP. A run costs 20 credits. It checks one URL at a time and does not read your Search Console report.