Core Web Vitals, explained

The three Core Web Vitals are Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when 75% of real visits hit the good threshold on all three. Google has confirmed these metrics are used by its ranking systems.

That is the short version. The rest of this guide is the part that actually helps.

The three metrics at a glance

All three are measured at the 75th percentile of visits, and mobile and desktop are scored separately. The 75th percentile matters: it means three out of four of your visitors get an experience at least this good. Chasing the average hides your slowest quarter, which is usually the quarter that leaves.

Thresholds come straight from Google's web.dev reference. They don't move often, so once you're comfortably under them you can mostly stop worrying and just watch for regressions.

Largest Contentful Paint (LCP)

LCP is the moment the biggest thing in the viewport finishes rendering, usually a hero image, a banner, or a big block of heading text. It's a good proxy for "the page looks ready" because the largest element is the one a visitor's eye lands on.

When LCP is slow, the cause is almost always one of four things: a slow server response (TTFB), render-blocking CSS or JavaScript holding up the paint, a hero image that's too heavy or discovered too late, or content that only appears after JavaScript runs. The good news is that LCP is the most fixable of the three. Google's Optimize LCP guide is the reference I keep going back to.

Interaction to Next Paint (INP)

INP measures responsiveness. Every time someone taps, clicks, or presses a key, the browser needs to react and paint the result. INP looks at those interactions across the whole visit and reports roughly the worst one. Aim for 200 ms or less.

INP replaced First Input Delay on 12 March 2024. The difference is honest in a way FID wasn't: FID only timed the delay before the first interaction, which most pages passed easily. INP times the full delay through to the next frame, for every interaction. If your page ships a lot of JavaScript, INP is where that shows up, because long tasks block the main thread and the page can't respond until they finish. The fixes live in Optimize INP.

One catch worth knowing: lab tools can't measure INP properly, because there's no real person clicking. Lighthouse reports Total Blocking Time instead as a stand-in. That's a big reason field data matters, and we'll come back to it.

Cumulative Layout Shift (CLS)

CLS is the one everyone feels but few measure. It's the sum of unexpected layout shifts: you go to tap a button, an image loads above it, the whole page jumps, and you tap an ad instead. Good is 0.1 or less.

The usual culprits are images and embeds without width and height set, content injected at the top of the page (cookie banners, ads, late-loading widgets), and web fonts that reflow text when they swap in. Most of it is preventable by reserving space before the content arrives. Google's Optimize CLS covers the patterns.

Lab data vs field data: why two tools disagree

This trips up almost everyone, so it's worth being clear. There are two ways to get Core Web Vitals, and they answer different questions.

Lab data comes from a synthetic test. A tool like Lighthouse loads your page once, on a simulated device and network, in a clean room. It's repeatable and it's great for debugging, because you can change one thing and re-run. But it's one device, one network, one moment. It can't see your real users, and it can't measure INP.

Field data comes from real Chrome users through the Chrome UX Report (CrUX). It's the 75th percentile of actual visits over a rolling 28-day window, across whatever phones, laptops, and connections your audience actually uses. This is the data Google's assessment is based on. The catch: a page needs enough traffic to show up in CrUX at all, so newer or low-traffic pages often have no field data.

So a page can score 98 in a lab test and still fail in the field, because your real visitors are on three-year-old phones and patchy 4G, not a data-centre connection. Neither number is wrong. They're answers to different questions: "is this page capable of being fast?" versus "is it fast for the people actually using it?" You want both.

Do Core Web Vitals affect SEO?

Yes, but keep it in proportion. Google's own wording is careful: "Core Web Vitals are used by our ranking systems," and at the same time, "Google Search always seeks to show the most relevant content, even if the page experience is sub-par" (source).

Read that twice. Speed won't rescue thin content, and it won't outrank a clearly better answer. But when two pages are close on relevance, the faster, more stable one has an edge, and a genuinely slow page leaks visitors before they read a word. Treat Core Web Vitals as part of helpful, people-first content, not a ranking cheat code.

How to measure them

A few free, official ways to check a page:

• PageSpeed Insights runs Lighthouse and shows CrUX field data in one view. The best starting point.
• Search Console's Core Web Vitals report groups your URLs by status using field data, so you see problems at site scale.
• Lighthouse in Chrome DevTools, for hands-on debugging.
• The web-vitals JavaScript library if you want to log real-user metrics yourself.

Each of these is a snapshot. That's the limitation. A page experience report tells you where you stand today; it won't tell you that a deploy last Tuesday quietly pushed LCP from 2.3 to 3.1 seconds on mobile. Performance drifts between releases, and a single check can't catch drift. That's the job a monitor does.