Core Web Vitals in 2026: Diagnose LCP, INP, and CLS With Real User Data

Direct answer

The current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. A good experience at the 75th percentile is LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, evaluated separately for mobile and desktop.

Use field data such as Chrome UX Report or your own real-user monitoring to decide whether real visitors have a problem. Use Lighthouse and performance traces to explain a reproducible problem in a controlled environment. A 100 Lighthouse score does not prove the mobile field cohort passes, and a failing CrUX cohort does not tell you which line of code caused it.

Fix the metric component that is actually slow, protect the result with a regression budget, and never promise that passing Core Web Vitals will produce a ranking or revenue increase.

What you will be able to do

By the end, you will be able to:

• define LCP, INP, and CLS in terms of user experience;
• classify good, needs-improvement, and poor thresholds;
• distinguish field, lab, page-level, and origin-level data;
• break LCP and INP into diagnostic components;
• prioritize the first fix for a failing cohort;
• set a performance budget and verification method without chasing a vanity score.

The three Core Web Vitals

Google's Web Vitals guidance identifies three stable Core Web Vitals.

Largest Contentful Paint, or LCP

LCP measures loading performance through the render time of the largest qualifying visible content element in the viewport.

The user question is:

When does the main visible content feel loaded?

Good: at or below 2.5 seconds.
Needs improvement: above 2.5 and at or below 4.0 seconds.
Poor: above 4.0 seconds.

Interaction to Next Paint, or INP

INP measures responsiveness by observing the latency of user interactions and reporting a high-latency representative interaction for the page visit.

The user question is:

After I click, tap, or type, how long until the page visibly responds?

Good: at or below 200 milliseconds.
Needs improvement: above 200 and at or below 500 milliseconds.
Poor: above 500 milliseconds.

On highly interactive pages, INP generally ignores one worst interaction per 50 interactions to reduce the effect of rare outliers. Read the exact current definition in web.dev's INP guide.

Cumulative Layout Shift, or CLS

CLS measures unexpected visual instability using layout-shift scores grouped into session windows.

The user question is:

Did content move unexpectedly while I was trying to read or act?

Good: at or below 0.1.
Needs improvement: above 0.1 and at or below 0.25.
Poor: above 0.25.

User-initiated expected changes are treated differently from unexpected shifts. Reserve space and manage dynamic content rather than hiding all movement.

Threshold and diagnostic table

The thresholds are experience guidance. They are not promises of ranking or conversion.

Why the 75th percentile matters

An average can hide the slowest meaningful user cohort. Google recommends evaluating the 75th percentile of page loads, segmented by mobile and desktop.

If 75 percent of measured visits have LCP at or below 2.5 seconds, the p75 LCP meets the good threshold. If the average is 2.0 seconds but p75 is 3.1 seconds, a substantial group still has a slower experience.

Segment further when you can:

• country or region;
• effective connection;
• device capability;
• template;
• signed-in state;
• release version.

Do not slice so aggressively that the sample becomes unstable or privacy-sensitive.

Field data versus lab data

Field data

Field data comes from real eligible user visits under real devices, networks, caches, extensions, and behavior.

Examples:

• Chrome UX Report, or CrUX;
• PageSpeed Insights field section;
• Search Console Core Web Vitals groups;
• your own real-user monitoring.

The CrUX API documentation says its records use a rolling 28-day collection period and are updated daily. Data is aggregated for eligible pages or origins.

Limitations:

• not every page has enough eligible data;
• origin fallback can hide page differences;
• Chrome users are not every user;
• the window reacts slowly to a release;
• field data identifies affected experience, not exact code cause.

Lab data

Lab data runs a page in a controlled environment.

Examples:

• Lighthouse;
• Chrome DevTools Performance panel;
• WebPageTest;
• local interaction traces.

Advantages:

• reproducible conditions;
• detailed waterfall and main-thread evidence;
• rapid debugging before release.

Limitations:

• one device and network profile;
• synthetic navigation;
• limited real interaction coverage;
• cache and location differ from the field;
• INP may be unavailable without interactions.

Why Lighthouse and CrUX disagree

They answer different questions.

Lighthouse asks:

What happened in this controlled run?

CrUX asks:

What did eligible real Chrome users experience across the rolling field window?

A static Astro page can score 100 in a desktop lab and still have poor mobile field INP if real users open a heavy consent manager, interact with a calculator, or run on slower devices.

Page-level versus origin-level data

CrUX can report a specific URL when enough data exists. Otherwise, tools may show origin-level data.

Origin-level data combines different templates and journeys. A fast documentation page can hide a slow checkout. A slow app can make an editorial page look guilty.

Always label:

• page or origin;
• mobile or desktop;
• field or lab;
• date window;
• p75 or another percentile;
• sample eligibility.

Diagnose LCP by components

Treat LCP as a chain.

time to first byte
  + resource load delay
  + resource load duration
  + element render delay
  = observed LCP

Time to first byte

The document response is slow.

Investigate:

• server work;
• cache miss;
• redirect;
• geography;
• backend dependency;
• cold start.

Resource load delay

The browser discovers the LCP resource late.

Investigate:

• CSS background images;
• client-injected images;
• missing preload for a truly critical resource;
• blocking styles or scripts;
• lazy loading applied to the above-the-fold LCP image.

Resource load duration

The resource takes too long to transfer.

Investigate:

• oversized image;
• wrong format or dimensions;
• slow CDN;
• compression;
• competing requests.

Element render delay

The resource is ready but cannot paint.

Investigate:

• render-blocking CSS;
• main-thread work;
• hidden element;
• hydration;
• font state;
• animation delay.

Do not optimize the server when the actual LCP delay is a late-discovered client-rendered image.

Diagnose INP by phases

Every slow interaction can be separated into:

input delay
  + event-handler processing
  + presentation delay
  = interaction latency

Input delay

The interaction waits because the main thread is busy.

Typical causes:

• long script tasks;
• third-party code;
• hydration;
• parsing a large payload;
• synchronous storage.

Processing duration

The event handlers themselves are expensive.

Typical causes:

• filtering thousands of rows synchronously;
• repeated layout reads and writes;
• large state update;
• heavy validation;
• unnecessary work inside each keystroke.

Presentation delay

Handler work ends, but the next frame is delayed.

Typical causes:

• expensive style and layout;
• rendering a huge component tree;
• synchronous follow-up tasks;
• complex paint.

Break long tasks, reduce work, yield to the browser where appropriate, and render only what the user needs. Do not remove useful functionality merely to improve a score.

Diagnose CLS

Use the layout-shift track to identify the moving element and what caused it.

Common causes:

• images or embeds without dimensions;
• cookie banner inserted above content;
• ad slot without reserved space;
• late web font change;
• accordion or alert inserted unexpectedly;
• client hydration replacing server markup with a different size.

Reserve space, use stable placeholders, coordinate fonts, and insert dynamic UI in predictable regions.

A repeatable CWV procedure

1. Confirm the field problem

Record metric, threshold, percentile, device, page or origin, date window, and affected template group.

2. Check data eligibility

Do not label a new page “passing CrUX” when it has no page-level field record.

3. Reproduce a representative case

Use an appropriate mobile profile, location, cold or warm state, and real interaction. One best desktop run is not representative.

4. Decompose the metric

For LCP, identify the element and four timing components. For INP, identify the actual interaction and three phases. For CLS, identify the shift cluster and trigger.

5. Rank root causes

Choose the cause that explains the largest observed delay and can be fixed without breaking the task.

6. Add budgets before release

Examples:

• maximum route JavaScript;
• maximum long-task duration;
• maximum LCP image bytes;
• reserved layout dimensions;
• p75 RUM alert threshold.

7. Validate in lab

Confirm that the targeted component improved and no accessibility or functionality regression appeared.

8. Release safely

Use a cohort or staged rollout when risk justifies it. Annotate the release.

9. Verify in field data

Use RUM for faster directional feedback and wait for the relevant CrUX rolling window. Compare the same cohort and definitions.

Worked example: desktop passes, mobile INP fails

A lesson template has:

• desktop lab INP-like interaction: 90 ms;
• mobile lab interaction: 260 ms;
• mobile field INP p75: 420 ms;
• desktop field INP p75: 150 ms.

The team wants to upgrade the server.

Trace the interaction

On mobile, opening the table filter produces:

• input delay: 170 ms;
• handler processing: 110 ms;
• presentation delay: 140 ms;
• total: 420 ms.

The main input delay comes from a 190 ms analytics and hydration task already running when the user taps. The handler then filters and renders the full 4,000-row synthetic table.

Prioritized fix

1. defer nonessential analytics initialization;
2. break hydration work into smaller tasks;
3. move filtering to an efficient data structure or worker where justified;
4. render a virtualized visible result set;
5. preserve keyboard and screen-reader table access;
6. add a long-task and mobile interaction budget.

Upgrading the server may improve the initial document response, but it does not address the measured interaction phases.

Verification

The lab trace falls to 160 ms on the representative mobile profile. RUM for the released cohort trends down. CrUX p75 is reviewed after the rolling field window has enough post-release exposure.

Why this can fail

If the new virtualized table removes semantic relationships or keyboard access, performance improved while the product regressed. Guardrails must include task completion and accessibility.

Core Web Vitals and Google Search

Google's Core Web Vitals and search results documentation explains that Core Web Vitals are used by ranking systems as part of page experience.

Do not overstate this:

• good CWV does not guarantee top rankings;
• poor CWV does not make relevant content invisible by itself;
• relevance and usefulness remain essential;
• a performance fix can improve users without creating a measurable ranking change.

Prioritize catastrophic usability failures, indexability, security, and task completion before chasing a perfect lab score.

SEOryon performance-budget planner

Download the CWV Threshold and Performance-Budget Planner.

For every template, record:

• device;
• whether page-level field data is eligible;
• p75 LCP, INP, and CLS;
• current status;
• first diagnostic;
• release budget;
• owner and review date.

The included rows are synthetic examples. Replace them with real approved aggregates. Never include personal or tenant-level browsing data.

Exercise: prioritize four templates

For each, choose the first intervention and verification method.

Answer key

• Academy: fix late LCP resource discovery, verify representative lab trace, then mobile field cohort.
• Calculator: instrument real interactions and gather RUM before declaring INP good or bad.
• Comparison: prioritize the measured long task and interaction phases, then verify task completion and mobile p75.
• Pricing: do not assume the page passes from origin data. Add page-level RUM and inspect representative lab evidence.

Penalize any answer that chooses solely from the highest Lighthouse score or treats missing data as good.

Common mistakes

Using FID as the current Core Web Vital

INP replaced FID as the responsiveness Core Web Vital.

Optimizing averages

Use p75 and meaningful cohorts.

Treating Lighthouse as CrUX

One is a controlled run. The other is aggregated field experience.

Chasing 100 before fixing broken content

Performance supports the task. It does not replace it.

Improving server time for an interaction problem

Break the actual INP phases down first.

Claiming revenue causality from one before-and-after

Performance and revenue can move together for many reasons. Use an appropriate experiment and preserve uncertainty.

Final checklist

• The metric is LCP, INP, or CLS under the current definition.
• Good, needs-improvement, and poor thresholds are correct.
• Data is labeled field or lab.
• Page versus origin scope is visible.
• Mobile and desktop are separate.
• The percentile and date window are recorded.
• Field-data eligibility is checked.
• LCP is decomposed into response, discovery, load, and render delay.
• INP is decomposed into input, processing, and presentation delay.
• CLS shifts have a visible trigger.
• The first fix addresses the measured root cause.
• Functionality and accessibility are guardrails.
• A regression budget exists.
• Release annotations and RUM monitoring are configured.
• Ranking and revenue outcomes are not guaranteed.

Frequently asked questions

Why is Lighthouse green while Search Console fails?

Lighthouse is one controlled test. Search Console uses CrUX field data across eligible real users and a rolling window. Device, network, interaction, route, and period can differ.

How quickly will CrUX show my fix?

CrUX uses a rolling 28-day collection period updated daily. Directional changes can appear gradually. Your own RUM can provide faster evidence.

Does passing Core Web Vitals improve rankings?

Core Web Vitals contribute to page experience, but passing does not guarantee ranking gains. Fix them for users and measure search outcomes separately.

What is the best tool for INP?

Use field data to identify affected cohorts and RUM to capture real interactions. Use Chrome performance traces to diagnose the specific slow interaction and its phases.

Should I remove JavaScript to improve INP?

Remove unnecessary work, not useful functionality by default. Split long tasks, reduce handler and rendering cost, and preserve accessibility.

Sources and methodology

Community research showed two recurring questions: why CrUX can be worse than a 90 to 100 Lighthouse score, and which tool can reveal INP problems. Those questions shaped the answer-first distinction between field decision data and lab diagnosis. Community claims were not used as evidence.

1. web.dev, Web Vitals, updated 31 October 2024 and checked 28 July 2026. Official metric definitions, thresholds, and p75 guidance.
2. web.dev, Interaction to Next Paint, updated 2 September 2025 and checked 28 July 2026. Official INP definition, thresholds, and interaction model.
3. Chrome for Developers, CrUX API, updated 11 February 2025 and checked 28 July 2026. Official 28-day aggregated real-user data model.
4. Google Search Central, Core Web Vitals and Google Search, updated 10 December 2025 and checked 28 July 2026. Official search relevance and page-experience context.

Previous: JavaScript SEO and Agent-Readable Interfaces
Next: /academy/structured-data-schema/ is the planned Step 11 route and should remain unpublished until its full lesson exists.