Core Web Vitals Explained: LCP, INP and CLS Thresholds

Core Web Vitals are three measurements of how a page feels to a real visitor: how quickly the main content appears, how quickly the page responds when someone clicks or taps, and how much the layout jumps around while it loads. They are reported in tools many site owners already use, including PageSpeed Insights and the Search Console Core Web Vitals report.

The numbers can be confusing. A tool says "good" while another says "needs improvement". A Lighthouse score is high but Search Console shows a warning. A change goes live and the report does not move for weeks. Most of this comes from a few facts about how the metrics are collected, which this guide explains.

It is written for site owners, marketers and developers who want to understand the three metrics well enough to read a report and decide what to fix first. At the end you will know each metric, its thresholds, where the data comes from, and a repeatable way to work through a failing result. It does not promise any ranking change, and a good score is not a goal on its own. It is a sign that visitors are having a smoother experience.

Before you begin

You need a Google account with access to Search Console for your site, if you have it set up (see our Search Console setup guide). You also need a browser with Developer Tools, ideally Chrome, and the address of a few important pages. The reading and diagnosing steps are safe and change nothing on your site.

Plan for an hour to read the reports. Fixes depend on what you find and can take much longer. Do not change production templates until you have a baseline you can compare against: save a screenshot or note of the current numbers and the date.

The three metrics

Each metric is judged at the 75th percentile of page loads, separately for mobile and desktop. That means at least 75 percent of visits must meet the "good" level for the metric to count as good. A page passes only if it is good on all three.

Largest Contentful Paint (LCP): loading

LCP reports when the largest image, text block or video visible in the viewport is rendered, measured from when the visitor started loading the page. The elements that can count include images, SVG images, video poster images, elements with a background image set through url(), and block-level elements that contain text. Elements with zero opacity or covering the whole viewport are ignored, and so are low-content placeholder images.

Good: 2.5 seconds or less.
Needs improvement: more than 2.5 and up to 4 seconds.
Poor: more than 4 seconds.

If this is your failing metric, go to fixing Largest Contentful Paint.

Interaction to Next Paint (INP): responsiveness

INP looks at how long the page takes to show a visual response after clicks, taps and key presses during the whole visit. Hovering, scrolling and zooming are not measured. Each interaction has three parts: input delay (waiting for the page to be free to start), processing time (running your event handlers) and presentation delay (getting the next frame on screen). The reported value is, roughly, the slowest interaction, with outliers ignored on pages with many interactions.

Good: 200 milliseconds or less.
Needs improvement: more than 200 and up to 500 milliseconds.
Poor: more than 500 milliseconds.

INP replaced First Input Delay (FID) as a Core Web Vital in 2024. If you read older advice that mentions FID, it is out of date. Slow INP is normally a JavaScript problem; see improving INP.

Cumulative Layout Shift (CLS): visual stability

CLS measures unexpected movement of visible content. Each shift gets a score: the share of the viewport affected multiplied by the share of the viewport distance moved. Shifts are grouped into session windows: bursts with less than one second between shifts and at most five seconds in total. CLS is the score of the worst window. Shifts that happen within 500 milliseconds of a tap, click or key press are excluded, because the visitor caused them.

Good: 0.1 or less.
Needs improvement: more than 0.1 and up to 0.25.
Poor: more than 0.25.

CLS has no unit, it is a score. To fix it, read reducing layout shift.

Field data and lab data

This is the part that explains most of the confusion. Field data is collected from real Chrome users visiting your site, aggregated in the Chrome User Experience Report (CrUX). PageSpeed Insights and Search Console both use that field data. Lab data comes from a tool such as Lighthouse that loads the page once, on a simulated device and network.

All three Core Web Vitals are primarily field metrics. Lab tools are useful while you build and debug, but they cannot replace real-user data. Lighthouse cannot measure INP at all, because nobody interacts with the page during an automated test. It reports Total Blocking Time (TBT) as a stand-in that tends to move in the same direction. For the deeper comparison, read field data vs lab data.

What Google says about ranking

Google describes Core Web Vitals as a set of metrics that measure real-world user experience, and says they align with what its core ranking systems aim to reward. Google highly recommends good scores for success in Search, but it does not say that any score assures a position in results. Treat the metrics as one input to a better experience for visitors.

Step-by-step instructions

Step 1: Open the Search Console report

In Search Console, open the Core Web Vitals report. It uses CrUX field data and shows mobile and desktop separately. Similar pages are grouped, and the group's status is its worst metric: if CLS is poor while LCP and INP are good, the group is poor. Only indexed URLs appear, as a sample, and a group needs enough data to be shown. New properties can show "No data" for a few days.

What success looks like: You can name which groups are poor or need improvement on each device, and which metric is responsible.

Step 2: Test a representative URL in PageSpeed Insights

Pick one URL from the worst group and test it in PageSpeed Insights. The top section shows field data if enough exists for that URL, and the lab section shows a Lighthouse run. Compare the two. If the field data is poor and the lab run looks fine, your testing conditions are easier than your visitors' conditions: faster device, faster network, or a cached page.

What success looks like: You have field and lab numbers for the same URL and know whether they disagree.

Step 3: Find the cause in Chrome DevTools

Open the page in Chrome with DevTools and use the Performance panel. Chrome can show LCP, CLS and INP in the lab. For LCP, find the LCP element and the time it appeared. For CLS, look for the layout shift entries and the elements that moved. For INP, record an interaction (click a menu, open a tab) and see which long task or handler delayed the response.

Remember that INP in the lab depends on what you interact with, so test the actions real visitors use most.

What success looks like: You can say which element is the LCP, which element shifts, or which interaction is slow.

Step 4: Fix the biggest cause first

Work on one metric at a time and change one thing at a time. A few common starting points, not an exhaustive list:

LCP: a slow server response, a large unoptimized hero image or late discovery of the main image. See server response time and modern image formats.
INP: long JavaScript tasks and heavy event handlers.
CLS: images and embeds without reserved space, late-loading banners, and web fonts swapping in. See font loading.

What success looks like: The lab numbers for the problem metric improve on a test of the same URL, in the same conditions as your baseline.

Step 5: Wait for field data and validate

Field data is collected over a rolling period. Search Console's validation uses a 28-day window: after you fix an issue and click Start Tracking, Google monitors CrUX data, and if the issue does not appear on any URL in that period it is considered fixed. Starting validation does not trigger a recrawl. Do not expect the report to change the day after a deployment.

What success looks like: The validation status moves to Passed, or the group's status improves in the report over the following weeks.

What Crawvix checks

Crawvix has individual checks for LCP, CLS and INP, a check named "Real-visitor Core Web Vitals pass" that uses field data, and a server response time check. They use the same good limits as above: 2,500 ms for LCP, 200 ms for INP and 0.1 for CLS. The field-data check depends on real-visitor data being available for your site.

Final verification checklist

You know the status of each Core Web Vital for mobile and for desktop.
You can name the metric that makes each failing group fail.
You compared field data and lab data for at least one URL and understand the difference.
You identified the LCP element, the shifting elements or the slow interaction in DevTools.
Each fix was made one at a time, with the before and after numbers saved.
You started validation in Search Console after fixing an issue.
You re-checked the report after the 28-day window.

Common mistakes to avoid

Chasing a perfect Lighthouse score. Lighthouse is a single lab run. The vitals that matter for the report are field results. Use the lab to diagnose, not to declare victory.

Testing only on a fast laptop. Many visitors use slower phones and networks. Check mobile data first.

Reading the report as pass or fail per page. Search Console groups similar pages, and the group status is its worst metric.

Still optimizing for FID. INP replaced it. Update any checklist that mentions FID as a Core Web Vital.

Fixing three things at once. You will not know what worked. Change one thing and retest.

Expecting immediate change in the report. CrUX is a rolling window, so improvements show up gradually.

Treating a good score as a ranking promise. Google presents the metrics as part of page experience, not as a promise of any result.

Frequently asked questions

What are the three Core Web Vitals?

Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability).

What is a good score for each?

LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, each at the 75th percentile of page loads and measured separately for mobile and desktop.

Why is my Lighthouse result different from Search Console?

Lighthouse is one simulated load in a lab, and Search Console reports real visitors over a rolling period. They answer different questions, so they can disagree.

Do the thresholds change?

Stable Core Web Vitals change no more than once a year, according to web.dev, and changes are documented. The most recent big change was INP replacing FID in 2024.

Are Core Web Vitals a ranking factor?

Google says the metrics align with what its core ranking systems aim to reward, and it recommends good scores. It does not state that a score alone decides rankings.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.