Core Web Vitals simply explained: LCP, INP, CLS

What are Core Web Vitals?

Core Web Vitals are a small selection of metrics from Google’s larger Web Vitals program that make the quality of a website’s user experience measurable. They answer three simple questions from your visitors’ perspective: does the page load fast? Does it respond quickly to my clicks? Does the layout stay calm while it loads? These three aspects are called loading performance, interactivity, and visual stability.

What is special is that the values do not come from a lab but from the real behavior of Chrome users on your page. Google collects this anonymized data in the Chrome User Experience Report (CrUX) and uses it to judge how your page actually feels. That makes Core Web Vitals not a pure developer topic but a direct measurement of what visitors experience.

The three metrics: LCP, INP, and CLS

Each of the three metrics covers a different part of the user experience and has a clearly defined threshold for good. Important: Google always evaluates the 75th percentile of your page views. That means at least 75% of visits have to be in the green zone for the page to pass. A single good test run is not enough.

LCP: Largest Contentful Paint

LCP measures loading performance: the time until the largest visible element in the viewport is fully rendered. Usually that is a hero image, a large block of text, or a video. The value tells you when the visitor feels the page has finished loading. A good LCP is under 2.5 seconds, needs-improvement up to 4 seconds, anything above is poor.

Typical causes of a bad LCP are slow server response times (a high Time to First Byte), large uncompressed images, and render-blocking JavaScript or CSS. A common mistake: lazy-loading the hero image. That exact LCP element should load immediately, not later.

INP: Interaction to Next Paint

INP measures interactivity: how quickly the page reacts to user interactions. When you click a button, type, or open a menu, INP measures the time until the page visibly responds. Unlike its predecessor, INP does not only look at the first interaction but at all interactions during the visit and reports the longest. A good INP is under 200 milliseconds, needs-improvement up to 500 milliseconds, above that is poor.

Important for 2026: INP officially replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. If you still read FID somewhere, the source is outdated. The most common cause of poor INP is heavy JavaScript blocking the main thread, plus too many event listeners and third-party scripts like chat widgets, analytics, or ads.

CLS: Cumulative Layout Shift

CLS measures visual stability: how much visible elements shift unexpectedly while loading. Everyone knows the moment when you try to tap a button and it jumps away at the last second because an image or banner loaded in. CLS bundles all these shifts into a single value. A good CLS is under 0.1, needs-improvement up to 0.25, above that is poor. CLS has no unit because it is a ratio of shift distance to viewport.

Typical causes are images without fixed width and height, dynamically loaded ad banners, web fonts that reflow text after the fact, and embeds without reserved space. The fix is almost always to reserve the space upfront, for example via fixed dimensions or the CSS aspect-ratio property.

How do you measure your Core Web Vitals?

When measuring, there is one distinction that decides everything: lab data versus field data. Mixing them up means optimizing in the wrong place. For Google ranking, only the field data counts.

Field data versus lab data

Lab data comes from a controlled, simulated environment, for example with Google Lighthouse. It is ideal for debugging and repeatable tests during development because it is stable and reproducible. But it does not reflect what real users on real devices experience. One note: INP cannot be measured directly in the lab because nobody interacts there. Lighthouse uses Total Blocking Time (TBT) as a proxy instead.

Field data is the values of real Chrome users, collected in the Chrome User Experience Report. This is exactly the data Google uses for ranking and shows in the Core Web Vitals report of the Search Console. The classic mistake: celebrating a green Lighthouse score of 95 while the field data is red. What counts is the field.

The right tools

To get started, a few free Google tools that cover all three metrics are enough. PageSpeed Insights (pagespeed.web.dev) is the best starting point: it shows both field and lab data separately for mobile and desktop and gives concrete recommendations. The Core Web Vitals report in Google Search Console gives you the overview of all URLs on your site, grouped by status and page type, and shows trends over time. For detailed analysis of single pages, use Chrome DevTools with the Lighthouse and Performance tabs. If you want your own live monitoring, measure with the web-vitals JavaScript library directly in your own code.

How do you improve each metric?

Optimization follows diagnosis. Instead of blindly installing plugins, you tackle the causes per metric. Here are the most effective levers, sorted by the three values.

Improving LCP

LCP is usually the easiest to improve because the causes are clear: large files and slow response times. First optimize your images with modern formats like WebP or AVIF, which are 30 to 50% smaller than JPEG or PNG, and deliberately do not lazy-load the hero image. Lower server response time through good hosting, caching, and a CDN that serves content from the nearest server. And eliminate render-blocking resources by inlining critical CSS and loading JavaScript with defer or async.

Improving INP

INP is technically more demanding because it hinges on JavaScript. The most effective lever is shipping less and leaner JavaScript: code splitting so only what the page truly needs is loaded, and breaking up long tasks that block the main thread beyond 50 milliseconds. Cut third-party scripts down to the essentials, because every tracking pixel and chat widget costs response time. For heavy computations, web workers that offload work to a separate thread help, as do debouncing and throttling on scroll or resize events.

Improving CLS

CLS is often the quickest to fix once you know where the jumps come from. Always give images and videos fixed width and height, or use aspect-ratio in CSS, so the browser reserves the space before the element loads. Reserve fixed containers for dynamic content like ad banners and embeds. Load web fonts cleanly with font-display: swap and preload, so text does not reflow afterward. And animate via transform instead of top or left, because CSS transforms do not trigger layout shifts.

Validating your fix

Once you have fixed a problem, do not confirm it with a single lab test but in the Search Console. There you start a 28-day monitoring period via "Validate fix". Google checks whether the improvement has actually reached real users in the field data. Because CrUX is based on a rolling 28-day window, changes need time accordingly until they fully show up in the values. Patience is part of the process here.

How important are Core Web Vitals for ranking, really?

An honest classification: Core Web Vitals have been a confirmed Google ranking factor since June 2021, part of the so-called page experience signals. But they are one of hundreds of factors. Relevant, good content beats performance almost every time. A fast page without fitting content does not rank just because it is fast.

In practice, Core Web Vitals act as a tie-breaker: when two pages are equal in content and authority, the technically better one wins. In Google Search Console, Google also groups URLs with a similar structure, so a template problem can flip the status of hundreds of pages at once. Currently (CrUX release May 2026), around 55.9% of all tracked sites pass all three Core Web Vitals at once, with 68.6% good LCP, 86.6% good INP, and 81.3% good CLS. So there is still an edge to be gained.

The stronger reason is not ranking anyway but business. Fast, stable pages keep visitors and convert better. When Vodafone Italy improved its LCP by 31%, sales rose by 8% and leads by 15%. Performance is therefore less an SEO trick than a direct revenue lever, which fits neatly with conversion optimization.

Why we build performance in from the start

Here is the point many guides skip: most Core Web Vitals problems are homemade and stem from how the website is built. An overloaded WordPress theme with page-builder bloat, five overlapping plugins, and cheap shared hosting are hard to rescue after the fact. You then spend months optimizing against your own architecture.

We take the opposite route. On Webflow and Next.js we build performance into the structure from the start: server-side rendering, lean JavaScript, optimized images, and fixed layout dimensions are standard for us, not an afterthought. With Next.js, automatic image optimization, code splitting, and modern rendering strategies come on top, directly benefiting LCP and INP. The result is pages that do not scrape the green thresholds but clear them with a buffer, because the foundation is right. That is exactly why a fast page is not an extra project for us but part of how we build, and a key reason a relaunch without SEO loss also succeeds cleanly on the technical side.

Frequently asked questions