Understanding Core Web Vitals: What LCP, INP, and CLS Actually Measure

Core Web Vitals are the three field metrics Google uses to judge whether a page feels fast and stable to a real visitor. They replaced vague notions of "speed" with specific, measurable thresholds, and since 2021 they've fed into the page experience signal in Google's ranking systems. Understanding exactly what each metric captures is the first step before you touch a single line of code, because optimizing the wrong thing wastes engineering hours.

Each metric maps to a different moment in the user's experience: loading, interacting, and viewing. Google scores pages at the 75th percentile of real-user visits, meaning three out of four of your visitors need a "good" experience for the page to pass — a lab test alone won't tell you that.

Largest Contentful Paint (LCP)

LCP measures how long it takes the largest visible element — usually a hero image, background image, or block of text — to render in the viewport. Google's threshold for "good" is 2.5 seconds or less. LCP is dominated by four sub-parts: time to first byte (TTFB), resource load delay, resource load time, and render delay. A slow TTFB from an under-provisioned server or unindexed database query often accounts for over a third of a bad LCP score, so server response time is the first place to check, not just image size.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as the official responsiveness metric in March 2024. It measures the latency of every click, tap, and keypress throughout the page's full lifespan and reports a high-percentile value, not just the first interaction. A good INP is under 200 milliseconds. Long JavaScript tasks — anything blocking the main thread for more than 50ms — are the usual culprit, especially third-party scripts like chat widgets, ad tags, and A/B testing tools that hook into every click event.

Cumulative Layout Shift (CLS)

CLS scores unexpected visual movement — when a button shifts down as an ad loads, or text reflows because a web font swaps in late. A good score is under 0.1. The most common causes are images and embeds without explicit width/height attributes, web fonts that cause a flash of unstyled text (FOUT), and content injected above existing elements, such as cookie banners or promotional bars that push the page down after it has already rendered.

How Google Actually Scores Your Site

Field data comes from the Chrome User Experience Report (CrUX), aggregated from real Chrome users over a rolling 28-day window. This is different from Lighthouse or PageSpeed Insights lab scores, which run a single simulated session. A page can score 100 in Lighthouse and still fail Core Web Vitals in Search Console's report if real users on slower devices and networks have a worse experience — always trust the Search Console "Core Web Vitals" report and CrUX data over a single lab test.

Where to Check Your Scores

• Google Search Console — the Core Web Vitals report groups URLs by status (Poor, Needs Improvement, Good) using real field data.
• PageSpeed Insights — shows both field data (when available) and a lab-based diagnostic breakdown with specific fix suggestions.
• Chrome DevTools Performance panel — lets you record a session and see exactly which script or resource is delaying LCP or causing layout shifts.
• web.dev/measure and the CrUX Dashboard — useful for tracking trends over time across a whole domain. For a deeper look at this, see our guide, Keyword Difficulty Scores Explained: How Semrush, Ahrefs, and Moz Actually Calculate Them.

Once you know which metric is failing and on which templates, you can move to targeted fixes — image and font optimization for LCP, JavaScript execution for INP, and layout reservation for CLS — rather than applying generic "speed tips" that may not move the metric that's actually hurting you. For a deeper look at this, see our guide, Content Optimization.