Resources · 39
Diagnose Core Web Vitals in field data
Connect LCP, INP and CLS to actual elements and interactions before fixing.
· 7 min
What this guide helps achieve
- Choose comparable segments
- Locate element or action
- Reproduce
- Verify change
Quick check
- Is the signal from the field or lab?
- Which devices and pages make up the measure?
- Which element is LCP?
- Which action contributes to INP?
- Which additions shift the layout?
Step-by-step method
- 01
Define the population
Separate page, template, device, period and journey before comparison. Record coverage and changes in traffic or content.
Deliverable: measurement scope and limits.
- 02
Find the dominant symptom
Treat LCP, INP and CLS as different experiences. Inspect their distributions rather than one site-wide mean.
Deliverable: prioritized affected segments.
- 03
Tie it to real content
For LCP, find the element and network or rendering delay. For CLS, find shifting elements. For INP, locate interactions and main-thread work.
Deliverable: elements and actions with traces.
- 04
Reproduce in the lab
Build a scenario close to affected conditions. Use developer tools to test a hypothesis without treating lab output as field evidence.
Deliverable: reproduction and likely cause.
- 05
Fix the cause
Prioritize resources, reserve dimensions or reduce blocking work according to evidence. Also test functional and accessibility regressions.
Deliverable: targeted change and local comparison.
- 06
Follow after release
Compare the same pages, devices and suitable periods. Document sample limits and population changes.
Deliverable: field follow-up and next decision.
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| LCP | Main element display in real journeys | Inspect load and rendering |
| INP | Response to real interactions | Reduce blocking work |
| CLS | Layout stability | Reserve space |
| Coverage | Segments with interpretable sample | Extend measurement |
Common pitfalls
- Inferring field experience from one Lighthouse score
- Mixing mobile and desktop
- Optimizing a mean without locating the element
- Crediting a fix despite changed traffic
Frequently asked questions
Why do lab and field differ?
Network, device, cache, content and real behavior can differ from the test scenario.
Does good LCP guarantee good INP?
No. Loading and interaction responsiveness measure different moments.
When is a fix confirmed?
After enough comparison on equivalent segments, accounting for volume and other changes.
References: data, uses and limitations
Documentation reviewed on .
| Source and purpose | Verified data or benchmark | How to use it | Limitation to retain |
|---|---|---|---|
| Google · Core Web Vitals Distinguish loading, responsiveness and visual stability. |
Good thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile, segmented by mobile and desktop. | Separate field measurement from laboratory tests. Record period, URL, device, population and sample size before comparing changes. | These thresholds are not measured results for this site. A good lab score alone does not establish visitor experience. |
Core Web Vitals: thresholds and field data
A useful Core Web Vitals diagnosis starts with a measurement whose scope is known. Identify page or origin, device, period and source before discussing a fix. A page may load quickly in a local run yet remain difficult for part of its audience. This dossier helps interpret values without confusing field results, lab traces and search promises.
Google sources consulted on 23 October 2026. Thresholds follow PageSpeed Insights; examples are fictional CIE data, never measurements of this site. The proposed checks form an acceptance method, not a ranking guarantee.
Google · About PageSpeed Insights · Living documentation · consulted 2026-10-23
Three metrics with explicit thresholds and units
| Metric | Good | Needs improvement | Poor | Reading and unit |
|---|---|---|---|---|
| LCP | ≤ 2500 ms | > 2500 ms · ≤ 4000 ms | > 4000 ms | Loading: appearance of the largest eligible content element. Tie the signal to the observed element before blaming every image. |
| INP | ≤ 200 ms | > 200 ms · ≤ 500 ms | > 500 ms | Interaction responsiveness. An action trace helps separate delay before handling, execution and presentation; a loading score does not replace that investigation. |
| CLS | ≤ 0.1 | > 0.1 · ≤ 0.25 | > 0.25 | Visual stability: a unitless score. Find what shifts elements, then reserve space or fix insertion; do not convert this score to milliseconds. |
Eight reading points to retain with the measurement
| Point | What to retain | Decision consequence |
|---|---|---|
| p75 | The 75th-percentile value for each metric. | This percentile is neither the mean nor the slowest visit. Do not average two population p75 values to invent their combined percentile. |
| Device | The PHONE, DESKTOP or TABLET dimension, or its absence. | Omitting a CrUX API dimension aggregates devices. Compare the same device before and after a fix. |
| URL or origin | The identifier actually returned by the source. | PSI can show origin data when a URL lacks data; do not attribute that result solely to the opened page. |
| Period | The collection dates for the inspected result. | The CrUX API aggregates the preceding 28 days and updates daily. Adjacent dates do not represent independent cohorts. |
| Missing INP | The absence of a measurement and its associated message. | PSI permits its exception when LCP and CLS are good. This does not establish fast interactions. |
| Coverage | CrUX eligibility and population limits. | A popularity threshold exists but its exact value is not published. Do not invent a minimum visit count to make a report available. |
| Histogram | Bucket fractions and the returned p75, separately. | CrUX derives p75 from available data, not just the three displayed buckets; do not reconstruct it exactly from those buckets. |
| Measurement contract | Separate entered values, source data and diagnosis. | This local reader classifies supplied values. It runs neither Lighthouse nor CrUX and observes no visitor. |
Chrome for Developers · CrUX API · Living documentation · consulted 2026-10-23
Chrome for Developers · CrUX methodology · Living documentation · consulted 2026-10-23
Local p75 value reader
Enter p75 values for the same device, period and scope. LCP and INP use milliseconds; CLS is unitless. A blank field means unavailable data, never zero. Dot or comma decimals are accepted, up to four decimal places, without thousands separators. Input caps of 600000 ms and CLS 1000 belong to this tool; they are not official metric limits. Fine fractions in the examples test the reader boundaries; they do not reproduce CrUX report output precision.
Local reading using PageSpeed Insights thresholds and its INP exception. No site test, remote call, stored history, percentile calculation or seconds/milliseconds conversion. The reader cannot verify whether values are comparable: record their provenance before drawing conclusions.
Use digits 0–9. Expected: non-negative number, up to four decimals, no spaces; maximum 600000 ms for LCP/INP and 1000 for CLS. A blank field means data unavailable.
Reading under PageSpeed Insights rules
INP unavailable: PSI exception applied. Interaction responsiveness remains unknown.
Eight fictional examples, accessible without JavaScript
V01 · Three values exactly on good boundaries
- LCP
- 2500 ms
- INP
- 200 ms
- CLS
- 0.1
Assessment passed for the entered values under the PSI rule.
Equality remains good: 2,500 ms, 200 ms and 0.1. No preliminary rounding moves the comparison.
V02 · A fraction above the LCP threshold
- LCP
- 2500.0001 ms
- INP
- 200 ms
- CLS
- 0.1
Assessment not passed for the entered values under the PSI rule.
LCP needs improvement. Rounding its display to 2,500 does not justify reclassifying it as good.
V03 · Upper boundaries of the middle range
- LCP
- 4000 ms
- INP
- 500 ms
- CLS
- 0.25
Assessment not passed for the entered values under the PSI rule.
All three values need improvement. Poor starts strictly above these boundaries.
V04 · Three upper-boundary exceedances
- LCP
- 4000.0001 ms
- INP
- 500.0001 ms
- CLS
- 0.2501
Assessment not passed for the entered values under the PSI rule.
All three metrics are poor. Investigate loading, interactions and layout shifts separately.
V05 · INP unavailable in PageSpeed Insights
- LCP
- 2000 ms
- INP
- Data unavailable
- CLS
- 0.05
Assessment passed for the entered values under the PSI rule.
INP unavailable: PSI exception applied. Interaction responsiveness remains unknown.
PSI permits a passed assessment when LCP and CLS are good despite missing INP. This proves no interaction responsiveness: the exception remains visible.
V06 · LCP absent, two other metrics present
- LCP
- Data unavailable
- INP
- 150 ms
- CLS
- 0.05
Assessment unavailable: LCP or CLS missing.
This scope cannot be assessed under the PSI rule. Missing data is neither zero nor a poor result.
V07 · CLS slightly above 0.1
- LCP
- 2000 ms
- INP
- 150 ms
- CLS
- 0.1001
Assessment not passed for the entered values under the PSI rule.
LCP and INP remain good, but CLS needs improvement. Averaging the three numbers makes no sense: their units and experiences differ.
V08 · Unsupported thousands separator
- LCP
- 2 500 ms
- INP
- 150 ms
- CLS
- 0.05
Correct invalid inputs before any assessment.
Input is rejected. Enter 2500 for 2,500 ms; comma or dot is reserved for a decimal separator. No performance assessment is inferred from invalid input.
Choose evidence suited to the question
| Source | Useful question | Reading limit |
|---|---|---|
| CrUX API | What p75 is returned for this identifier, device and period? | Aggregated data with conditional coverage; missing reports are not proof of failure. |
| PageSpeed Insights · field | What does available experience describe for this URL or origin? | Check the scope actually shown, missing metrics and dates. |
| Lighthouse · lab | Which hypothesis can I reproduce in a controlled scenario? | One run and its score do not prove the field outcome for all users. |
| Service-owned RUM | Which component or journey explains the issue in our instrumentation? | Document method, population and collection differences before comparing with CrUX. |
Two 28-day windows overlap substantially
Fictional calendar example: 1–28 September and 2–29 September share 27 days. This does not mean 27/28 of visits are identical: traffic varies. A recent fix initially occupies only part of the window; record its date and follow the same segment rather than promise an immediate switch.
Six acceptance cases tied to real journeys
| CIE case | Observation to collect | Justified action |
|---|---|---|
| P-IMAGE · Main content | LCP element for the affected template, request order and reserved dimensions. | Prioritize the right media and check rendering; do not prioritize every image. |
| P-INTERACTION · Opening a record | Keyboard or touch action, handling trace and visible feedback. | Reduce the work causing delay without removing state announcements or control behavior. |
| P-STABILITY · Late inserted block | Content shift and control position before and after insertion. | Reserve space or revise insertion; verify understandable focus and touch targets. |
| P-SCOPE · Sparse URL data | Requested URL and origin actually displayed by PSI. | Present the result with its exact scope and add a template-specific observation. |
| P-RELEASE · Recent fix | Change date, collection dates and compared population. | Separate immediate local validation from field follow-up; record other traffic or content changes. |
| P-REGRESSION · Removed third-party script | Performance measurement and business journey after removal, including consent and forms. | Retain the gain only if expected functions, permissions and accessibility remain verified. |
Core Web Vitals document part of the experience; they certify neither accessibility, security nor editorial quality. Improvement guarantees no search ranking. For useful decisions, connect each number to an element or action and retain functional journey checks.
web.dev · Web Vitals · Living documentation · consulted 2026-10-23
Google Search Central · Core Web Vitals · Search guidance · consulted 2026-10-23
Provenance, date and credits
Google documentation consulted 2026-10-23. CIE: original explanations, fictional examples and local threshold reader.
Google · About PageSpeed Insights · HTML SHA-256: 3ca78c96f9df1778aed6aaed634df06b534489176ce8b7824f870661f15e4c26
web.dev · Web Vitals · HTML SHA-256: 024989d5bce351f2a95be14d3a03cba110e5440d055ad5087425a72890ee754a
Chrome for Developers · CrUX methodology · HTML SHA-256: 825f49d646eb05c476a6ec2fbd3a9e12e094e081286489c8ab8def43b9627157
Chrome for Developers · CrUX API · HTML SHA-256: 814c2f1ec4e9cd14028ab30f196f1973ed3722af50fe98f2668e6be5f7338641
Thresholds and reading rules adapted from the cited Google documentation under Creative Commons Attribution 4.0 unless otherwise noted. Original CIE explanations, fictional examples and local reader; no Google endorsement is implied. CC BY 4.0
Google Developers · Site Policies · Documentation licensing and attribution
A/B allocation: data and SRM
Compare populations before comparing metrics
A measurement change can alter who appears in the analysis. Check counts at each stage before attributing a difference to the interface.
- Name the unit: user, device, session and event are not interchangeable.
- Compare telemetry losses and exclusions in each group.
- Keep scope, window and configuration changes with the result.
Explore the allocation check and its limitations →
Microsoft Research · Diagnosing Sample Ratio Mismatch · Published 2020-09-14 · consulted 2026-10-23
NIST/SEMATECH · Binomial distribution · e-Handbook §1.3.6.6.18 · consulted 2026-10-23
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
- web.dev — Web Vitals
- web.dev — Getting started with measuring Web Vitals
- Microsoft Research · Diagnosing Sample Ratio Mismatch
- NIST/SEMATECH · Binomial distribution
- Google · About PageSpeed Insights
- Chrome for Developers · CrUX methodology
- Chrome for Developers · CrUX API
- Google Search Central · Core Web Vitals
Continue exploring
Related analysis
