Core Web Vitals explained: LCP, INP and CLS, no jargon

Core Web Vitals are three metrics Google uses to evaluate what a page is like to use: how long the main content takes to show up (LCP), how long the page takes to react when you tap it (INP), and how much the layout moves around while loading (CLS). A site “passes” when all three are in the green for most of its real visits. They’re among the signals Google’s ranking systems use, and once you strip the acronyms, they’re mostly common sense.

The three metrics and their thresholds

Metric	What it measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	How long until the largest element in the initial viewport is visible	2.5 s or less	2.5 to 4 s	over 4 s
INP (Interaction to Next Paint)	How long the page takes to visually respond to a click, tap or key press	200 ms or less	200 to 500 ms	over 500 ms
CLS (Cumulative Layout Shift)	How much content shifts unexpectedly	0.1 or less	0.1 to 0.25	over 0.25

One detail changes how you read these numbers: Google doesn’t look at the average, it looks at the 75th percentile. Three out of four visits need to land inside the “good” threshold. And it evaluates mobile and desktop separately.

LCP: when the important part shows up

LCP doesn’t measure the full page load. It marks the moment the largest element on the first screen gets painted, which is almost always the hero image or the headline. It’s the closest thing to the question every visitor silently asks: “is it loaded yet?”

INP: how long it takes to react

INP replaced FID as the official responsiveness metric in March 2024. The difference matters: FID only looked at the first interaction, while INP watches all of them during the visit (clicks, taps, key presses) and reports, roughly, the worst one. A menu that takes half a second to open will sink your INP even if the page loaded instantly.

CLS: how much the page moves

CLS isn’t measured in seconds. It’s a score that combines how much of the screen moved and how far. It’s the button that slides away right as you’re about to tap it because a banner appeared above it.

How to measure them: lab data vs. field data

There are two kinds of measurement, and mixing them up causes most of the confusion.

• Field data comes from real people using Chrome. Google publishes it in the Chrome UX Report (CrUX), calculated over a rolling 28-day window. This is the data that counts for search.
• Lab data is a simulated test on a defined device and connection. That’s what Lighthouse does. It’s great for diagnosing problems and testing a change before shipping it, but it isn’t the final grade.

The tools we use, from least to most effort:

1. PageSpeed Insights. Paste a URL and you get field data at the top (if the page has enough traffic to appear in CrUX) and a lab analysis with recommendations below.
2. Google Search Console. The Core Web Vitals report groups your site’s URLs by status and by issue type. It’s the best overview, and worth checking once a month.
3. Chrome DevTools. The Performance panel shows the metrics live as you browse and lets you throttle to a slow phone. This is where you find the specific cause.
4. The web-vitals library. For higher-traffic sites, it lets you send each visit’s metrics to your own analytics and see which pages and devices are failing.

Two clarifications that save a lot of confusion. First, Lighthouse can’t measure INP, because nobody interacts with the page during an automated test; it uses Total Blocking Time as a stand-in. Second, a Lighthouse score of 100 doesn’t guarantee green Core Web Vitals, and the reverse is also true. If your site is new or low-traffic, it’s normal to have no field data at all; in that case, lab data is the best reference you have.

What breaks them (and how it gets fixed)

What hurts LCP

• A slow server. If the HTML takes a while to arrive, everything else starts late. This is common on sites that build each page by querying a database.
• A heavy or badly prioritized hero image. A 2 MB JPG at the top of the page, or a hero image with loading="lazy", which tells the browser not to hurry.
• Render-blocking CSS and JavaScript. The browser paints nothing until it finishes processing them.
• Content that needs JavaScript to appear. If the headline only renders after a framework finishes running, LCP waits for it.

Typical fixes: pre-built HTML served from a CDN, images in AVIF or WebP at the right size, fetchpriority="high" on the hero image, and preloaded fonts.

What hurts INP

• Too much JavaScript. While the browser is running a long script, it can’t respond to a tap.
• Third-party scripts. Chat widgets, ad pixels, heatmaps and embeds add work to every interaction.
• Pages with a huge DOM. Every visual update costs more when there are thousands of elements.

Typical fixes: ship less JavaScript, defer what isn’t urgent, break up long tasks, and review which third-party scripts still earn their cost.

What hurts CLS

• Images and videos without dimensions. Without width and height, the browser can’t reserve the space, and content jumps when they arrive.
• Banners, notices and embeds injected late. The cookie notice that pushes the whole page down is the classic case.
• Web fonts. When the final typeface replaces the fallback and takes up a different width, text reflows. We cover this in how we choose typography.

Typical fixes: declare dimensions or aspect-ratio, reserve room for anything that loads later, and tune the fallback font’s metrics.

How much they matter for rankings

Less than they’re often sold as, and more than you can afford to ignore. Google is explicit about it: relevant content still wins, and a slow page with the best answer can outrank a fast page with nothing to say. But among similar results, page experience counts. And there’s an effect that has nothing to do with Google: a site that stalls or jumps loses visitors before they read a single line.

Our target

Green on all three, on a mid-range phone, on mobile data. That’s why we pick architectures that solve most of this by default, as we explain in why we build static sites, and why these metrics are part of the checklist we run before every launch.

Next step

Run your homepage through PageSpeed Insights and look at the field data section first. If any of the three metrics is yellow or red, it’s a fixable problem: our performance and technical SEO service audits exactly this and corrects it, with before-and-after measurement. If you’d rather go through it together, get in touch.