Core Web Vitals: LCP, INP, CLS Explained

Why Measuring Page Experience Is Hard

When someone says a website feels slow, they are describing a feeling, not a fact. Two people visiting the same page can walk away with different impressions depending on what they were waiting for, what they were trying to do, and how the page behaved while it loaded. For years, this subjectivity made it difficult for search engines and developers to agree on what "good" actually meant.

Core Web Vitals are Google's answer to that problem. Rather than measuring the entire loading experience as a single number, they isolate three specific moments that research consistently links to how users perceive quality. Each metric captures a different dimension of experience, and together they form a framework that turns subjective frustration into something observable and comparable across billions of pages.

The Three Dimensions of Page Experience

The choice to measure three separate signals rather than one composite score reflects something important about how experience actually works. Loading, interactivity, and visual stability are genuinely different phenomena. A page can load its main content quickly but still feel broken if the layout shifts unexpectedly. A page can appear stable but refuse to respond when a user taps a button. Collapsing these into a single metric would hide the specific failure that matters.

Largest Contentful Paint: The Moment the Page Feels Loaded

Largest Contentful Paint measures how long it takes for the largest visible element in the viewport to finish rendering. This is typically a hero image, a large heading, or a prominent block of text. The logic behind choosing this specific moment is grounded in perception psychology: users tend to judge whether a page has "loaded" based on when the dominant visual element appears, not when every background script has finished running.

Earlier loading metrics focused on technical milestones like the time until the first byte of data arrived from the server, or the moment the browser finished parsing the HTML document. These metrics were precise but poor proxies for perceived experience. A page could pass those milestones quickly and still leave a user staring at a blank screen or a spinner for several more seconds. LCP shifts the measurement to the moment that actually registers in human perception: when the page looks usable.

The threshold Google uses reflects research into abandonment behavior. Pages where LCP occurs within 2.5 seconds are classified as good. Between 2.5 and 4 seconds is considered needs improvement. Beyond 4 seconds falls into the poor category. These are not arbitrary numbers. They correspond to points on the distribution of user experience where satisfaction drops measurably and bounce rates increase.

Interaction to Next Paint: The Moment the Page Feels Responsive

INP replaced an earlier metric called First Input Delay in 2024. FID measured only the delay before the browser began processing the very first interaction a user made. INP is broader and more representative: it measures the delay across all interactions during a page visit and reports the worst-case result, with a small allowance for outliers.

An interaction in this context means a discrete input event: a click, a tap, or a keyboard press. The metric captures the time from that input until the browser has finished processing the response and painted the next visible frame. This matters because users interpret unresponsiveness as a sign that something is wrong. When a button does not react immediately, the instinct is either to tap it again (which can cause unintended duplicate actions) or to assume the page is broken.

INP reflects a specific understanding of how the browser's main thread works. Browsers process JavaScript, handle layout calculations, and respond to user input on a single thread. When that thread is occupied with heavy processing tasks, interactions queue up and wait. The delay the user experiences is not a network problem or a server problem. It is a consequence of how much work the browser has been asked to do at once. INP makes that invisible bottleneck visible.

A response time under 200 milliseconds is considered good. Between 200 and 500 milliseconds needs improvement. Above 500 milliseconds is poor. The 200-millisecond threshold corresponds roughly to the limit of human perception for cause and effect. Below that threshold, an interaction feels instantaneous. Above it, users begin to notice and interpret the gap as lag.

Cumulative Layout Shift: The Moment the Page Feels Stable

Cumulative Layout Shift measures visual instability. It captures how much the visible content of a page moves unexpectedly during the loading process. Every time an element shifts position without the user initiating that movement, CLS increases. The score accumulates across the entire session, weighted by both the size of the shift and the distance elements travel.

Layout shifts happen for a specific reason: the browser renders what it knows about, then updates the layout as more information arrives. An image without declared dimensions causes the browser to reserve no space for it initially. When the image loads, everything below it jumps down. An advertisement that loads after the surrounding content pushes the paragraph a user was reading off screen. A font that loads late causes text to reflow as letter spacing changes.

The frustration CLS captures is distinctive. Unlike slow loading or unresponsive buttons, layout shift causes active harm. Users click the wrong link because a button moved at the moment they tapped. They lose their reading position. They submit forms they did not intend to submit. The metric exists because this category of experience failure was widespread and largely invisible to the teams building the pages causing it.

A CLS score below 0.1 is considered good. Between 0.1 and 0.25 needs improvement. Above 0.25 is poor. The score has no unit in the traditional sense. It is a calculated ratio based on the fraction of the viewport affected and the fraction of the viewport the element traveled.

Why Google Chose These Three Signals

The selection of LCP, INP, and CLS was not primarily a technical decision. It was a decision about which user frustrations were common enough, measurable enough, and actionable enough to serve as a meaningful quality signal at web scale. Google's research into user behavior identified these three categories of experience failure as the ones most consistently correlated with users abandoning pages, expressing dissatisfaction, or failing to complete their intended task.

There are other dimensions of experience that matter, including accessibility, visual design, and content quality. Core Web Vitals do not attempt to measure those. They measure the narrow set of loading-related behaviors that can be observed objectively, compared across different pages and industries, and used to distinguish between pages that feel good to use and pages that do not.

This is also why Core Web Vitals use field data rather than lab data as their primary signal. Field data comes from real users on real devices and real network connections. Lab data comes from controlled simulations. A page that performs well in a lab simulation but poorly for actual users is failing by the measure that matters. Real user measurement captures the distribution of experience across different devices, connection speeds, and geographic locations rather than a single idealised scenario.

The Relationship Between Core Web Vitals and Search Ranking

Google incorporated Core Web Vitals into its ranking systems as part of the Page Experience update. The intent was to give pages that provide a genuinely good experience a modest advantage over pages that do not, all else being equal. The emphasis on "all else being equal" is significant. Relevance, authority, and content quality remain the dominant ranking factors. Core Web Vitals function as a tiebreaker rather than a primary signal.

What this means in practice is that understanding Core Web Vitals is partly about understanding what Google values and why. Google's business depends on users trusting that search results lead to good experiences. A search engine that consistently sends users to slow, unstable, or unresponsive pages loses credibility. Core Web Vitals give Google a systematic way to reward pages that respect the user's time and attention and to deprioritise pages that do not.

What Changes After Understanding This

Before understanding Core Web Vitals, the conversation about page speed tends to collapse into a single vague concern: "the site is slow." After understanding them, it becomes possible to distinguish between three genuinely different problems with different causes and different implications for user experience. A page with a poor LCP score is failing at a different moment than a page with a high CLS score. Treating them as the same problem obscures what is actually happening.

This framework also reframes the relationship between technical decisions and user experience. Every choice about how a page loads, how scripts are executed, and how layout is constructed has a measurable effect on how the page feels to use. Core Web Vitals make that connection explicit, turning what was once a matter of intuition into something that can be observed, compared, and understood.