What Is Core Web Vitals?

Reviewed by Ionut Caval · Updated September 2026

Core Web Vitals are the subset of web performance signals Google treats as most important to the user experience, and they feed into search ranking as part of the page experience signal. What makes them distinct is that they are designed to be measured in the field, from the sessions of actual visitors via real user monitoring, rather than only from a single lab test. Lab tools such as Lighthouse can estimate them, but the scores Google uses for ranking come from aggregated field data.

The three metrics and where the thresholds sit

Each one covers a different part of the experience, and each has a fixed cut-off for a "good" rating:

• LCP (Largest Contentful Paint) is the loading one: how long until the biggest element on screen has actually rendered. 2.5 seconds or less is good, 2.5 to 4 seconds needs improvement, and anything past 4 seconds is poor.
• INP (Interaction to Next Paint) covers responsiveness, and it watches the whole visit rather than a single moment: every tap, click and key press, and how long the page takes to paint a response. 200 ms or less is good, 200 to 500 ms needs improvement, past 500 ms is poor. It took over from First Input Delay in March 2024.
• CLS (Cumulative Layout Shift) is visual stability: how far the layout jumps around as content loads in and shoves what you were reading out of place. 0.1 or less is good, 0.1 to 0.25 needs improvement, above 0.25 is poor.

Why Google reads the 75th percentile

None of this is an average. Each metric is read at the 75th percentile of page loads, with mobile and desktop scored separately. That value is the experience 75% of visits are at least as good as, so a page passes only once three quarters of real sessions clear the "good" bar. The choice is deliberate, because an average lets a fast majority bury a slow tail. Say most of your visitors get LCP in 1.8 s while the slowest quarter sits at 3 s or worse. The typical visit looks fine, and the page still fails LCP.

Where the field data comes from

Google does not run a test of its own. It reads the Chrome User Experience Report (CrUX), a field dataset gathered from real, opted-in Chrome users, and that is the source behind the page experience signal. CrUX reports each metric over a trailing 28-day window and refreshes daily, so a fix you ship today only lands in full about four weeks later, once the slow days before it age out of the window.

Passing is rarer than it sounds. As of the 2024 Web Almanac, 43% of mobile websites and 54% of desktop websites cleared all three, so check the device split before assuming a page is fine: the mobile assessment is the one Search uses for mobile results. Your own RUM figures will not match CrUX either, since CrUX covers only opted-in Chrome users on sufficiently popular pages and lags 28 days, while a RUM tool sees every browser in near real time.

The numbers come from real traffic, which is why RUM collects them and scheduled checks cannot. Server speed still counts: a slow TTFB (time to first byte) feeds straight into LCP, so the loading score is partly a hosting and network story. The limit is worth stating plainly. Core Web Vitals describe how a page feels to the people who reached it, and say nothing at all about a page nobody can reach, which is the job of synthetic and API monitoring. Synthetic vs real user monitoring covers how the two layers fit together.

See also: Synthetic vs real user monitoring