The idea, in plain English
Start here.
The current Core Web Vitals are LCP for loading, INP for interaction responsiveness and CLS for visual stability. Their recommended good targets are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, assessed at the 75th percentile. A lab test, real-user data and an overall performance score are different evidence.
A page can appear quickly yet react slowly to a tap. Another can respond promptly but move the button just as you try to use it. A single speed score hides these differences. Start with the experience, then read the relevant metric and inspect what was actually measured.
A few words you’ll meet.
OPEN WHAT YOU NEED ↙LCP
Largest Contentful Paint: a loading metric based on when the largest qualifying visible image or text block is rendered.
INP
Interaction to Next Paint: a responsiveness metric reflecting the time associated with a user interaction through the next painted frame.
CLS
Cumulative Layout Shift: a unitless visual-stability metric for unexpected layout shifts. It is not measured in seconds.
75th percentile
A value at or below which roughly three quarters of the measured observations fall. It is different from an average or median.
Field and lab data
Field measurements come from real visits; lab measurements come from controlled tests. Record source, scope, device context and observation window before comparing them.
Match the metric to the experience
Think about three moments: the main content becomes visible, a tap produces the next visible response, and the layout stays where the reader expects it. LCP, INP and CLS address those different concerns. They do not measure every aspect of usability, accessibility or business success.
Use the correct unit. A fictional LCP of 3.1 seconds describes loading time; an INP of 180 milliseconds concerns responsiveness; a CLS of 0.16 is a unitless score. Do not add these numbers together or label their sum a meaningful user-experience measurement.
Read the target and the statistic together
Google’s web.dev guidance gives the good targets as LCP ≤ 2.5 seconds, INP ≤ 200 milliseconds and CLS ≤ 0.1. For a Core Web Vitals assessment, all three should meet their recommended targets at the 75th percentile, with mobile and desktop considered separately.
The percentile matters: an average can hide slower experiences. Before calling a result good, confirm the metric, statistic, scope and time window. A homepage result is not automatically a result for every product page. A missing field assessment is unavailable evidence, not proof of either a pass or a failure.
- Metric and unit: which experience does this number describe?
- Statistic: is this a percentile, average or one test run?
- Scope: which URL or group, device and period?
- Availability: did the tool actually return usable data?
Different units. Separate targets.
Use lab and field evidence for different checks
Field data helps describe experiences among the visits it represents. A controlled lab run helps reproduce and investigate a problem under stated conditions. Differences can come from devices, networks, content, interactions or collection scope. Keep the original labels rather than forcing the two numbers to agree.
A page-load-only Lighthouse run has no actual user interaction from which to measure INP. Its Total Blocking Time can help investigate responsiveness, but TBT is not INP. Developer tools can record a performed interaction in a controlled session; that session still does not become a representative field assessment. One green test does not establish every visitor’s experience.
Investigate one demonstrated issue
Choose a specific affected page and reproduce the observed problem. For loading, identify the relevant content and inspect its delivery. For a slow interaction, record the actual action and work around it. For layout movement, inspect which element changed position and whether space was reserved. A slow metric is a starting point, not a complete root-cause diagnosis.
Describe one proposed correction and the check that would demonstrate its implementation. Retest under comparable lab conditions, then review relevant later field evidence when available. Record other changes and collection windows before claiming an effect. Better performance can improve the experience, but a metric correction does not guarantee a search ranking or conversion increase.
Three numbers need three readings
Fictional 75th-percentile values for a hypothetical mobile field report. They are teaching data, not measurements of SEO Supreme or a claim about visitors.
| Metric | Example versus good target | Reading |
|---|---|---|
| LCP | 3.1 s versus ≤ 2.5 s | Does not meet the good target; investigate loading. |
| INP | 180 ms versus ≤ 200 ms | Meets this target in the stated fictional data. |
| CLS | 0.16 versus ≤ 0.1 | Does not meet the good target; investigate unexpected movement. |
Put it into practice
Write an evidence-aware performance note
Use the fictional mobile values above. You also have one fast local page-load test, but no controlled interaction trace and no later field data after a proposed layout fix.
- Record each metric with its unit, percentile and fictional scope.
- Identify which good targets are met and which are not.
- Explain why the fast local load does not invalidate the field example.
- Choose one loading or stability problem to investigate and specify an implementation check.
- Mark interaction diagnosis and post-change field outcomes as unverified.
Keep your working notes in your own document. This page saves only your completion check, not your answers or customer data.
Check your understanding
Make the call.
Choose an answer for each question. Then compare the reasoning.
You have a useful next step.
- LCP, INP and CLS describe different experiences and use different units.
- Read recommended targets with the 75th percentile and actual scope.
- Use controlled tests to investigate, and later field data to review represented visits.
Completion is your own learning record. Quiz scores and practice checks are saved separately, on this browser.
Sources & context
The sources below explain the factual foundations and editorial methods used in this lesson. Worked examples, planning models and exercises are illustrative teaching material.
- web.dev: Web Vitals
Primary definitions, recommended good targets, percentile assessment and lab/field distinction, including Lighthouse TBT versus INP.
- Google: Core Web Vitals and Search
Official search and page-experience context. No ranking or conversion lift is promised.
