Core Web Vitals
CWV / LCP / INP / CLS / page experience
Core Web Vitals are three measurements Google uses for page experience: loading, responsiveness and visual stability. The current set is LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. A page passes only if it hits all three at the 75th percentile of real visits.
Core Web Vitals are three numbers about how a page behaves for the people actually loading it. Google describes them as measuring real world user experience for loading performance, interactivity and visual stability.
The current three, with Google's own targets, are Largest Contentful Paint under 2.5 seconds for loading, Interaction to Next Paint under 200 milliseconds for responsiveness, and Cumulative Layout Shift under 0.1 for visual stability. That last one is the measure of things jumping around as the page settles.
Check the date on anything you read about this, including this page. The set has changed. A fourth metric, First Input Delay, was part of it until recently, and web.dev states the change plainly: that is exactly what happened to FID as INP became a stable Core Web Vital metric in 2024. On the Google page carrying these definitions, dated 2025-12-10, FID is not mentioned at all. Any guide still listing it is describing a set that no longer exists. Google does commit to some stability, saying stable Core Web Vitals metrics will not change more than once per year.
Two details change how you should read a report. First, passing is not about a typical visit. Google says tools should consider a page passing if it meets the targets at the 75th percentile of page loads, segmented across mobile and desktop. So the standard is roughly your worse quarter of visits, not your average one.
Second, and this one catches people out: web.dev says tools like Lighthouse, which load pages in a simulated environment without a user, cannot measure INP, because there is no user input. A green score from a simulated test has not assessed one of the three.
In practice
A developer sends a screenshot of a performance score in the nineties. It is real, and it is also not the same thing as passing Core Web Vitals. One of the three metrics cannot be produced by that kind of test at all, and the standard is set at the 75th percentile of actual visits rather than one run on one machine. The report to ask for is the field data, which is what Search Console shows.
Not the same as
- A performance score
- A single number out of 100 from a lab tool. Core Web Vitals are three specific measurements from real visits.
- A ranking guarantee
- Google puts it carefully, saying good vitals align with what its core ranking systems seek to reward.
Why it matters to you
This is one of the few technical areas where Google publishes exact numbers, which makes it unusually easy to hold a supplier to. The targets are public, the thresholds are specific, and the measurement is from real visitors rather than an opinion. It is also easy to be shown the wrong evidence in good faith.
What is typical
Google's published targets, on its page dated 2025-12-10: LCP within 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, each measured at the 75th percentile of page loads and split between mobile and desktop.
What to ask or check
- 01What are our LCP, INP and CLS at the 75th percentile, on mobile and on desktop separately?
- 02Is this field data from real visits, or a score from a simulated test?
- 03If any guidance we have been given mentions First Input Delay, when was it written?
What people get wrong
That a high score from a page speed tool means the vitals pass. Those tools run in a simulated environment with no user, and web.dev says they cannot measure INP at all, so one of the three is missing from that number.
Red flags
- A performance score offered as proof the vitals pass.
- Any guidance that still lists First Input Delay, which tells you when it was written.
- Mobile and desktop reported as one combined figure.
Where you will see it
In the Core Web Vitals report in Search Console, which uses field data from real visits.
Where we fit
Building and maintaining websites is one of the things we do, so these three numbers are part of the work rather than an add on.
See how we do it