Core Web Vitals: How to Read LCP, INP and CLS

Core Web Vitals are not a single speed score. They are user-experience metrics that describe loading, responsiveness and visual stability. Reading them correctly means knowing the current thresholds, the difference between field and lab data, and what a failing value can—and cannot—tell you.

The three current Core Web Vitals

Google’s web.dev documentation lists three current Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). The official Web Vitals guide is the best place to confirm current definitions and thresholds.

LCP: loading experience

LCP measures when the largest relevant content element in the viewport finishes rendering. A good LCP is 2.5 seconds or less; values above 4 seconds are considered poor.

Slow LCP can have many causes: server response, render-blocking resources, image delivery, client-side rendering or the way the main content is prioritized. The metric identifies the symptom; diagnosis still requires inspecting the page.

INP: responsiveness

INP evaluates interaction responsiveness across a page visit. A good INP is 200 milliseconds or less; above 500 milliseconds is poor.

A high INP can point to long main-thread tasks, heavy JavaScript, expensive rendering or other work that delays visual feedback. Do not assume one library is the cause without profiling.

CLS: visual stability

CLS measures unexpected layout shifts. A good CLS is 0.1 or less; above 0.25 is poor.

Common contributors include images without reserved dimensions, late-loading banners, injected content and font changes that move existing elements. The specific cause depends on the page.

Why the 75th percentile matters

Core Web Vitals are assessed using the 75th percentile of page loads, segmented by mobile and desktop where appropriate. That means one fast test on your laptop does not prove that real users have a good experience.

Field data captures real visits and real device/network conditions. Lab tools are still valuable because they make debugging repeatable, but the two data sources answer different questions.

Field data versus lab data

• Field data: aggregated measurements from real eligible users over time. Useful for understanding experienced performance.
• Lab data: a controlled test under specified conditions. Useful for diagnosing and reproducing technical problems.

If a lab test looks fast while field data is poor, investigate device mix, network conditions, page variants, third-party scripts and user flows rather than dismissing one source.

Use thresholds as triage, not as a diagnosis

EseoGen’s Core Web Vitals Input Assessment lets you enter LCP, INP and CLS values and classifies them against stored thresholds. It runs locally in the browser and does not fetch PageSpeed Insights or Chrome UX Report data.

That makes it useful for quickly interpreting measurements you already have. It does not identify the root cause or prove that a live URL currently passes.

Turn each metric into an investigation

1. Confirm whether the value is field or lab data.
2. Check the date range, device category and affected URL group.
3. Identify which Core Web Vital is outside the good range.
4. Reproduce the problem with appropriate development tools.
5. Fix the underlying bottleneck rather than optimizing only for a displayed score.
6. Measure again after deployment and wait for field data to reflect real visits.

Do not confuse Core Web Vitals with total site quality

Passing Core Web Vitals does not prove that a page is useful, accessible, accurate or easy to navigate. Failing one metric does not explain every ranking or conversion problem either.

Treat LCP, INP and CLS as focused experience signals. Their value is greatest when they help a team identify a real user-facing problem, test a fix and verify the result with the appropriate data source.