Core Web Vitals: the three thresholds Google measures on your site

Core Web Vitals are three measures of your visitors' real experience: loading (LCP, 2.5 seconds at most), responsiveness (INP, 200 milliseconds at most) and visual stability (CLS, 0.1 at most). Google recommends meeting them to succeed in Search, but they don't replace useful content: above all, they stop good content from being held back by a poor experience.

The three metrics and their thresholds

Google's reference page defines them as follows (web.dev, Web Vitals):

Above 500 ms, INP is rated "poor" (web.dev, INP); above 0.25, so is CLS (web.dev, CLS). In between, Google calls the values "needs improvement".

The detail that changes everything: the 75th percentile

These thresholds don't apply to your own visit from your office computer. Google recommends measuring them at the 75th percentile of page loads, segmented across mobile and desktop, and considers a page passing if it meets all three targets at that percentile (web.dev, Web Vitals).

In practice: three visits out of four must be "good", including those from an entry-level phone on an average mobile connection. That's why a site that "loads fast for me" can fail: you test on your audience's best setup, Google looks at the typical one.

INP replaced FID

If you read a guide from 2022, it talks about FID (First Input Delay). INP is its successor: FID only measured the delay of the first interaction, while INP observes all interactions during the visit and keeps the longest one, ignoring outliers (web.dev, INP). A menu that responds well on the first click but freezes on the tenth passed FID; it fails INP.

What Google really says about ranking

The Search Central documentation is precisely worded: "We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally. This, along with other page experience aspects, aligns with what our core ranking systems seek to reward." (Google Search Central, Understanding Core Web Vitals).

Here's how I read it: Core Web Vitals are part of what the ranking systems reward, among other page experience aspects. They're not a lever that lifts a pointless page above a useful one. But they are a very real drag when two pages are otherwise equal — and a direct drag on conversion, since what's being measured is your own visitors' experience.

Where to measure them

The same page points to the Core Web Vitals report in Search Console, which shows how your pages perform (Google Search Central). It's the first place to open: it's field data from real visitors, grouped by page type.

Lab tools such as Lighthouse simulate a page load. They're perfect for reproducing and fixing a problem, but a lab score of 100/100 doesn't guarantee a green report in Search Console: the two don't measure the same thing.

What I fix most often

On the sites I audit, the same causes keep coming back:

• LCP: a header image that's too heavy or loaded late, or a font that blocks the heading from rendering.
• INP: too much JavaScript running at click time — ad scripts, widgets, heavy animations.
• CLS: images and embeds with no reserved dimensions, a cookie banner or promo bar that pushes content down after it has rendered.

None of these fixes is spectacular. Together, they often make the difference between a page that "needs improvement" and a "good" one at the 75th percentile.