Skip to learning content
03-05Technical SEO

Measure loading, response and stability.

Read Core Web Vitals as three different experiences, with the evidence behind each number.

Let’s get into it Intermediate
No perfect score required.
← See the full learning path
Three distinct ivory performance specimens sit on a graphite bench: a violet loading aperture, a silver response actuator and a suspended stability platform.
SEO SUPREME SCHOOLLESSON 5 / 6
05/06Your place
in this path
5minA focused
read
~20minPut the idea
into practice
3Questions to
check your thinking

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.

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?
MAKE THE CONNECTION

Different units. Separate targets.

Three independent metric rulers show fictional LCP above its good target, INP within its good target and CLS above its good target, with units and labels kept separate.
Fictional mobile field example at the 75th percentile: LCP 3.1 s, INP 180 ms and CLS 0.16. Threshold markers come from web.dev; these are not live site measurements.

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.

SEE IT IN PRACTICE

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.

Three numbers need three readings
MetricExample versus good targetReading
LCP3.1 s versus ≤ 2.5 sDoes not meet the good target; investigate loading.
INP180 ms versus ≤ 200 msMeets this target in the stated fictional data.
CLS0.16 versus ≤ 0.1Does 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.

  1. Record each metric with its unit, percentile and fictional scope.
  2. Identify which good targets are met and which are not.
  3. Explain why the fast local load does not invalidate the field example.
  4. Choose one loading or stability problem to investigate and specify an implementation check.
  5. 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.

1. Which metric is unitless?
2. What does a page-load-only Lighthouse run directly lack for measuring INP?
3. A field panel has no usable data. Which status is honest?
Take it with you

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.

  1. web.dev: Web Vitals

    Primary definitions, recommended good targets, percentile assessment and lab/field distinction, including Lighthouse TBT versus INP.

  2. Google: Core Web Vitals and Search

    Official search and page-experience context. No ranking or conversion lift is promised.

Reviewed