Core Web Vitals: What They Measure and How Google Scores Them

Core Web Vitals are three metrics Google uses to describe how a page feels to real visitors: how fast the main content appears (LCP), how quickly the page responds to input (INP), and how much the layout moves while people read (CLS). This page explains what each one measures, where the pass marks sit, how the score is worked out and whose visits it counts. If you already know which metric is failing, go straight to the step-by-step fixes in how to improve Core Web Vitals.

The three metrics and their thresholds

Search Console rates each metric against the same three bands (Search Console Help):

LCP: when the main content shows up

LCP is the render time of the largest image, text block or video visible in the viewport, counted from the moment the user started navigating to the page (web.dev). On most pages that is a hero image or the first big heading. Background images loaded with CSS url() count; CSS gradients do not.

INP: how fast the page answers a click, tap or key press

INP watches every click, tap and key press during the visit and measures the time from the input until the browser paints the next frame. Hovering and scrolling are not counted. The reported value is the slowest interaction, with one outlier ignored for every 50 interactions (web.dev).

INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024 (web.dev). FID only measured the delay before the first interaction started processing, so a page could pass FID and still feel sluggish. If a report, plugin or agency deck still talks about FID, it is out of date.

CLS: how much the layout jumps

CLS adds up unexpected layout shifts in bursts (shifts less than one second apart, up to five seconds per burst) and reports the worst burst. Shifts within 500 ms of a tap, click or key press are excluded, because the user expected something to change (web.dev). Typical causes are images without dimensions, ad slots that load late and web fonts that reflow text.

How the score is calculated: the 75th percentile of real visits

Google does not score a single test run. It takes field data from real Chrome users, collected in the Chrome UX Report (CrUX) over a rolling 28-day window, and looks at the 75th percentile of page loads, separately for mobile and desktop. A page passes when all three metrics are good at the 75th percentile (web.dev).

In practice, a 75th-percentile LCP of 2.8 s means a quarter of visits waited 2.8 s or longer for the main content. That is a fail, even if your own test on office Wi-Fi loads in 1.5 s. It also explains why fixes take weeks to show up: the old, slower visits stay in the 28-day window until they age out.

Whose visits CrUX counts

The 75th percentile is taken over a subset of your visitors. CrUX only records Chrome users who have turned on usage statistics reporting, sync their browsing history and have no sync passphrase set, and only on these platforms (Chrome for Developers):

Three more rules from the same methodology page decide what ends up in the data:

• A page or origin needs a minimum number of visitors before it appears, and Chrome doesn't publish the number. When a whole site falls short, Search Console shows "No data available" for that device type (Search Console Help).
• Query strings and fragments are stripped, so /pricing?utm_medium=email and /pricing#plans count as visits to /pricing.
• In a single-page app, route changes made in JavaScript are attributed to the first page of the visit. The pages a visitor moves to afterwards get no CrUX data of their own.

So look at the browser split in your analytics before you act on a Core Web Vitals status. If most of your visitors are on iPhones, the status describes the smaller group who visit in Chrome on Android or a desktop, and a change that only affects Safari won't show in Search Console. To see the visits CrUX leaves out, collect your own field data with the web-vitals library: it reports LCP and INP in Chrome, Firefox and Safari, while CLS is still Chromium-only. From Chrome 151 it can also report Core Web Vitals for route changes in a single-page app.

Field data and lab data

Field data comes from real visits. Lab data comes from one simulated load on one device and network. They measure different things and often disagree; when you have both, prioritise field data (web.dev).

Where to find each:

A standard Lighthouse run only loads the page. Nobody clicks or types, so there is no INP to measure, and it reports Total Blocking Time (TBT) as a proxy. A page can have a good TBT and still a poor INP (web.dev).

Two supporting metrics help diagnose a slow LCP but are not Core Web Vitals themselves: Time to First Byte (TTFB) points at slow server responses, and First Contentful Paint (FCP) points at render-blocking resources (web.dev). A good TTFB is 0.8 s or less (web.dev).

Reading the Search Console Core Web Vitals report

The report is built from CrUX data and works differently from a page-by-page test (Search Console Help):

• URLs are grouped with pages that give a similar experience, and the status applies to the whole group.
• A group's status is its worst metric for that device type. A group with good LCP and CLS but a poor INP shows as Poor.
• Each value is the 75th percentile over the last 28 days, shown separately for mobile and desktop.
• Only indexed URLs can appear, and a group is listed only when it has enough data for both LCP and CLS. INP data can be missing. When a group has too little data, Search Console falls back to an origin-level group. A new or low-traffic site may see "No data available".
• After a fix, Start tracking opens a 28-day monitoring period. It does not trigger re-indexing or any other action from Google.

Because the status covers the whole group, fixing a cause shared by those pages (an unsized carousel on every product page, say) can move every URL in the group.

How much Core Web Vitals affect rankings

Google states that Core Web Vitals are used by its ranking systems, and that other page experience aspects beyond them don't directly help a site rank higher. There is no single page experience signal to pass. Relevance still comes first: Google shows the most relevant content even when its page experience is below par, and good Core Web Vitals help most when many pages are similarly useful (Google Search Central). Google also says good report results don't guarantee top rankings and that chasing a perfect score just for SEO may not be the best use of your time.

So treat a Poor status as a real problem to fix for your visitors, and don't expect a jump in rankings just from turning a Good page greener.

Next step

When you know which metric fails and on which template, work through how to improve Core Web Vitals, which goes metric by metric with code. If you'd rather hand it over, our speed optimization service starts from your field data. When slow pages are one symptom among others, such as pages missing from the index or canonicals pointing the wrong way, ask for a technical review of crawling, indexing and page speed instead.