Core Web Vitals Explained: LCP, INP and CLS Thresholds and Fixes

Core Web Vitals are three metrics Google uses to measure how fast a page loads for real users, how quickly it responds and how stable it stays while loading: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift). To count as good, at least 75% of page visits should have an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less. Google says these metrics align with the page experience its core ranking systems seek to reward, but they should not be seen as a factor that decides rankings on their own.

What are the Core Web Vitals thresholds?

The Core Web Vitals report in Search Console sorts each metric into three groups:

• LCP: Good at 2.5 seconds or less; needs improvement up to 4 seconds; poor above 4 seconds.
• INP: Good at 200 milliseconds or less; needs improvement up to 500 milliseconds; poor above 500 milliseconds.
• CLS: Good at 0.1 or less; needs improvement up to 0.25; poor above 0.25.

Two details matter for reading the results correctly. First, the assessment is based on the 75th percentile of visits, not the average, and mobile and desktop are measured separately. So if a quarter of your visitors have a bad experience, the result can still look poor. The report always looks at the last 28 days of data. Second, Search Console sets the status of a URL group by its worst metric: if CLS is poor on mobile and LCP needs improvement, the group's status is poor.

Where did FID go, and why INP?

You may still see FID (First Input Delay) in older articles. On 12 March 2024, Google made INP an official Core Web Vitals metric and retired FID from the program. FID only measured the delay of the first interaction on the page; INP tracks every click, tap and key press during the visit and, after filtering out outliers, reports one of the slowest interactions. Scrolling, hovering and zooming are not included in INP.

In practice this change means that sites which look fast on first load but stall on actions such as adding to cart, filtering or opening a menu now get poor results.

How do you improve LCP?

LCP is the time it takes for the largest content element on the screen (usually the hero image or a large heading block) to become visible. web.dev's LCP guide breaks this time into four parts: the time to first byte from the server (TTFB), the delay before the LCP resource starts loading, the time to download the resource, and the time from download until it is painted on screen. To fix the problem, first find out which part is long.

Common mistakes we see, and their fixes:

• Lazy loading is applied to the hero image. Do not use loading="lazy" on the image at the top of the page; the browser discovers it late.
• The image is added by JavaScript rather than in the HTML. The LCP image should be present in the initial HTML. You can use fetchpriority="high" to raise its priority.
• The image is larger than necessary. WebP or AVIF formats, the right dimensions and compression directly shorten download time.
• The server is slow. Removing unnecessary redirects and using caching and a CDN reduce TTFB.
• CSS and JavaScript block rendering. Deferring non-critical scripts and cutting unnecessary stylesheets shorten the final part.

How do you improve INP?

INP has three phases: the wait from the interaction until the event handler starts running, the time the handler runs, and the time until the browser paints the next frame. The common enemy of all three is JavaScript that keeps the main thread busy for a long time.

• Break up long tasks. Splitting a heavy function that runs in one go into smaller pieces gives the browser a chance to respond to user interactions in between.
• Review third-party scripts. Chat widgets, heatmaps, multiple tags and ad scripts are the most frequent causes of poor INP. Remove what you do not use and defer what you need until after the interaction.
• Do less work on interaction. Instead of redrawing the whole page on a filter click, update only the part that changes; show the visual response (that the button was pressed) first and run heavy calculations afterward.
• Avoid a large DOM. Product lists with thousands of elements and deeply nested menus lengthen rendering time on every interaction.

How do you improve CLS?

CLS measures unexpected shifts in content while the page loads. The typical example: just as you are about to tap a button, a banner appears at the top and you tap the wrong spot.

• Give images and videos width and height values or define an aspect ratio, so the browser reserves their space in advance.
• Reserve fixed space for ads, cookie banners and embedded content.
• Add new content when the user takes an action or below the visible area, not on top of existing content.
• When loading web fonts, reduce the size difference between the fallback font and the real font; this prevents text from jumping.

Which tools should you use to measure Core Web Vitals?

The most common mistake here is confusing lab measurements with real user data.

• Search Console Core Web Vitals report: Based on anonymous data collected from real Chrome users (CrUX), and shows the site as groups of URLs. This is the main reference for prioritizing. Pages without enough traffic may not appear in the report.
• PageSpeed Insights: Shows both real user data (if available) and a lab test for the same page. Ideal for diagnosing a single page.
• Lighthouse and Chrome DevTools: Provide repeatable tests in a controlled environment, used during development to find the source of a problem. A standard page load test includes no user interaction, so it does not show INP directly; you need to perform interactions manually and observe them in DevTools.
• The web-vitals library: Lets you collect metrics from your own site's visitors and send them to your analytics.

After making a fix, you start a 28-day monitoring period with the "Start tracking" button on the issue's details page in Search Console; if the issue is not seen on any URL during that period, it is considered fixed. Because real user data updates as it accumulates, improvements do not show up in the report right away.

Where should you start?

1. Open the mobile report in Search Console and note the URL groups with a poor status.
2. Test a sample page from each group in PageSpeed Insights; find which metric, and which part of it, is the problem.
3. Fix template-level issues first: one fix to the product page template improves hundreds of pages at once.
4. Make an inventory of third-party scripts and remove the unnecessary ones.
5. Start tracking and check the result after 28 days.

Many Core Web Vitals problems start with design decisions and infrastructure, so speed is far cheaper to achieve when it is set as a goal at the web design stage than when it is patched later. For improvements on the server, caching and CDN side, see our server and infrastructure service, and if you would like to assess your site together, get in touch.