Core Web Vitals: The Metrics Google Actually Measures

What Core Web Vitals Are

Core Web Vitals are three metrics Google settled on to answer a question that used to be impossible to measure objectively: does this page feel good to use? Speed alone never captured it. A page could load its HTML in under a second and still feel broken if the text jumped around while images loaded, or if tapping a button did nothing for half a second. Google needed metrics that reflected the actual human experience of a page, not just how fast the server responded.

The three vitals each measure a different dimension of that experience. Largest Contentful Paint measures loading, specifically how long it takes for the largest visible element to appear. Cumulative Layout Shift measures visual stability, how much the page jumps around as it loads. Interaction to Next Paint measures responsiveness, how quickly the page reacts when a user taps or clicks. Loading, stability, responsiveness. Three questions a real visitor asks without realizing they are asking them.

What makes the vitals different from the page speed metrics that came before is that they are anchored to thresholds based on user research, not arbitrary targets. Google studied how real people perceive delays and instability and set the “good” thresholds at the point where experience degrades noticeably. Hitting those thresholds is not about impressing a testing tool. It is about staying inside the range where the page feels right to the person using it.

Largest Contentful Paint (LCP)

Largest Contentful Paint measures how long it takes for the largest content element in the viewport to render. On most pages that is a hero image, a large heading, or a block of text above the fold. LCP answers the visitor’s first impatient question: when can I see the thing I came here for?

Google’s threshold for good LCP is 2.5 seconds or less, measured at the 75th percentile of page loads. That last detail matters and most explanations skip it. The score is not your average load time. It is the experience of your slower visitors, the ones at the 75th percentile, which means a quarter of your traffic can be slower than your reported number. If your LCP reads 2.5 seconds, plenty of real users are waiting longer than that.

LCP problems usually trace back to a handful of causes: a slow server response that delays everything downstream, render-blocking CSS and JavaScript that the browser has to process before it can paint, large unoptimized images that take too long to download, or client-side rendering that makes the browser build the page before anything appears. This is the loading speed metric most worth attacking first when a page feels slow.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift measures visual stability. Specifically, it quantifies how much the visible content moves around unexpectedly while the page loads. Everyone has experienced bad CLS without knowing the name for it. You go to tap a link, an ad or image finishes loading above it, the whole page jumps, and you tap the wrong thing. That jump is layout shift, and Google measures it.

The threshold for good CLS is a score of 0.1 or less. Unlike LCP, CLS is not measured in seconds. It is a unitless score calculated from how much of the viewport shifted and how far it moved. A small element nudging slightly scores low. A large block jumping halfway down the screen scores high. The score accumulates across the whole page load, hence “cumulative.”

Most layout shift comes from a few predictable sources. Images and videos without width and height attributes, so the browser does not reserve space for them before they load. Ads, embeds, and iframes that inject themselves into the layout after the page has rendered. Web fonts that cause text to reflow when the custom font swaps in. Content injected dynamically above existing content. The fix in almost every case is reserving the space in advance so nothing has to move when the asset arrives.

Interaction to Next Paint (INP)

Interaction to Next Paint is the newest of the three. It replaced First Input Delay in March 2024, and the change was a meaningful upgrade. First Input Delay only measured the delay before the browser began processing the first interaction. INP measures the full latency of interactions throughout the entire visit, from the moment a user taps or clicks to the moment the screen visually updates in response.

The threshold for good INP is 200 milliseconds or less. When a user taps a button, opens a menu, or expands an accordion, the page should respond within that window or the interaction starts to feel sluggish. INP captures the worst interactions across the session, so a page that responds instantly most of the time but hangs for half a second on one heavy interaction will still score poorly.

INP problems are almost always JavaScript problems. Heavy scripts that monopolize the main thread, long-running event handlers, large JavaScript bundles that the browser has to parse and execute, and third-party scripts that block interactivity. When the main thread is busy running code, it cannot respond to the user, and the interaction stalls. Reducing and deferring JavaScript is the core of fixing INP.

Field Data vs Lab Data

This is the distinction that trips up most people, and getting it wrong leads to wasted effort. There are two kinds of Core Web Vitals measurement, and only one of them affects your rankings.

Field data, also called real user monitoring, comes from actual visitors using your page on their own devices and connections. Google collects this through the Chrome User Experience Report, aggregating the experience of real Chrome users over a rolling 28-day window. This is the data Google uses for ranking. It reflects reality: slow phones, spotty connections, real-world conditions.

Lab data comes from a controlled test run in a simulated environment, like the test a tool runs on demand from a data center with a fast connection. Lab data is useful for debugging because it is repeatable and gives you immediate feedback on changes. But it does not reflect your actual users, and it is not what Google ranks on. A page can post excellent lab scores and still fail its field vitals because the lab test ran on infrastructure no real visitor has access to.

The practical implication: use lab data to diagnose and verify fixes, but judge your actual standing by field data. The tools that report these metrics, covered in the the metrics that matter section of our speed test guide, show both, with field data taking priority when Google has enough real traffic to report it. If you only look at the lab score, you may be optimizing for a test that does not match what your users experience or what Google measures.

How Core Web Vitals Affect Rankings

Core Web Vitals are a ranking signal, but understanding their actual weight prevents both neglect and obsession. They are part of Google’s page experience signals, and Google has been consistent that page experience is a tiebreaker, not a primary factor. Content relevance and quality come first. When two pages are closely matched on relevance, the better page experience can be the deciding factor.

What this means in practice: passing Core Web Vitals will not rocket a thin, irrelevant page to the top. But failing them can hold back a strong page that would otherwise rank well, especially in competitive results where the margins between pages are narrow. The vitals are most worth your attention when your content is already solid and you are looking for the edge that moves you from position six to position three.

There is also a conversion argument that exists independently of rankings. Pages that load fast, stay stable, and respond quickly keep users engaged. Slow, janky pages get abandoned. Even if Core Web Vitals carried zero ranking weight, the user experience they measure directly affects whether visitors stay, read, and convert. The ranking benefit is real but secondary to the simple fact that a better-performing page serves the people who land on it.

FAQ

What are the three Core Web Vitals?

The three Core Web Vitals are Largest Contentful Paint (LCP), which measures loading performance; Cumulative Layout Shift (CLS), which measures visual stability; and Interaction to Next Paint (INP), which measures responsiveness. INP replaced First Input Delay in March 2024.

What are good Core Web Vitals scores?

Good scores are LCP of 2.5 seconds or less, CLS of 0.1 or less, and INP of 200 milliseconds or less. These thresholds are measured at the 75th percentile of real user page loads, meaning your slower visitors count toward the score, not just your average.

Do Core Web Vitals affect SEO rankings?

Yes, but as part of Google’s page experience signals, which function as a tiebreaker rather than a primary ranking factor. Content relevance and quality come first. Core Web Vitals can be the deciding factor between closely matched pages in competitive results, and failing them can hold back an otherwise strong page.

What is the difference between field data and lab data?

Field data comes from real visitors using your page on their own devices, collected by Google through the Chrome User Experience Report, and it is what Google uses for ranking. Lab data comes from a controlled simulated test, useful for debugging but not used for ranking. A page can pass lab tests while failing field data.

Why did INP replace First Input Delay?

First Input Delay only measured the delay before the browser began processing the first interaction on a page. Interaction to Next Paint measures the full latency of all interactions throughout the visit, from input to visual response, making it a far more complete measure of how responsive a page actually feels to use.

How long do Core Web Vitals take to update?

Field data in the Chrome User Experience Report is based on a rolling 28-day window. After you deploy a fix, it can take up to 28 days for the field data to fully reflect the improvement, because the metric averages the experience of all users over that period. Lab data updates immediately on each test.