Core Web Vitals Explained: LCP, CLS, and INP Meaning

Core Web Vitals are a set of measurements that describe how a webpage feels to the person using it — not how fast a server responds in a lab report, but how quickly content appears, how stable the layout stays, and how promptly the page reacts when someone clicks, taps, or types. The three metrics that make up this set are Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Together they attempt to quantify loading speed, visual stability, and responsiveness using data drawn from actual visits rather than synthetic tests alone.

Understanding these metrics matters because they capture friction points that are easy to overlook during development but highly noticeable to a real visitor. A page that loads its main image slowly, jumps around as ads or fonts load, or freezes for a moment after a button is pressed creates a subtly worse experience even if the site “looks” fine in a screenshot. Core Web Vitals were designed to put numbers on those moments of friction so they can be identified and discussed with precision.

This page serves as a reference for what each metric measures, why it was introduced, what a poor score actually represents from a user’s perspective, and how these measurements relate to one another. It does not offer instructions for raising a score — the goal here is to explain what is being measured and why it exists, so that the underlying concepts are clear before any technical investigation begins.

Key Concepts

At its core, the Core Web Vitals framework is built on the idea that page performance should be measured from the perspective of the person loading the page, not from the perspective of a server or a network engineer. Traditional performance metrics — total load time, server response time, number of requests — describe technical processes but don’t always correlate with how a visitor perceives the experience. A page can finish “loading” in the technical sense while still feeling slow, jumpy, or unresponsive to a human being watching the screen.

The three metrics each address a distinct phase of the browsing experience. LCP addresses the loading phase: how long it takes for the largest, most prominent piece of content to become visible. CLS addresses the visual stability phase: whether elements on the page move around unexpectedly while a person is trying to read or interact with them. INP addresses the interactivity phase: how quickly the page responds after someone performs an action, such as clicking a menu or submitting a form. These three windows — loading, stability, and responsiveness — cover the major stages a visitor experiences from arrival to interaction.

It’s also important to understand that these metrics are typically gathered as “field data,” meaning they’re collected from real visits by real people on real devices and networks, rather than solely from a controlled lab environment. This distinction matters: a page might perform well in a lab test run on a fast connection but score poorly in the field if most visitors arrive on older phones or slower mobile networks. Field data reflects the diversity of real-world conditions, which is precisely why it can differ from a single lab-based test result.

What to Look For

When trying to understand or interpret Core Web Vitals data, the first thing to look for is which of the three metrics is underperforming, since each points to a different kind of problem. A poor LCP score points toward loading delays — something in the chain between a request and the rendering of the main content is taking too long. A poor CLS score points toward layout instability — elements are shifting position after they’ve already appeared. A poor INP score points toward responsiveness issues — the browser’s main thread is too busy to react quickly to input.

Context matters as much as the raw number. A metric measured on mobile devices will often look different from the same metric measured on desktop, because mobile devices typically have less processing power and often connect over less consistent networks. Similarly, a metric aggregated across an entire site may mask the fact that one specific template or page type — a product page with many images, for instance — performs far worse than the rest of the site. Segmenting data by device type, connection speed, and page template usually reveals more than a single site-wide average.

Another useful lens is distinguishing between the “typical” experience and the “worst-case” experience. Core Web Vitals reporting tools commonly use percentiles — often the 75th percentile — rather than an average, specifically because averages can hide bad experiences that a meaningful share of visitors are having. Looking only at a median or mean score risks ignoring a slower segment of traffic that may represent a large number of actual visits. Understanding the distribution, not just a single summary number, gives a more honest picture of the experience being delivered.

Types / Subcategories

Largest Contentful Paint (LCP)

Largest Contentful Paint measures the point in time when the largest visible element within the viewport — typically a hero image, a large block of text, or a background image — finishes rendering. It exists because earlier loading metrics, such as the moment a page’s first byte arrives or the first pixel appears, didn’t reliably reflect when a visitor could actually see meaningful content. A page might technically “start” rendering quickly while the content a person actually came to see doesn’t appear for several more seconds.

A poor LCP score means a visitor is staring at a blank or mostly empty screen for an extended period before the primary content becomes visible. This delay is often caused by factors such as slow server response times, render-blocking resources that must be downloaded before the page can display anything, or large media files that take time to fetch. From the visitor’s point of view, a bad LCP feels like the page is “stuck” or unresponsive during the initial load, which can lead to uncertainty about whether the page is working at all.

Because LCP is tied to a specific, identifiable element on the page, it tends to be one of the more diagnosable metrics — the element responsible for the measurement can usually be pinpointed directly, which makes the underlying cause easier to trace even though this page does not cover remediation steps.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift measures unexpected movement of visible elements during the life of a page. It calculates a score based on how much of the viewport is affected by a shift and how far elements move, then accumulates these values across the page’s lifespan. It exists to quantify a specific kind of frustration: clicking a button only to have it move at the last second, or trying to read a paragraph that jumps downward as an image or advertisement loads in above it.

A poor CLS score reflects a visually unstable page — one where content is not reserved with proper space ahead of time, so elements like images, embeds, ads, or web fonts push other content around as they load in. For a visitor, this can mean accidentally tapping the wrong link, losing their place while reading, or simply perceiving the page as unpolished or unreliable. Unlike a slow load, a layout shift problem is often experienced as a jarring, disorienting moment rather than a passive wait.

CLS is somewhat unique among the three metrics in that it isn’t about time at all — it’s a unitless score representing the magnitude of visual disruption. A page can load quickly and still score poorly on CLS if its content continues to rearrange itself after the initial paint.

Interaction to Next Paint (INP)

Interaction to Next Paint measures the time between a visitor’s interaction — a click, tap, or keypress — and the moment the browser visually updates in response. It replaced an earlier metric called First Input Delay, which only measured the delay before the browser began processing the first interaction, without accounting for how long the full response actually took or considering interactions beyond the first one.

A poor INP score means that when someone clicks a button, opens a menu, or fills out a field, there’s a noticeable lag before anything visibly happens. This is typically caused by heavy scripts monopolizing the browser’s main thread, leaving it unable to process the interaction promptly. From a visitor’s perspective, a bad INP feels like the page is unresponsive or frozen — a common source of repeated clicking, frustration, or abandoning a task altogether.

Because INP is evaluated across the entire session rather than a single moment, it captures a more complete picture of interactivity than its predecessor. A page might respond quickly to an initial click but bog down during a later interaction, once more scripts have loaded or executed — INP is designed to catch that kind of inconsistency rather than judging only a page’s first response.

Field Data Versus Lab Data

Although not one of the three core metrics itself, understanding the distinction between field data and lab data is essential to interpreting Core Web Vitals correctly. Field data comes from actual visits by real users, aggregated over a rolling time window, and reflects the true diversity of devices, networks, and conditions those visitors experienced. Lab data, by contrast, comes from a controlled test run under fixed, repeatable conditions.

Lab data is useful for isolating and testing a specific scenario, since the conditions don’t change between runs. Field data is useful for understanding what visitors are genuinely experiencing, since it accounts for the full range of devices and connections in actual use. The two can diverge significantly — a page tested in a lab under fast, ideal conditions may show good scores while its field data, shaped by a wide range of real visitor conditions, tells a very different story.

Thresholds and Scoring Bands

Each Core Web Vitals metric is generally grouped into three bands: good, needs improvement, and poor. These bands exist to translate a raw number into a simple classification that’s easier to communicate and track over time. LCP is commonly considered good at or under roughly 2.5 seconds, CLS good at or under roughly 0.1, and INP good at or under roughly 200 milliseconds, with progressively higher values falling into the weaker bands.

These thresholds are based on research into the point at which delays or instability become perceptible and bothersome to most people, rather than being arbitrary technical benchmarks. They provide a shared reference point, allowing different pages, sites, or time periods to be compared using the same standard rather than relying on subjective judgment of what feels “slow” or “fast.”

Frequently Asked Questions

What are Core Web Vitals, in simple terms? They are a group of three measurements — LCP, CLS, and INP — that describe how quickly a page’s main content appears, how visually stable the page remains while loading, and how quickly it responds to interaction. Together they aim to represent the practical experience of using a page rather than purely technical loading statistics.

What is the difference between LCP, CLS, and INP? LCP measures loading speed by timing when the largest visible element appears. CLS measures visual stability by quantifying unexpected movement of elements. INP measures responsiveness by timing the delay between an interaction and the browser’s visual response. Each covers a different stage of the visitor’s experience on the page.

Why did Interaction to Next Paint replace First Input Delay? First Input Delay only measured the delay before the browser began handling the very first interaction on a page, without capturing how long the entire response took or accounting for later interactions during the session. INP was introduced to measure responsiveness more completely across the full visit, not just the initial moment.

Is field data more accurate than lab data? Neither is inherently more “accurate” — they serve different purposes. Field data reflects real visitor conditions across many devices and networks, which makes it representative of actual experience. Lab data is gathered under fixed, repeatable conditions, which makes it useful for isolating and studying a specific scenario in a controlled way.

Why are these specific three metrics used instead of older performance metrics? Earlier metrics tended to measure technical loading milestones that didn’t always align with what a person actually perceives while using a page. LCP, CLS, and INP were selected because each corresponds to a distinct, noticeable aspect of the experience — content appearing, layout staying stable, and the page responding to input — that visitors can directly perceive.

Core Web Vitals provide a structured way to describe how a page behaves from the moment it begins loading through the moments a visitor interacts with it. LCP addresses how quickly the main content becomes visible, CLS addresses whether the page stays visually steady, and INP addresses how promptly the page responds to input. Understood together, these three measurements offer a fuller picture of the practical, human experience of browsing a page than loading time alone ever could.