Core Web Vitals

What are Core Web Vitals?

Core Web Vitals are three metrics Google uses to measure the experience real people have on a page: 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 all three are “good” for at least 75% of visits.

The thresholds are the same for every site. Largest Contentful Paint is good at 2.5 seconds or less and poor above 4 seconds. Interaction to Next Paint is good at 200 milliseconds or less and poor above 500 milliseconds. Cumulative Layout Shift is good at 0.1 or less and poor above 0.25. Anything between good and poor is “needs improvement”.

Google assesses each metric at the 75th percentile of page loads, measured separately for mobile and desktop. Using the 75th percentile means most visitors, not just the ones on fast devices and connections, need a good experience before a page passes. A page with a median LCP of 1.8 seconds can still fail if a quarter of visits take longer than 2.5 seconds.

The set has changed once. When Google introduced Core Web Vitals in 2020, responsiveness was measured by First Input Delay (FID), which only timed the delay before the first interaction was handled. In March 2024 INP replaced FID. INP looks at the latency of interactions across the whole visit, including the time to update the screen, so it is a stricter and more complete measure.

Core Web Vitals come from field data: real Chrome users who have opted in to share usage statistics, collected in the Chrome User Experience Report (CrUX) over a rolling 28-day window. When a URL does not have enough traffic for its own data, Google may group it with similar pages or fall back to the whole origin. Lab tools such as Lighthouse cannot measure the field values directly. Lighthouse reports LCP and CLS from a simulated load and uses Total Blocking Time as a lab stand-in for INP, because there is no real user interacting during a test.

Core Web Vitals are part of Google’s page experience signals, alongside things like HTTPS and the absence of intrusive interstitials. They became part of ranking with the page experience update in 2021.

Why Core Web Vitals matter for SEO

Google’s ranking systems use Core Web Vitals, so they are one of the few user-experience measures with a direct, documented link to search. Google is careful about their weight: it says good scores do not guarantee top rankings and that relevance and helpful content matter more. In practice they work as a tiebreaker between pages that are otherwise similar, and as a guard against an experience bad enough to lose visitors.

The bigger payoff is usually outside rankings. Faster loading, quick responses and a page that does not jump about all keep visitors on the page and make it easier for them to buy, sign up or read. Because CWV come from real visitors, they also show you problems that only appear on slow phones and networks, which a developer testing on a fast laptop would never see.

They also give teams a shared, measurable target. “Make the site faster” is vague; “get mobile LCP at the 75th percentile under 2.5 seconds on product pages” is a goal a developer can work on and a report can track.

How to check Core Web Vitals

1. Open the Core Web Vitals report in Google Search Console. It groups your URLs into good, needs improvement and poor for mobile and desktop, based on CrUX field data, and names the failing metric for each group.
2. Pick an example URL from a failing group and test it in PageSpeed Insights. The top section shows field data for the URL and the origin; the lower section is a Lighthouse lab run with specific suggestions.
3. Work on the failing metric. For LCP, find the LCP element, cut server response time, preload or prioritise the main image and remove render-blocking CSS and JavaScript. For INP, break up long JavaScript tasks, cut third-party scripts and keep event handlers light. For CLS, set width and height on images and video, reserve space for ads and embeds and avoid inserting content above what people are reading.
4. Reproduce problems in Chrome DevTools. The Performance panel shows live LCP, INP and CLS as you use the page, and lets you throttle the CPU and network to imitate a mid-range phone.
5. For your own field data, add real-user monitoring with Google’s open-source web-vitals JavaScript library, which reports the same metrics from your visitors’ browsers.
6. Ship the fix and wait. CrUX uses a 28-day rolling window, so Search Console’s report takes up to four weeks to reflect a change. Use the “Validate fix” button to start Google’s check.
7. Watch for regressions. A new script, a redesigned hero or an ad change can undo the work, so check the report after every major release.

Core Web Vitals example

LCP: good ≤2.5 s, needs improvement 2.5–4 s, poor >4 s. INP: good ≤200 ms, needs improvement 200–500 ms, poor >500 ms. CLS: good ≤0.1, needs improvement 0.1–0.25, poor >0.25. A product page with field values of LCP 2.1 s, INP 240 ms and CLS 0.04 fails overall, because INP is above 200 ms.