Core Web Vitals explained: LCP, CLS, and INP

LCP: how fast the main content shows up

Largest Contentful Paint measures how long it takes for the biggest visible element to render, usually the hero image, a headline, or a big block of text. It is a stand-in for the moment the page feels loaded to a visitor, rather than the moment the last byte arrives. Good is 2.5 seconds or under; anything past 4 seconds is poor.

Slow LCP usually comes from a slow server response, a large unoptimized hero image, or render-blocking CSS and JavaScript holding up the paint. The fixes follow the cause: speed up the server or add caching, compress and correctly size the main image and serve it in a modern format, and stop scripts and stylesheets from blocking the first render.

CLS: how much the page jumps around

Cumulative Layout Shift measures unexpected movement. You go to tap a button, an image finishes loading above it, the whole page lurches down, and you tap an ad instead. CLS scores how much the layout shifts as the page loads. It is a score rather than a time, and good is 0.1 or less, while above 0.25 is poor.

The usual culprits are images and embeds without dimensions, ads or banners that get inserted after the page starts rendering, and web fonts that swap in and reflow the text. The fixes are mostly about reserving space ahead of time: set width and height on images and video, leave a fixed slot for anything injected later, and load fonts so they do not cause a visible reflow.

INP: how quickly the page responds

Interaction to Next Paint measures responsiveness. When you click, tap, or type, how long until the page visibly reacts? INP looks across all your interactions on a page and reports close to the worst of them, so a single sluggish interaction can sink the score. Good is 200 milliseconds or under; above 500 is poor. INP replaced the older First Input Delay metric, which only measured the first interaction.

Poor INP almost always traces to JavaScript hogging the main thread. A heavy script runs when you interact, the browser cannot paint a response until it finishes, and the page feels frozen. The fixes are about getting work off the main thread: break long tasks into smaller chunks, defer or remove JavaScript you do not need, and avoid doing expensive work directly in response to every click or keystroke.

Lab data versus field data

There are two ways to measure these, and they often disagree. Lab data comes from a single test on a simulated device and connection. It is repeatable and great for debugging, because you can change one thing and rerun. Field data comes from real visitors on their real devices and networks, and it is what Google actually uses for ranking.

INP in particular can only be measured properly in the field, since it depends on how real people interact with the page. A page can score beautifully in a lab test and still fail in the field because your actual visitors are on slower phones than the test assumes. Use lab tools to diagnose and field data to judge whether you have genuinely fixed it.

A sane way to improve them

Do not try to fix everything at once. Measure first, find which of the three metrics is actually failing, and start there. Most pages are weak on one in particular rather than all three, and chasing a metric that already passes is wasted effort.

• Failing LCP: optimize the hero image, speed up the server response, and remove render-blocking resources.
• Failing CLS: set explicit dimensions on images and embeds and reserve space for anything that loads late.
• Failing INP: cut and defer JavaScript and break up long tasks so the main thread can respond.
• Measure again after each change, and trust field data over a single lab run for the final verdict.