Core Web Vitals: LCP, INP and CLS Explained for Site Owners

Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors: how fast the main content appears, how quickly the page responds when you tap something, and whether things jump around while it loads. They are part of Google's page experience signals. They matter, but less than many audit reports suggest. A slow page with the best answer still tends to outrank a fast page with a weak one.

That said, a page that frustrates visitors loses them, and you'll feel that in conversions long before you feel it in rankings.

The three metrics

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element, usually a hero image, a banner or a big block of text, to render. Google's "good" threshold is 2.5 seconds or less. Above 4 seconds is "poor".

On most sites I look at, the LCP element is a large hero image that is uncompressed, lazy-loaded by mistake, or loaded late because a slider script has to run first.

Interaction to Next Paint (INP)

INP replaced First Input Delay as a Core Web Vital in March 2024. It looks at how quickly the page visually responds after a user clicks, taps or types, across the whole visit, and reports roughly the worst interaction. Good is 200 milliseconds or less; above 500 ms is poor.

Poor INP almost always comes from heavy JavaScript keeping the browser's main thread busy: big frameworks, tag managers loaded with a dozen marketing scripts, chat widgets, and analytics added on top of analytics.

Cumulative Layout Shift (CLS)

CLS measures how much visible content moves unexpectedly while the page is in use. Good is 0.1 or lower; above 0.25 is poor. You know this one from experience: you go to tap "Add to cart" and an ad loads above it, so you tap something else.

Field data vs lab data

This is where people get confused. There are two kinds of measurement:

• Field data comes from real Chrome users through the Chrome User Experience Report (CrUX). This is what Google uses for ranking signals. It's shown in Search Console's Core Web Vitals report and at the top of PageSpeed Insights, over a rolling 28-day window.
• Lab data comes from a simulated test, such as Lighthouse. It's great for debugging but it's one device on one connection at one moment.

A page can score 45 in Lighthouse and still pass Core Web Vitals in the field, because real visitors are on better devices than the simulation. The reverse also happens. When they disagree, trust the field data for SEO decisions and use lab data to find the cause.

Low-traffic sites often have no field data at all. In that case Search Console shows nothing, and you work from lab tests and common sense.

Where to check

1. Search Console > Core Web Vitals. Groups URLs by template with similar issues, separately for mobile and desktop. Start here.
2. PageSpeed Insights. Enter one URL to see field data (if available) plus a Lighthouse run with specific suggestions.
3. Chrome DevTools. The Performance panel shows exactly which script or element is responsible.

Fixes that usually work

For LCP

• Compress and resize the hero image. A 2,400-pixel-wide photo on a phone screen is wasted bytes. Serve WebP or AVIF where you can.
• Don't lazy-load the LCP image. Lazy-load images further down the page instead.
• Add fetchpriority="high" to the hero image so the browser fetches it early.
• Improve server response time with caching or a CDN. If your shared hosting takes over a second just to send the HTML, no front-end tweak will rescue LCP.
• Replace sliders with a single static image. Sliders rarely help conversions anyway.

For INP

• Audit third-party scripts. List every tag in your tag manager and remove what nobody uses.
• Defer non-essential JavaScript so it doesn't compete with user interactions.
• Break up long tasks in your own code. If a "filter products" click triggers a heavy re-render, that is your INP problem.
• Be wary of page builders that ship large scripts on every page.

For CLS

• Set width and height attributes (or CSS aspect-ratio) on images and video so the browser reserves space.
• Reserve fixed space for ad slots and embeds.
• Load web fonts with font-display: swap and similar-sized fallbacks to reduce text reflow.
• Don't insert banners such as cookie notices or offers above existing content after load; overlay them instead.

How much should you care?

It depends on the site. For an ecommerce store on mobile-heavy Indian traffic, often on mid-range Android phones over patchy 4G, Core Web Vitals work is directly tied to revenue. For a B2B consultancy whose visitors arrive on office desktops, passing the thresholds is usually enough and further gains have little SEO effect.

My rule: get every template into the "good" range, then stop optimising for the metric and go back to content and links. Chasing the last few points is rarely the best use of a small team's time.

The page speed optimization guide goes further into server and asset fixes, and mobile-first indexing explains why the mobile numbers are the ones to watch. Both sit within the wider technical SEO checklist.

Open Search Console's Core Web Vitals report, pick the mobile URL group with the most "poor" pages, and run one example through PageSpeed Insights. Fix the top suggestion on that template and the whole group usually improves together.