Test your Core Web Vitals, and what sits behind them.

What does a Core Web Vitals test measure?

Your Core Web Vitals test gives your page three numbers: LCP for loading, INP for responsiveness and CLS for visual stability. Open your Search Console report and you will see those labels, each marked good, needs improvement or poor. Your LCP marks the point when your page's main content has likely loaded. And your INP measures every qualifying interaction during the life of your page, then reports the worst one your visitors hit. CLS tracks unexpected layout shift of visible content. Think of a button moving as you tap it.

Two facts shape how you read your numbers. Your metrics come from real users of your site, so they differ from one visitor to the next, and they are not what Google or its crawler thinks of your page. The assessment does not measure them on your pages. It reads what your pages ship. That is the evidence behind your numbers, and it is the part you can act on directly.

What are the passing thresholds for LCP, INP and CLS?

You pass when your page's 75th percentile gives you an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less. Check your report against the poor lines. An LCP above 4000 ms is poor, and so is an INP above 500 ms or a CLS above 0.25. Anything between good and poor counts as needs improvement. In plain terms: your page is not there yet.

The 75th percentile is the part you may miss. Three in four of your page loads, across mobile and desktop, must hit the target, so a fast average does not save you. When PageSpeed Insights has enough data for all three of your metrics, you pass only if all three 75th percentiles are good. Your report shows which one you missed. If your INP data is thin, it judges your LCP and CLS alone. But lack LCP or CLS data and it cannot assess your page at all. INP replaced FID as a Core Web Vitals metric on March 12, 2024, so you may still see FID in older reports.

Why does a lab test differ from your field data?

Your lab test and your field data differ because you are comparing one controlled load with many real ones. Your lab run uses predefined device and network settings; your field data records real page loads from your visitors. Run your URL in PageSpeed Insights and compare the two blocks you see. Your lab result comes from Lighthouse. Your field result comes from the Chrome User Experience Report, called CrUX. You can reproduce and debug lab results easily, but you may miss real-world bottlenecks. Field data shows what your users experienced. The trade is fewer metrics there, and less debugging detail.

Your field data is a distribution, not one number. Run Lighthouse and you get the same LCP element every time, while your real visitors usually produce a variety of them. Your CLS drifts apart too, because your page may have interactive content your Lighthouse test never touches. So where the two disagree, be wary of your lab advice on post-load CLS and on INP.

What can a public scan tell you about your vitals without field data?

A public scan shows you what your pages ship that makes good scores harder or easier to reach. It cannot give you your 75th percentile LCP, INP or CLS. In the performance pillar of your assessment, you see your script weight, image loading and render pattern, read from your homepage and up to eight sampled pages. Your response headers and markup come with it (the boring parts that often explain the most). In short, you see how your pages actually reach your visitors.

You get a reasonable proxy for cause, not a measurement of effect. If your script bundle is heavy, suspect INP risk. A late-loading image points to LCP risk. Neither proves that your real visitors fail. The reverse also holds: a clean read does not prove your field report is green. A slow start also caps your LCP. Your page cannot land under 2.5 seconds if it has not finished downloading for a few seconds. So for your verdict, read your Search Console field data next to the assessment.

Which page patterns usually fail INP?

You usually fail INP when your pages run heavy event handlers, load third-party scripts that block your main thread, thrash layout, or carry a large DOM. Tap your slowest filter, form field or menu. Do you see a pause? Heavy event handlers do your pages the most damage, so check your complex form validation, your client-side filtering and your large DOM mutations. Animations add to it when they trigger layout or large paints. And so do heavy third-party scripts attached to clicks or taps.

Your INP reports the worst interaction in the life of your page, so one slow control on your site is enough to hurt it. Check your code for a long task, a common culprit: any task running over 50 milliseconds. Found one? You can break it into smaller chunks with scheduler.yield() or setTimeout, a commonly recommended fix. If your DOM is large, every presentation update on your pages costs more. The assessment shows your script weight and render pattern, so you know where to look first. But only your field data records the interaction itself.

How do you fix the three most common Core Web Vitals failures?

You fix LCP by getting your main content to start loading sooner, INP by breaking up your long tasks and trimming your blocking scripts, and CLS by finding what moves unexpectedly on your page and holding its space. Start in your Search Console report. Find which of the three your 75th percentile fails, and fix that one first. Then reproduce it in your own lab run. Field tools are more accurate about what your users experienced. Lab tools are often better at helping you identify and fix the issue. So use each for what it does well.

For LCP, check what delays your content before it arrives: if your page has not finished downloading for a few seconds, you cannot land under 2.5 seconds. Then look at how your largest element loads. For INP, split any task you find over 50 milliseconds with scheduler.yield() or setTimeout, and remove third-party scripts on your pages tied to clicks. CLS needs a retest of your interactive parts, since you may never trigger the shift in your lab run. Run the assessment on your site after each change and you will see your evidence move.

Questions, answered.

Your next read.

1. 01Website health checkThe general read, all eight pillars.
2. 02Next.js SEO auditRendering mode, metadata, hydration cost.
3. 03Website audit checklistThe eight pillars as a list you can run yourself.