Core Web Vitals: what LCP, INP and CLS measure

What the three Core Web Vitals measure

Core Web Vitals are three metrics Google defines 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 meets the "good" bar when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less. Each limit is assessed at the 75th percentile of page loads, separately for mobile and desktop.

Google also publishes a "poor" limit for each metric. Anything between the two limits counts as "needs improvement".

LCP is good at 2.5 seconds or less and poor above 4 seconds.
INP is good at 200 milliseconds or less and poor above 500 milliseconds.
CLS is good at 0.1 or less and poor above 0.25. It is a unitless score, not a time.

Field data, lab data and the 75th percentile

Field data comes from real visits. The Chrome User Experience Report (CrUX) collects it from Chrome users who opted in, and PageSpeed Insights shows it for the previous 28 days. Search Console's Core Web Vitals report uses the same data.

The 75th percentile is the value that three out of four visits meet or beat. A page passes a metric only when at least three quarters of its visits are good, which an average cannot tell you.

Lab data comes from a test run in controlled conditions, such as Lighthouse or the Performance panel in Chrome DevTools. It is repeatable and good for debugging, but it reflects one device on one network. A page-load test has no user clicking anything, so it cannot report INP; Total Blocking Time is the usual lab stand-in.

When the two disagree, trust field data for what users experience and use the lab to find the cause.

Google Search uses Core Web Vitals among many signals in its ranking systems. Google also says relevance still comes first, so treat a good score as a user experience goal rather than a ranking shortcut.

LCP: why the main content loads slowly

LCP reports when the largest image, text block or video visible in the viewport finishes rendering, timed from the start of navigation. The browser stops looking for new candidates once the user taps, scrolls or presses a key.

A slow LCP breaks down into four parts, and each has its own fixes:

Slow time to first byte (TTFB) delays everything after it. Uncached server rendering and redirect hops are common causes; caching HTML at a CDN and linking to final URLs both help.
Resource load delay means the browser found the LCP image late, often because it is a CSS background, is inserted by JavaScript or has loading="lazy". Put it in the HTML as an img element and never lazy-load it.
Resource load duration is the download itself. Serve the image in WebP or AVIF at the size it is displayed, and add fetchpriority="high" so it downloads ahead of less important files.
Element render delay means the image has arrived but render-blocking CSS, scripts or client-side rendering hold it back. Trim the CSS needed for the first view and defer scripts.

INP: why clicks and key presses feel slow

INP observes every click, tap and key press during a visit and reports one of the slowest, ignoring one outlier for every 50 interactions. Hovering and scrolling do not count. Each interaction is timed from the input until the browser paints the next frame.

INP replaced First Input Delay (FID) in the Core Web Vitals in March 2024. FID measured only the wait before the first interaction started processing, so a page could pass it while every later click was slow.

Interaction latency has three parts, each with its own fixes:

Input delay is time spent waiting because the main thread is busy, for example with a large script that is still running. Break long tasks into smaller ones and yield to the main thread between them.
Processing time is the event handlers themselves. Make the visible update first and move analytics calls and other non-urgent work until after the next paint.
Presentation delay is the style, layout and paint work for the next frame. Large DOMs and forced layouts make it longer.

CLS: what makes a page jump

CLS adds up unexpected layout shifts, where visible elements move after they were drawn. Shifts close together are grouped into windows of up to 5 seconds, and CLS reports the window with the highest total. Shifts within 500 milliseconds of a click, tap or key press count as expected and are left out.

Each shift is scored by the share of the viewport affected multiplied by how far the elements moved. Most shifts come from content that arrives without space reserved for it:

Images, videos and iframes without width and height attributes. Add them, or set a CSS aspect-ratio, so the browser reserves the box before the file loads.
Ads, embeds and banners injected above existing content. Reserve their space with a min-height, or place them below what the user is reading.
Web fonts that swap in with different metrics. A fallback font with similar metrics, or the size-adjust descriptor in @font-face, keeps the swap from moving text.
Animations of top, left, width or height. Animate transform instead, which does not move surrounding content and does not count as a layout shift.

What the three Core Web Vitals measure

Google also publishes a "poor" limit for each metric. Anything between the two limits counts as "needs improvement".

LCP is good at 2.5 seconds or less and poor above 4 seconds.

INP is good at 200 milliseconds or less and poor above 500 milliseconds.

CLS is good at 0.1 or less and poor above 0.25. It is a unitless score, not a time.

Field data, lab data and the 75th percentile

The 75th percentile is the value that three out of four visits meet or beat. A page passes a metric only when at least three quarters of its visits are good, which an average cannot tell you.

When the two disagree, trust field data for what users experience and use the lab to find the cause.

LCP: why the main content loads slowly

A slow LCP breaks down into four parts, and each has its own fixes:

Slow time to first byte (TTFB) delays everything after it. Uncached server rendering and redirect hops are common causes; caching HTML at a CDN and linking to final URLs both help.

Resource load delay means the browser found the LCP image late, often because it is a CSS background, is inserted by JavaScript or has loading="lazy". Put it in the HTML as an img element and never lazy-load it.

Resource load duration is the download itself. Serve the image in WebP or AVIF at the size it is displayed, and add fetchpriority="high" so it downloads ahead of less important files.

Element render delay means the image has arrived but render-blocking CSS, scripts or client-side rendering hold it back. Trim the CSS needed for the first view and defer scripts.

INP: why clicks and key presses feel slow

Interaction latency has three parts, each with its own fixes:

Input delay is time spent waiting because the main thread is busy, for example with a large script that is still running. Break long tasks into smaller ones and yield to the main thread between them.

Processing time is the event handlers themselves. Make the visible update first and move analytics calls and other non-urgent work until after the next paint.

Presentation delay is the style, layout and paint work for the next frame. Large DOMs and forced layouts make it longer.

CLS: what makes a page jump

Each shift is scored by the share of the viewport affected multiplied by how far the elements moved. Most shifts come from content that arrives without space reserved for it:

Images, videos and iframes without width and height attributes. Add them, or set a CSS aspect-ratio, so the browser reserves the box before the file loads.

Ads, embeds and banners injected above existing content. Reserve their space with a min-height, or place them below what the user is reading.

Web fonts that swap in with different metrics. A fallback font with similar metrics, or the size-adjust descriptor in @font-face, keeps the swap from moving text.

Animations of top, left, width or height. Animate transform instead, which does not move surrounding content and does not count as a layout shift.