Core Web Vitals: LCP, INP, CLS — what Google actually measures

LCP measures the time it takes to render the largest visible element in the viewport. In practice, this is most often a hero image, a large photo, or a main heading.

It's the metric that best corresponds to the user's perception of "the page has loaded." Not when the first pixel appears (FCP), nor when everything is fully interactive (TTI) — when the main content is visible.

LCP Thresholds

• Good: under 2.5 seconds
• Needs improvement: between 2.5 and 4 seconds
• Critical: over 4 seconds

Common causes of degraded LCP

• Slow server (high TTFB): if the server takes 2 seconds to respond, LCP cannot be good. This is the first bottleneck to fix.
• Unoptimized images: an uncompressed hero image in JPEG/PNG instead of WebP, without proper sizing, is often the main culprit.
• Render-blocking resources: CSS and JavaScript loaded synchronously that delay content rendering.
• Client-side rendering (CSR): sites built with JavaScript frameworks like React or Vue in CSR mode must execute JS before displaying anything.

INP (Interaction to Next Paint) officially replaced FID (First Input Delay) in March 2024. This is the most significant change to Core Web Vitals since their launch.

Where FID only measured the delay on the very first interaction, INP measures the latency of all interactions throughout the session: clicks, taps, keystrokes. It records the 98th percentile — meaning a single slow interaction can be enough to degrade the score.

In practice, INP measures the time between the user interacting (click, tap, key press) and the browser displaying the next visual update. It's perceived responsiveness.

INP Thresholds

• Good: under 200 milliseconds
• Needs improvement: between 200 and 500 milliseconds
• Critical: over 500 milliseconds

Common causes of degraded INP

• Heavy JavaScript on the main thread: long calculations, complex loops or excessive DOM rendering operations block the thread and delay response.
• Long Tasks: any JS task that runs for more than 50ms on the main thread is considered long and can affect INP.
• Third-party scripts: analytics, chatbots, ads, social media plugins — each third-party script adds load on the main thread.
• Heavy event handlers: event listeners that trigger style recalculations or complex repaints on every interaction.

CLS measures the visual stability of the page during loading. It quantifies how much elements move unexpectedly — that frustrating phenomenon where you're about to click a button and the content shifts just before your click.

Technically, CLS is the product of the impact fraction (what portion of the screen moved) multiplied by the distance fraction (how far the element moved). It's a unitless value, not a time measure.

Since 2021, Google has refined CLS measurement to use "session windows": it no longer measures the sum of all shifts, but the worst group of shifts occurring within a 1-second window, separated by at least 5 seconds.

CLS Thresholds

• Good: under 0.1
• Needs improvement: between 0.1 and 0.25
• Critical: over 0.25

Common causes of degraded CLS

• Images without dimensions: if img tags lack width and height attributes, the browser doesn't reserve space and content shifts when the image loads.
• Dynamically injected content: cookie banners, popups, ads loaded after initial render that push content downward.
• Web fonts (FOUT/FOIT): when a web font loads and replaces the fallback font, metric changes can shift text and surrounding elements.
• Unoptimized CSS animations: using transform and opacity instead of top/left/width/height for animations avoids layout recalculations.