Core Web Vitals thresholds: what a good LCP, INP and CLS score is, and how to fix each

What Core Web Vitals are

Core Web Vitals are three metrics Google uses to measure real-world user experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. They are defined by the Chrome team on web.dev, measured from real Chrome users through the Chrome UX Report, and shown in Search Console.

Each one answers a simple question a visitor would ask: did the main content show up quickly, did the page react when I tapped, and did things jump around while I was reading?

Core Web Vitals thresholds: good, needs improvement, poor

A good score is LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. These are the official thresholds published by Google.

The 75th-percentile rule

A page meets a threshold when at least 75% of its real page loads are at or better than it, measured separately on mobile and desktop. Google's Web Vitals article calls the 75th percentile of page loads, segmented across mobile and desktop devices, a good threshold to measure.

In practice that means one in four visits can be slow and the page still passes, but a fast median is not enough. If your LCP is 1.8 seconds for most people but 3.1 seconds for the slowest quarter on older phones, your 75th-percentile LCP is in “needs improvement”. It is also why mobile and desktop often get different results for the same page: phones are slower and mobile networks less reliable.

To pass the Core Web Vitals assessment, all three metrics must be good. Search Console gives a group of URLs the status of its worst metric, so one poor CLS score makes the whole group poor.

LCP: Largest Contentful Paint

LCP is the time from when the page starts loading until the largest image, text block or video in the viewport is rendered. Good is 2.5 seconds or less. Because it is measured from navigation start, it includes redirects and server response time, not just how fast the image downloads.

The LCP element can be an <img>, an <image> inside an SVG, a video's poster image or first frame, an element with a CSS url() background image, or a block of text. On most pages it is the hero image or the main heading.

What is INP (Interaction to Next Paint)?

INP measures how quickly a page visibly responds when someone clicks, taps or presses a key, across the whole visit. Good is 200 milliseconds or less; poor is over 500 milliseconds. It became a stable Core Web Vital on 12 March 2024, replacing First Input Delay (FID).

FID only measured the delay before the first interaction started being handled. INP observes every click, tap and key press, measures the full time until the next frame is painted, and reports one of the slowest: usually the worst, though on pages with many interactions it ignores the single highest for every 50 interactions so one fluke does not decide the score. Scrolling and hovering do not count.

A slow INP feels like a button that does nothing for half a second, a menu that opens late, or typing that lags. The usual culprit is JavaScript keeping the browser's main thread busy.

CLS: Cumulative Layout Shift

CLS scores how much visible content moves unexpectedly while the page is open. Good is 0.1 or less; poor is over 0.25. It takes the largest burst of layout shifts, where a burst is a group of shifts less than 1 second apart, lasting at most 5 seconds. Shifts within 500 milliseconds of a user's input are expected and excluded.

The common causes, per web.dev: images or videos without dimensions, web fonts that render larger or smaller than their fallback, ads and widgets that resize themselves, and content inserted above what the reader is already looking at.

Field data (CrUX) vs lab data (Lighthouse)

Field data is what real Chrome users experienced over the last 28 days; lab data is one simulated page load. Google's thresholds and Search Console use field data.

The two often disagree, and PageSpeed Insights says so: its documentation explains that lab data comes from a simulated load with fixed network conditions, so values may differ from real users. A Lighthouse performance score of 95 does not mean you pass Core Web Vitals, and a score of 60 does not mean you fail. Lighthouse cannot measure INP because nobody interacts with the page during the test; web.dev describes Total Blocking Time as a reasonable lab proxy for INP, but not a substitute.

Where to see your Core Web Vitals

Use Search Console for the site-wide picture, PageSpeed Insights for a single URL, and the CrUX API or dashboards for history.

• Search Console → Core Web Vitals. The report uses CrUX field data, splits Mobile and Desktop, and groups similar URLs together. Each group's status is its worst metric. After fixing an issue you can start validation, which tracks the group for 28 days.
• PageSpeed Insights. Shows CrUX field data for the URL and its origin at the top, when Google has it, and a Lighthouse lab run underneath.
• Chrome UX Report. The CrUX History API returns weekly data points, each covering the previous 28 days: 25 by default, up to 40, updated each Monday. Useful for seeing whether a release made things better or worse.
• Chrome DevTools. The Performance panel shows your own LCP, INP and CLS live as you use the page, which is the fastest way to find the slow interaction.

How much Core Web Vitals matter for rankings

They count, but modestly: Google says Core Web Vitals are used by its ranking systems, and also that relevance comes first. Google's page experience documentation makes four points worth reading exactly as written:

• “Core Web Vitals are used by our ranking systems.”
• There is no single page experience signal; Google's core ranking systems look at a variety of signals.
• Google always seeks to show the most relevant content, even if its page experience is sub-par. Great page experience can contribute to success when many helpful pages are competing for the same query.
• Beyond Core Web Vitals, other page experience aspects do not directly help a site rank higher.

So a slow page with the best answer can still win, and making a weak page fast will not rescue it. Fix Core Web Vitals because slow, jumpy pages lose visitors and sales, and treat any ranking gain as a bonus. If your traffic fell sharply, page speed is rarely the cause; our traffic drop checklist covers the likelier ones.

Top fixes for each metric

Most gains come from a short list of fixes that Google's own guide to the most effective improvements recommends.

1. Improve LCP

   Make the LCP image discoverable in the HTML (a real <img> with src, not one injected by JavaScript or a lazy-loading script), give it fetchpriority="high", and never lazy-load it. Serve it in a modern format at the size it is shown. Cut server response time with caching and a CDN, and avoid redirects before the page.

2. Improve INP

   Break up long JavaScript tasks and yield to the main thread often, so the browser can respond between chunks of work. Remove JavaScript you do not need: unused code, old tag manager tags, heavy third-party widgets. Keep the work done after a click small, and avoid large rendering updates such as re-drawing a whole page to change one number.

3. Improve CLS

   Set width and height (or aspect-ratio) on every image, video, iframe and ad slot, and reserve space for banners before they load. Do not insert content above what is already on screen. Animate with transform rather than properties that change layout, and make pages eligible for the back/forward cache so returning visitors get an instant, stable page.

Change one thing at a time and confirm it in the field. Because CrUX covers 28 days, a fix takes up to four weeks to show fully in Search Console and PageSpeed Insights.

How MrKeyword tracks Core Web Vitals

MrKeyword's Core Web Vitals tracking pulls your site's weekly LCP, INP and CLS history from the Chrome UX Report History API, separately for mobile and desktop. Each weekly point is Google's 75th-percentile value for real Chrome visitors to your whole origin over the previous 28 days, rated good, needs improvement or poor against the thresholds above, with the change since eight weeks earlier. It refreshes once a week, after Google publishes the new point.

What it does not do: it shows origin-level data, not individual URLs; it does not run lab tests or estimate values; and if Google does not have enough Chrome visitors for your site, it says so rather than showing a number.

Questions and answers