Understanding and Improving Core Web Vitals

What Google actually measures

Google does not judge the quality of a page by feel but by measurable values. Three of them have formed the Core Web Vitals since 2020 and have fed into ranking as a signal ever since. They describe three different aspects of the experience a page produces in the browser.

Largest Contentful Paint (LCP) captures when the largest visible element has loaded. That is usually the hero image or the main heading. Interaction to Next Paint (INP) measures how quickly the page responds to input, such as a click or a keystroke. Cumulative Layout Shift (CLS) describes how much content jumps around while loading.

INP replaced the older metric First Input Delay in March 2024. The reason lies in accuracy. FID measured only the delay of the first interaction, whereas INP looks at all interactions across the whole session and reports the near-worst value.

The three values and their thresholds

Each metric has three ranges. What counts is always the 75th percentile of real page loads, the value that three out of four visits reach or beat. A page passes only when all three values sit in the green range.

A page passes the Core Web Vitals only when LCP, INP and CLS sit in the green range at the same time. A single outlier drags the overall verdict down.

LCP, when the content becomes visible

LCP is the time until the largest visible element appears. Four factors determine this value, and each of them can be addressed deliberately.

The first is the server response time, measured as Time to First Byte. The longer it runs, the later loading begins, and the whole LCP shifts back. A CDN in front, server-side rendering and lean database queries shorten this phase. The second factor is render-blocking resources. CSS and render-blocking JavaScript delay the first meaningful frame, so critical CSS belongs inline in the head of the page while the rest loads asynchronously.

The third factor is the LCP resource itself. If the largest element is an image, a modern format such as WebP or AVIF helps, along with a fitting size instead of an oversized original and a fetchpriority="high" on the decisive image. The fourth factor is client-side rendering. If the main content is assembled only through JavaScript, the LCP shifts later, which is why the most important content should already sit in the delivered HTML.

INP, how quickly the page responds

INP measures the span between an input and the next visible response on screen. High values almost always come from an overloaded main thread. When JavaScript runs long tasks there, the browser can only react to clicks once the task has finished.

The most effective levers therefore target the main thread.

• Split long tasks into smaller chunks, so the browser can respond to input in between
• Defer non-urgent work, for example through requestIdleCallback or scheduler.yield
• Move heavy computation into a Web Worker, away from the main thread
• Reduce the amount of delivered JavaScript, since less code means less execution
• Audit third-party scripts, because analytics and chat tools often load the main thread unnoticed

INP can only be judged fully in the field, because real interactions are required. Lab data gives an indication, while the binding verdict comes from field data in the Chrome User Experience Report.

CLS, why the layout must stay calm

CLS describes content jumping around while loading. The classic case is a click that misses, because an image or a banner pushes in at the last moment. The value is not a measure of time but a ratio that combines the area and the distance of the shifts.

The causes are limited and therefore manageable. Images and videos without fixed dimensions reserve no space, so width and height or a defined aspect-ratio belong on every medium. Fonts that load late and rewrap the text shift the layout, which can be avoided with font-display: optional or preloaded fonts. Elements inserted afterward, such as banners or notices, need reserved space instead of pushing existing content down.

Implementing animations correctly

Motion is fine as long as it does not shift the layout. Transformations through transform and opacity run outside the layout flow and do not count toward CLS. Animations through top, left, width or height, by contrast, trigger reflows and worsen the value.

Lab versus field, both have a role

There are two sources for measurement, and they complement each other. Lab data comes from a controlled environment with fixed CPU throttling and a defined connection. Lighthouse in the Chrome DevTools provides it and suits debugging, because the result is reproducible.

Field data comes from real visits and feeds into ranking through the Chrome User Experience Report. PageSpeed Insights shows both sources side by side, and the Search Console aggregates the field data across all pages of a domain. Before any claim about performance comes the measurement on a throttled CPU, not the guess.

A number without a measurement context is worthless. Only the note of whether a value comes from the lab or the field makes it comparable.

A practical approach

The three values are connected but can be addressed separately. A sensible order is LCP, then CLS, then INP, because the first two are usually solvable with clearly defined changes, while INP needs a closer look at how the JavaScript behaves.

This approach follows our method. First think further about the biggest brake, then plan further in which order the levers take hold, then build further, and finally go further by monitoring the values in the field over time. More on this stance is on the Mission page. Anyone who wants to know the current state of a page can request a measurement through the Contact page.

---

A measurement with concrete before-and-after values shows where a page really stands on LCP, INP and CLS. We measure and optimize.