Core Web Vitals

Core Web Vitals are three metrics for real-world page experience: Largest Contentful Paint (LCP) measures loading performance, Interaction to Next Paint (INP) measures responsiveness, and Cumulative Layout Shift (CLS) measures visual stability. Google’s current thresholds and Search context are documented in Understanding Core Web Vitals and Google search results.

Google recommends evaluating the 75th percentile of visits, separately for mobile and desktop where possible:

Metric	Good	Needs improvement	Poor
LCP	≤ 2.5 s	> 2.5 s and ≤ 4 s	> 4 s
INP	≤ 200 ms	> 200 ms and ≤ 500 ms	> 500 ms
CLS	≤ 0.1	> 0.1 and ≤ 0.25	> 0.25

These are user-experience thresholds, not a promise about rankings or conversions.

Field data and lab data answer different questions

Field data comes from real visits, commonly through the Chrome User Experience Report (CrUX). It captures device, network, cache, and interaction diversity over time. Search Console groups URLs using field data, so a report can reflect a group rather than one exact URL.

Lab data comes from a controlled test such as Lighthouse. It is repeatable and useful for debugging, but a lab run cannot fully represent the distribution of real users. Lighthouse can investigate LCP and CLS; Total Blocking Time is a diagnostic proxy for responsiveness, not the same metric as field INP.

Use field data to establish whether users have a problem. Use lab traces and your own real-user monitoring to locate the cause.

Diagnose each metric at page level

LCP

Identify the actual LCP element before changing infrastructure. Break the time into server response, resource discovery delay, resource load duration, and render delay. Typical fixes include caching HTML, removing redirect delays, prioritizing the hero resource, avoiding lazy-loading the LCP image, and reducing render-blocking work.

INP

Find the slow interaction and separate input delay, event-processing time, and presentation delay. Reduce long main-thread tasks, unnecessary third-party code, expensive event handlers, and large rendering updates. Test real interactions rather than optimizing only initial load.

CLS

Use layout-shift records to find the moving element and the cause. Reserve image, video, ad, and embed space; avoid inserting late content above existing content; and manage font loading. User-initiated shifts within the permitted interaction window are treated differently from unexpected shifts.

SEO interpretation

Google states that its ranking systems use Core Web Vitals and seek to reward good page experience. It also states that good results in CWV reports do not guarantee high rankings and that relevance remains more important. See Google’s page experience guidance.

Do not extend that statement into undocumented claims. There is no public basis for saying GPTBot or ClaudeBot rejects a page because of its CWV score, or that AI answer systems read your bounce rate and downweight a source. Server response, crawl access, rendered content, and user experience are separate audit questions.

Verification checklist

1. Record the affected URL group, device class, metric, and 28-day field window.
2. Confirm the problem with URL-level field data where available.
3. Reproduce it with a lab trace or real-user monitoring.
4. Fix the measured bottleneck, not a generic checklist item.
5. Re-test for functional and visual regressions.
6. Deploy, annotate the release, and wait for enough field data before judging the result.

Related: Page Speed, Technical SEO, and Engagement Rate.