LCP, INP, and CLS are the three metrics Google uses to measure real user experience. Here is what each one actually captures and where to focus your effort.
Core Web Vitals are Google’s attempt to turn “this page feels fast” into three measurable numbers. They are part of the page experience ranking signals, which means they affect search rankings — not dramatically, but measurably, and they are one of the few ranking factors you can fully control. The three current metrics are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift.
Largest Contentful Paint (LCP)
LCP measures loading performance. It records the time from navigation start to the moment the largest visible element in the viewport finishes rendering. That element is usually a hero image, a headline block, or a video poster. The threshold is 2.5 seconds for a “good” score; anything above 4 seconds is “poor.”
Because LCP keys off the largest element, the fix is almost always about that one element: serve it early, serve it fast, and do not block it. Common causes of a slow LCP are a large unoptimised hero image, a render-blocking stylesheet or script in the head, a slow server response (TTFB), or a hero image loaded lazily by mistake. Preload the hero image, compress it, serve a modern format, and make sure it is not deferred.
Interaction to Next Paint (INP)
INP replaced First Input Delay in 2024 as the responsiveness metric. It measures the time from a user input (a click, tap, or keypress) to the next frame the browser paints that reflects that input. It samples all interactions during the page lifetime and reports the worst (roughly the 98th percentile). A “good” INP is under 200 milliseconds; over 500 milliseconds is “poor.”
INP catches what LCP and CLS do not: a page that loads fast but feels sluggish when you interact with it. The usual culprits are long JavaScript tasks on the main thread, third-party scripts that run on every interaction, heavy event handlers, and unoptimised animations that fight the compositor. Break long tasks into smaller ones with setTimeout or scheduler.yield, defer non-critical JavaScript, and move work off the main thread with Web Workers where possible.
Cumulative Layout Shift (CLS)
CLS measures visual stability. It sums up every unexpected layout shift during the page’s life. A shift happens when an element changes position after it has rendered — an image pushes content down as it loads, a font swap reflows text, or a late-loading banner shoves the page. A “good” CLS is under 0.1; over 0.25 is “poor.”
CLS is the most preventable of the three. Always set width and height attributes on images and embeds so the browser reserves space before they load. Avoid injecting content above existing content. Reserve space for ads and dynamic widgets. Use font-display: optional or swap to avoid late font reflows. Most CLS issues come from missing dimensions on media, and they are cheap to fix.
How the three fit together
The three metrics cover the three phases of user experience: loading (LCP), responsiveness (INP), and visual stability (CLS). A page needs to pass all three to count as having a good page experience. They are measured on real Chrome users through the Chrome User Experience Report, so they reflect field data, not lab conditions. You can also measure them locally with Lighthouse and the web-vitals JavaScript library.
Where to focus
- Start with CLS — it is usually the cheapest to fix and the most visible to users.
- Then LCP — compress and preload the hero image, reduce TTFB, remove render-blocking resources.
- Then INP — audit JavaScript, break up long tasks, defer third-party scripts.
- Measure with field data (CrUX, Search Console) and confirm with lab data (Lighthouse).
- Re-check after every change. A single late-loading banner can undo weeks of work.
Core Web Vitals are not a one-time project. They are a discipline. Measure, fix, and measure again — and the same habits that improve them also make the page genuinely better for the people using it.