Core Web Vitals Explained: Metrics, Thresholds and What to Do

Core Web Vitals are three metrics Google uses to measure the real-world experience of a page: LCP (how soon the main content appears), INP (how quickly the page responds to clicks and taps) and CLS (how stable the layout stays while you read). A page counts as good when, for 75% of visits, LCP is within 2.5 seconds, INP within 200 milliseconds and CLS at or below 0.1.

Which metrics, and what are the thresholds?

These are the metrics described in the Web Vitals documentation on web.dev, where all three are listed as stable. INP replaced the older FID in 2024, so if an older guide still mentions FID, it is no longer part of the set. At the time of writing, the official documentation shows no other metrics or different thresholds.

The reference value is the 75th percentile of visits, split between mobile and desktop. In other words, the threshold has to hold for most of your users, not for the average and not for the best case.

Field data vs. lab data

Field data comes from real visits, collected by the Chrome User Experience Report (CrUX) over a 28-day period. Lab data comes from a simulated page load on a fixed device and network. It is useful for finding and reproducing problems, but it does not match what your visitors experience. The PageSpeed Insights documentation explains the difference, and the tool shows both. INP, in particular, exists only as field data.

Where to measure

• PageSpeed Insights. For a given URL it shows field data, when there is enough of it, plus a lab analysis with suggestions on what to fix.
• Search Console. The Core Web Vitals report uses CrUX data, separates mobile and desktop, and groups pages with a similar experience. On low-traffic sites, data may be missing or may cover the whole site rather than a single page.
• Developer tools. Chrome DevTools and Lighthouse cover the lab side, and the web-vitals JavaScript library collects data from your own visitors.

Do they affect search rankings?

Yes, but don’t overstate it. Google says Core Web Vitals are used by its ranking systems and recommends good scores, but it also states that it always tries to show the most relevant content, even if the page experience is sub-par, and that there is no single signal. A good score does not guarantee rankings, and a useful, relevant page should never be traded away for a few milliseconds. Still, a fast, stable page is simply nicer to use, whatever search does.

What to do in practice

Start with whichever metric looks worst in your field data. A few general fixes, all recommended by web.dev:

• Images. Always set width and height to prevent layout shifts. Use loading="lazy" only for images below the first screen, never for the main one, which benefits from fetchpriority="high", as the LCP optimization guide explains.
• Fonts. Use WOFF2, include only the characters you need, limit the number of variants, and pick a suitable font-display value, using size-adjust to reduce the gap with the fallback font (font best practices).
• JavaScript. Do less work in event handlers and break up long operations: a task over 50 milliseconds counts as long and delays the response to clicks (INP guide). Also review which third-party scripts you really need.
• Reserved space. For banners, embeds and anything that appears late, set aside the space in advance with min-height or aspect-ratio (CLS guide).
• Server response. The time it takes to deliver the page weighs on LCP, so hosting and caching are part of the work too.

Field data is based on a 28-day window, so it is reasonable to expect a change to show up only after a few weeks (this is our inference from that window, not a timeframe stated by Google). Check in the lab first and then follow the real trend. We don’t promise scores, because they depend on the site, its content and its visitors.

Performance is part of how we design and measure websites: see Web & Digital Strategy, and for visibility work, including on sites built by others, SEO, GEO and AEO.