Core Web Vitals measure three different parts of user experience: loading, interaction responsiveness and visual stability. Largest Contentful Paint (LCP) represents loading experience, Interaction to Next Paint (INP) represents responsiveness, and Cumulative Layout Shift (CLS) represents visual stability.
But these metrics are measurements, not diagnoses. A poor LCP does not automatically mean the hero image is too large. A poor INP does not prove that every JavaScript file is a problem. A poor CLS does not tell you which element caused the movement.
The useful question is not simply “Did the site pass?” It is: Which part of the user experience is failing, under which conditions, and what evidence is needed to find the responsible layer?
What are Core Web Vitals?
Core Web Vitals are user-experience metrics focused on loading, interaction responsiveness and visual stability. LCP measures how quickly the main visible content appears, INP measures responsiveness to user interactions, and CLS measures unexpected layout movement. They show where experience is poor, but additional investigation is required to identify the root cause.
What Are Core Web Vitals?
Core Web Vitals are a subset of Web Vitals designed to represent critical, user-centered aspects of page experience that can be measured in real-world usage.
Loading → LCP | Interaction Responsiveness → INP | Visual Stability → CLS
How quickly the largest relevant visible content is rendered during page load.
How quickly the page can respond visually to user interactions over the life of the page.
How much unexpected layout movement affects the visible page.
Core Web Vitals do not represent every dimension of performance or every aspect of user experience.
They are not:
- a complete performance audit;
- a full UX measurement system;
- a Lighthouse Performance Score;
- a single SEO score;
- a root-cause diagnosis.
Core Web Vitals tell you which part of the experience needs attention. They do not automatically tell you why it is failing.
Core Web Vitals Measure Experience, Not Root Causes
This distinction is central to using Core Web Vitals correctly.
Metric → Observed Symptom → Diagnostic Evidence → Responsible Layer → Root Cause
Suppose field data shows poor LCP.
That is evidence that the loading experience is not meeting the desired threshold for a meaningful portion of users. It does not identify the cause.
The responsible path could involve:
– server response time;
– late discovery of the LCP resource;
– resource loading;
– rendering delay;
– client-side behavior.
The same logic applies to INP and CLS.
Metric interpretation should route the investigation. It should not replace the investigation.
Largest Contentful Paint: Loading Experience
Largest Contentful Paint measures perceived loading performance by reporting when the largest qualifying image, text block or video visible in the viewport is rendered relative to the start of the navigation.
In practical terms, LCP asks:
Depending on the page, the LCP element may be:
- a hero image;
- a large heading or block of text;
- a prominent content image;
- a video poster or other qualifying visible element.
LCP is useful because it is closer to what users perceive as the page’s main loading moment than older milestones that may occur before meaningful content appears.
But LCP does not prove why that content was late.
Poor LCP does not automatically mean “the image is too large.” Server delay, resource discovery, loading behavior or rendering can all contribute.
If LCP is the failing metric, continue with why LCP is slow. Resource discovery belongs in the dedicated late LCP discovery investigation.
Interaction to Next Paint: Responsiveness
Interaction to Next Paint assesses how responsive a page is to user interactions such as clicks, taps and keyboard input across the page’s lifespan.
INP is not primarily a page-load metric.
A page can load quickly and still have poor responsiveness after it becomes visible.
At a conceptual level, an interaction can involve:
- input delay before event processing begins;
- processing time associated with the interaction;
- presentation delay before the browser can paint the next frame.
INP therefore asks a different question from LCP:
A site with an excellent loading experience can still have poor INP if the browser is frequently unable to respond promptly to interactions.
Poor INP does not prove “too much JavaScript” by itself. The investigation still needs to identify which interaction, task, dependency or browser workload is responsible.
For deeper diagnosis, continue with long tasks and INP.
Cumulative Layout Shift: Visual Stability
Cumulative Layout Shift measures visual instability by quantifying unexpected layout shifts that affect visible content.
The user-facing problem is easy to recognize:
- text moves while you are reading;
- a button moves just before you click it;
- content is pushed downward when something is inserted above it;
- the layout changes unexpectedly after initial rendering.
CLS is different from LCP and INP because it is not primarily asking when content loads or how quickly an interaction responds.
It asks whether the layout remains visually stable.
Poor CLS does not automatically mean “images are missing dimensions.” Images are one possible direction, but fonts, ads, embeds, dynamically inserted UI and other layout changes may also require investigation.
LCP vs INP vs CLS
| Metric | Primary experience | Typical user symptom | What it does NOT prove |
|---|---|---|---|
| LCP | Loading | Main visible content appears late | That image size is the root cause |
| INP | Interaction responsiveness | Clicks, taps or keyboard interactions feel delayed | That all JavaScript is problematic |
| CLS | Visual stability | Visible content moves unexpectedly | Which specific element or dependency caused the shift |
The metrics are complementary, not interchangeable.
A site can have good LCP and poor INP. It can have good INP and poor CLS. Improving one metric does not automatically improve the others.
What Counts as Good Core Web Vitals?
The current recommended thresholds classify each metric as good, needs improvement or poor.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 seconds | > 2.5s and ≤ 4.0s | > 4.0 seconds |
| INP | ≤ 200 ms | > 200ms and ≤ 500ms | > 500 ms |
| CLS | ≤ 0.1 | > 0.1 and ≤ 0.25 | > 0.25 |
For field evaluation, the recommended approach is based on the 75th percentile of page loads, segmented across mobile and desktop.
This matters because field performance is a distribution, not one average user and not one test run.
A threshold is a classification boundary, not a root-cause explanation. Crossing the LCP, INP or CLS threshold tells you which experience dimension needs investigation—not which code change to make.
Thresholds and field-evaluation method verified against current web.dev guidance before this draft was generated.
Field Data vs Lab Data
Core Web Vitals are designed to represent real-user experience, but engineers also need controlled lab data to diagnose problems.
Field Data = Real Users / Actual Devices / Actual Networks / Distribution Over Time | Lab Data = Controlled Conditions / Repeatable Tests / Diagnostic Evidence
| Field data | Lab data | |
|---|---|---|
| Source | Real-user measurements such as CrUX or RUM | Controlled tools and synthetic test environments |
| Represents | Actual users, devices, networks, geography and usage patterns | A defined test condition |
| Useful for | Understanding real-world distribution and whether users are affected | Reproduction, tracing, debugging and before/after comparison |
| Limitation | Does not automatically identify the dependency causing the problem | Does not represent every real user or every production condition |
Lighthouse Score Is Not the Same as Core Web Vitals
Lighthouse is a valuable diagnostic tool.
Its Performance Score is a synthetic composite score produced under defined lab conditions. It is not the same thing as field Core Web Vitals.
This distinction prevents several common mistakes:
- a Lighthouse score of 100 does not mean every real user has good Core Web Vitals;
- a lower mobile Lighthouse score does not prove all mobile users fail Core Web Vitals;
- a page can improve its Lighthouse score without fixing the real-user bottleneck that matters most;
- field Core Web Vitals can improve or degrade under conditions that one lab test does not reproduce.
For the dedicated comparison, see Lighthouse vs Core Web Vitals.
Why a Website Can Pass in Lab Tests but Fail in the Field
Lab and field results can disagree without either dataset being “wrong.”
Real users may differ in:
A controlled lab test may exercise one page on one device profile over one test window.
Field data aggregates actual visits over time.
The reverse can also happen: a lab test may reproduce a deliberately constrained condition that performs worse than most real-user visits.
Do not force lab and field data to match. Use each dataset for the question it can answer.
Page-Level and Origin-Level Thinking
Core Web Vitals behavior is not necessarily uniform across an entire site.
Performance can vary between:
- templates;
- URLs;
- mobile and desktop;
- user populations;
- geographic regions;
- network conditions;
- application states.
A fast homepage does not prove every article, product or checkout flow has the same experience.
Likewise, one problematic URL does not automatically prove that every page on the origin behaves the same way.
This is another reason to move away from “one score for the site” thinking.
Good Core Web Vitals Do Not Mean Everything Is Fast
Core Web Vitals deliberately focus on specific user-centered outcomes.
That means a site can:
Have good LCP but poor INP
Main content becomes visible quickly, but interactions can still be delayed.
Have good INP but poor CLS
Interactions respond quickly while the layout remains unstable.
Pass Core Web Vitals but have a slow checkout
A business-critical application flow may have its own server or API bottleneck.
Pass public CWV but have a slow backend
Admin or authenticated application performance can follow a completely different path.
Core Web Vitals are important measurements, but they do not replace a complete root-cause performance investigation.
A Poor Metric Does Not Tell You the Root Cause
This is the most important interpretation rule in the article.
Loading investigation
Possible directions include TTFB, late discovery, resource loading and render delay.
Interaction investigation
Possible directions include long tasks, event processing, main-thread contention and third-party code.
Visual stability investigation
Possible directions include layout insertion, images, fonts, ads and dynamic UI.
These are investigation directions, not automatic diagnoses.
What Should You Investigate When LCP Is Poor?
If LCP is poor, the next step is to investigate the loading path—not to assume one specific optimization.
At a high level, useful questions include:
- Was the initial document response already delayed?
- Was the LCP resource discoverable early?
- Did the resource itself take too long to load?
- Was the resource available but rendering still delayed?
The detailed investigation belongs in why LCP is slow.
What Should You Investigate When INP Is Poor?
If INP is poor, the investigation moves toward interaction and browser main-thread behavior.
Useful high-level questions include:
- Which interactions are slow?
- Was the main thread already busy when input occurred?
- How long did event processing take?
- Was visual presentation delayed after processing?
- Did first-party or third-party work contribute?
The deeper analysis belongs in Interaction to Next Paint and long tasks and INP.
What Should You Investigate When CLS Is Poor?
If CLS is poor, the investigation should identify which visible layout movements contribute to instability and under what conditions they happen.
Possible directions include:
- media dimensions;
- ads or embeds;
- font changes;
- dynamically inserted content;
- UI elements that resize or appear unexpectedly.
The full diagnosis belongs in Cumulative Layout Shift.
Core Web Vitals Diagnostic Routing
WHICH METRIC NEEDS ATTENTION?
│
├─ LCP
│ └─ Investigate the loading path
│
├─ INP
│ └─ Investigate interaction and main-thread responsiveness
│
└─ CLS
└─ Investigate visual stability
↓
IS THE PROBLEM IN FIELD DATA, LAB DATA, OR BOTH?
│
├─ FIELD ONLY
│ └─ Investigate user / device / template / geography variability
│
├─ LAB ONLY
│ └─ Check test setup, conditions and reproducibility
│
└─ BOTH
└─ Prioritize root-cause diagnosis
If several Core Web Vitals fail at the same time, do not assume they share one root cause.
One dependency can affect multiple metrics, but that relationship must be demonstrated with evidence.
Common Core Web Vitals Misconceptions
1. Lighthouse score = Core Web Vitals
No. Lighthouse Performance Score is a synthetic composite score. Core Web Vitals are individual user-experience metrics.
2. Pass Lighthouse = pass field CWV
No. Lab conditions and real-user distributions are different.
3. Poor LCP = image too large
No. Image size is one possible factor, not an automatic root cause.
4. Poor INP = too much JavaScript
No. Diagnosis still needs to identify the interaction and responsible work.
5. CLS = only missing image dimensions
No. Several kinds of layout changes can contribute to visual instability.
6. Low mobile score = mobile users definitely fail
No. One synthetic test does not determine the full real-user distribution.
7. One test is enough
No. Repeatable evidence and field distributions are more reliable than a single run.
8. Passing CWV means the whole site is fast
No. Important performance problems can exist outside the three Core Web Vitals.
9. Failing CWV guarantees SEO loss
No. Search ranking depends on many signals and relevance remains central.
10. Every page has the same CWV behavior
No. Templates, devices, users and runtime conditions can produce different results.
Core Web Vitals and SEO
Core Web Vitals should not be treated as a standalone “SEO score.”
Google states that its ranking systems use Core Web Vitals as part of broader page-experience considerations, while also making clear that good Core Web Vitals do not guarantee top rankings.
Search systems consider many signals, and relevance remains essential.
Do not optimize Core Web Vitals solely to chase a perfect SEO score. Use them to improve real user experience, then evaluate search and business outcomes separately.
Performance can influence user experience and task completion, but business impact such as conversion or revenue should be measured using the site’s own data rather than assumed from the metric alone.
When a Core Web Vitals Investigation Is Needed
A deeper investigation becomes useful when:
When a Core Web Vital fails, the metric tells you where the user experience is breaking down, but not necessarily why. A deeper investigation may need browser traces, request dependencies, field data and application evidence to isolate the responsible layer.
Know which metric is failing, but not why?
A structured Core Web Vitals investigation can connect field metrics with browser, network and application evidence to identify the responsible layer before production changes are made.
WebPerfLab — Measure → Trace → Diagnose → Fix → Verify
Final Takeaway
Core Web Vitals tell you which part of user experience needs attention.
LCP points toward loading experience.
INP points toward interaction responsiveness.
CLS points toward visual stability.
They do not tell you the root cause.
Identify the failing metric→
Gather evidence→
Trace the cause→
Fix the responsible layer→
Verify
That is the difference between score chasing and Core Web Vitals performance engineering.