A red Core Web Vitals report is evidence that a group of real visits crossed a performance threshold. It is not a diagnosis. The same failing metric can come from different templates, devices, assets, third parties, or interactions. A sitewide performance project launched from the colour of the report can spend heavily on pages and code that were never the constraint.
Google recommends good Core Web Vitals for Search and for user experience generally. Its current thresholds are evaluated at the 75th percentile: LCP within 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1. Treat those thresholds as a common performance language, then investigate what produced the field result.
| Metric | What it represents | Start the diagnosis with |
|---|---|---|
| LCP | When the likely main content finishes rendering | The actual LCP element, server response, render-blocking resources, image delivery, and client rendering |
| INP | How quickly the page presents the next frame after interactions | The slow interaction, main-thread work, event handler, DOM complexity, and third-party scripts |
| CLS | Unexpected movement of visible content | The shifted elements, missing dimensions, late fonts or embeds, injected content, and animation choices |
Field data answers “what happened”; lab data helps answer “why”
The Chrome User Experience Report aggregates eligible Chrome visits. Search Console groups similar URLs and reports field performance, which is useful for finding the scale and template pattern of a problem. Field data is historical and affected by real devices, networks, geography, cache state, and user behaviour.
Lighthouse and DevTools reproduce a controlled visit or interaction. They may not match the field, and that is expected. Use them to trace a representative failure: inspect the LCP element, record a slow interaction, identify a long task, or observe the source of a layout shift. A perfect lab run does not cancel a field problem; a poor lab run does not establish that most users experienced it.
Fix the issue sooner when the failing template serves valuable visits, the problem affects task completion or conversion, the cause is shared across many pages, and the remediation is tractable. Rank it lower when field volume is thin, the affected pages have little business value, or a more fundamental crawl, content, or demand problem dominates.
Diagnose at the narrowest reusable layer
- Segment. Separate mobile and desktop, then template or route type. A product template problem is not automatically a sitewide problem.
- Choose examples. Test a representative poor URL, a good URL from the same template if one exists, and a high-value URL.
- Name the experience. Record the slow element, interaction, or shift rather than only the metric score.
- Trace the cause. Identify the server, asset, JavaScript task, DOM operation, font, embed, or injected block responsible.
- Fix the shared cause. Prefer a template, component, or delivery correction over page-by-page exceptions.
- Verify twice. Confirm the lab trace changed, then wait for enough new field data to assess real visits.
Do not sell the threshold as a traffic forecast
Google describes Core Web Vitals as part of page experience, alongside other aspects, and recommends good results. It does not offer a traffic gain for crossing a threshold. Relevance and content quality can dominate a result set. The business case should therefore include the direct experience: fewer delayed interactions, less visual disruption, faster access to the primary content, and a simpler technical system.
When a broader page audit reveals that the real problem is obsolete or overlapping content, use the content audit worksheet before polishing the performance of a page that should be merged or removed.
Google Search Central's Core Web Vitals guidance and web.dev's metric definitions and thresholds. Reviewed 13 August 2026.