Core Web Vitals explained: LCP, INP and CLS in plain terms

What Core Web Vitals are

Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor: how quickly the main content appears, how quickly the page reacts when someone taps or types, and whether things jump around while it loads. They are defined and maintained by the Chrome team on web.dev, and Google Search recommends that site owners achieve good scores as part of a wider page experience (more on that below).

The current set is:

Metric	What it measures	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	Loading: when the biggest visible element has rendered	2.5 s or less	2.5 s to 4.0 s	Over 4.0 s
Interaction to Next Paint (INP)	Responsiveness: delay between an interaction and the next visual update	200 ms or less	200 ms to 500 ms	Over 500 ms
Cumulative Layout Shift (CLS)	Visual stability: how much content moves unexpectedly	0.1 or less	0.1 to 0.25	Over 0.25

Thresholds are from the web.dev pages for LCP, INP and CLS.

Two details matter as much as the numbers. First, each metric is judged at the 75th percentile of page loads, so three out of four visits need to be in the “good” range, not just the average. Second, results are assessed separately for mobile and desktop. A page passes only when all three metrics are good at the 75th percentile (web.dev).

INP replaced FID in March 2024

If you read older material, you will see First Input Delay (FID) listed as the responsiveness metric. FID only measured the delay before the browser started handling the first interaction on a page. Interaction to Next Paint replaced it as a Core Web Vital on 12 March 2024 (web.dev announcement). Search Console dropped FID on that date; PageSpeed Insights and the Chrome UX Report kept it for a six-month deprecation period.

INP is a much stricter test. It watches every click, tap and key press during the visit (scrolling and hovering are not counted) and, for each one, measures the full time until the browser paints the next frame: the wait before event handlers start, the time the handlers take, and the time to render the result (web.dev). The reported value is usually the slowest interaction; on pages with many interactions, one outlier is ignored for every 50 interactions so a single freak event does not dominate.

What each metric actually counts

LCP

LCP looks at the largest image, video poster or text block visible in the viewport and records when it finished rendering, measured from the moment the user started navigating (web.dev). Eligible elements include <img>, <image> inside SVG, <video>, elements with a CSS url() background image, and block-level text. Gradients do not count. Because timing starts at navigation, redirects, connection set-up and server response time are all part of LCP.

INP

INP is about the main thread. Anything that keeps the browser busy, such as a large JavaScript bundle being parsed, a heavy click handler or a big re-render, delays the visual response to the user’s action.

CLS

Each unexpected movement gets a layout shift score: the share of the viewport affected multiplied by how far things moved relative to the viewport (web.dev). Shifts that happen close together (each within one second of the last, capped at five seconds) are grouped into a “session window”, and CLS is the worst window on the page. Movement within 500 ms of a tap, click or key press is treated as expected and excluded, which is why opening an accordion does not count against you.

Field data versus lab data

This is where many teams go wrong. There are two kinds of measurement, and they answer different questions.

Field data comes from real visitors. Google’s source is the Chrome User Experience Report (CrUX), which reports on a rolling 28-day window (web.dev). PageSpeed Insights and the Core Web Vitals report in Search Console both surface it. You can also collect your own field data with the open-source web-vitals JavaScript library and send it to your analytics (web.dev).

Lab data comes from a scripted test on a fixed device and network, typically Lighthouse or Chrome DevTools. It is repeatable, which makes it ideal for debugging and for checking a change before release. But Lighthouse cannot measure INP at all, because there is no real user interacting; it reports Total Blocking Time as a proxy (web.dev).

The two often disagree, for good reasons (web.dev):

Real visitors arrive with warm caches, or return via the back/forward cache, while lab tests usually start cold.
The LCP element can differ by screen size, personalisation or A/B test.
Lab tests only see layout shifts during load; real users also trigger shifts while scrolling.
Lab tests cannot predict when real people will interact, so they miss slow interactions entirely.

The practical rule from web.dev is to use field data to decide what to work on and lab data to work out why. A perfect Lighthouse score with poor field INP still means real users are waiting.

Common fixes, metric by metric

Improving LCP

Google’s guide to optimising LCP splits the metric into four parts: time to first byte, resource load delay, resource load duration and element render delay. As a rough guide, most of the time should go on the server response and on downloading the resource, with the two “delay” parts close to zero. The fixes follow from that:

Make the LCP image discoverable early. Put it in the HTML as an <img> with src or srcset, not as something injected later by JavaScript. If it is only referenced from CSS, preload it.
Prioritise it. Add fetchpriority="high" to the likely LCP image (one or two images at most) and never lazy-load it.
Shrink it. Serve correctly sized images in modern formats, compressed, ideally from a CDN close to your users.
Unblock rendering. Cut render-blocking CSS, defer non-critical scripts, and avoid synchronous scripts in the <head>. Server-side rendering or pre-rendering avoids waiting for JavaScript to build the page.
Speed up the HTML. Reduce redirects and make sure pages can be served from CDN edge caches; unique query parameters can defeat this.

Improving INP

From the guide to optimising INP and the companion article on long tasks (any task over 50 ms):

Break up long tasks. Yield to the main thread so the browser can paint between chunks of work, using scheduler.yield() where supported or setTimeout as a fallback.
Do less in event handlers. Update only what the next frame needs, then defer the rest.
Avoid layout thrashing. Do not read layout values (such as an element’s height) straight after changing styles in the same task; it forces a synchronous layout.
Keep the DOM lean. Large DOMs make every render more expensive. content-visibility can defer off-screen work.
Audit JavaScript at load. Script parsing and execution during start-up is a common cause of slow first interactions. Third-party tags deserve particular scrutiny.

Improving CLS

From the guide to optimising CLS:

Always set width and height on images and video, or use CSS aspect-ratio, so the browser reserves space before the file arrives.
Reserve space for ads, embeds and iframes with a fixed min-height or aspect ratio, including when no ad is returned.
Do not insert content above existing content (cookie bars, promos, “related” widgets) unless the user asked for it. Place late-loading content lower down or in fixed-size containers.
Animate with transform, not top, left or other layout properties.
Tame web fonts. Use font-display: optional or a well-matched fallback with size-adjust and related overrides, and preload critical fonts.
Stay eligible for the back/forward cache, so returning visitors get the page restored instantly with no new shifts.

How much do Core Web Vitals matter for search?

Google’s Search documentation recommends achieving good Core Web Vitals and says that this, together with other page experience aspects, lines up with what its core ranking systems reward. It does not promise a ranking boost for passing. The fairer way to see it: relevance and content quality come first, and Core Web Vitals are a measure of whether people can actually use what you built. Slow, jumpy pages lose visitors regardless of where they rank.

A practical workflow

Start with field data. Open the Core Web Vitals report in Search Console or run key URLs through PageSpeed Insights. Note which metric fails, on which device type, and for which group of pages.
Reproduce in the lab. Use Chrome DevTools’ Performance panel on a throttled mobile profile to see what is happening on the main thread and which element is the LCP.
Fix templates, not pages. Most problems live in shared layouts, components or third-party tags, so one fix often covers hundreds of URLs.
Add real-user monitoring. The web-vitals library gives you per-page, per-release data instead of waiting on a 28-day rolling window.
Guard against regressions. Put Lighthouse checks and a JavaScript size budget into your build pipeline, and review third-party scripts before they are added.

Sources

Facts in this article were checked against the linked sources on 9 October 2026. Rules, prices and standards change; check the source before relying on a detail. This article is general information, not legal or financial advice.