Define scope
Select templates, URLs, devices, regions and important interactions. Record dates, sample volume and intervening changes.
GUIDE / PROTOCOL
Measure the performance people experience
A lab score describes one test; experienced performance depends on users, devices and journeys.
Direct answer
How do you measure performance without mistaking a score for experience?
Separate field from lab data, mobile from desktop, and pages from journeys. Track LCP, INP and CLS distributions, then find the responsible resource or interaction before changing the site.
01 / Review method
Review method
Compare field and lab
Review field Core Web Vitals at the 75th percentile; use lab traces for reproduction and diagnosis, not as a substitute for users.
Find causes
Identify the LCP element, critical resources, blocking scripts, long tasks, layout shifts and third parties. Support each hypothesis with a trace.
Fix and monitor
Prioritize by reach and cost, compare before and after under similar conditions, and watch for regressions.
MEASUREMENT WORKSHOP
Three thresholds for reading experienced performance
Good 75th-percentile thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1. Compare the same device, period and scope. The table explains a fictional example.
Fictional example · no measurement of this site or a client
| Indicator | Calculation or threshold | What the result establishes |
|---|---|---|
| Loading · LCP | LCP ≤ 2.5 s | 2.8 s exceeds 2.5 s: investigate main-content rendering. |
| Interaction · INP | INP ≤ 200 ms | 180 ms is below 200 ms: the interaction threshold is met in the example. |
| Stability · CLS | CLS ≤ 0.1 | 0.08 is below 0.1: the stability threshold is met in the example. |
From observation to decision
Identify the measurement
Separate field data from a lab run. Keep URL or origin, device and dates.
Investigate the cause
For LCP, review main content; for INP, interactions; for CLS, layout movement.
Compare again
Review the same scope after a fix. One good lab run does not describe every visitor.
A better mean and a worse median
Five lab loads are measured before and after in the same test context. The series are fictional, not a real-use distribution.
| Observed unit | Before | After |
|---|---|---|
| Five observations (seconds) | 1 ; 1 ; 1 ; 1 ; 8 | 1.5 ; 1.5 ; 1.5 ; 1.5 ; 1.5 |
| Mean (seconds) | 2.4 | 1.5 |
| Median (seconds) | 1 | 1.5 |
Why does “faster on average” not describe the whole series?
The mean falls from 2.4 to 1.5 s while the median rises from 1 to 1.5 s. Retain observations and the metric chosen before testing. Five trials do not replace a real-visit percentile.
Method reference : NIST · Measures of Location ·
Reading workshop
An LCP image can arrive after DOMContentLoaded
Three fictional traces separate cache, network and rendering stages without claiming real performance.
Fictional data and records for learning: none of these results comes from a live service query.
Compare C1, W1 and C2 without mixing conditions
All timings start at navigation start. Here TTFB means responseStart−startTime, not isolated server time. LCP entries are observed during five seconds without interaction.
If the table exceeds the screen, scroll horizontally; arrow keys work when the region is focused.
| Check | Scenario observation | What it establishes | Next action |
|---|---|---|---|
| C1 · cold cache · network A | TTFB 400 ms; DCL 900 ms; image LCP 2,100 ms | DCL occurs before the last observed LCP paint. | Follow the image: response ends at 1,800 ms, then rendering. |
| W1 · warm cache · network A | TTFB 350 ms; DCL 700 ms; image LCP 1,000 ms | Cache conditions differ from C1. | Describe a different condition, not a correction’s effect. |
| C2 · cold cache · network B | TTFB 800 ms; DCL 1,400 ms; image LCP 3,800 ms | Network differs; C2 is not a comparable C1 repetition. | Separate series and repeat under identical conditions. |
| C1 timeline | LCP−DCL = 1,200 ms; LCP−image end = 300 ms | Intervals, not established causes. | Examine discovery, transfer and rendering; do not add timestamps as disjoint durations. |
What does the C1/W1 difference establish?
Open each proposition to compare its diagnosis. More checks may still be needed.
A correction saved every visitor 1,100 ms.
No: cache changes and no general user effect is measured.
DCL at 900 ms proves C1 was fully displayed.
No: the scenario’s LCP image renders later.
A 1,100 ms difference between two laboratory conditions.
Appropriate. Attribute gains only after controlled before/after repetitions with matched cache, network and content.
Retained comparative trace
Case: DEMO-P24; 5 s observation without interaction C1 cold/A: TTFB 400; DCL 900; LCP 2100 ms C1 image: response ends 1800 ms; paint 2100 ms W1 warm/A: TTFB 350; DCL 700; LCP 1000 ms C2 cold/B: TTFB 800; DCL 1400; LCP 3800 ms C1−W1 LCP: 1100 ms; different conditions Outcome: hypothesis to test, not field improvement
Retain version, viewport, device, cache, network, LCP element and resource traces. State repetitions and aggregation rule before relating these tests to field data.
Documentation of the rules, separate from fictional examples
02 / Evidence to keep
Evidence to keep
Measured population
Source, dates, device, region, URL or page group and sample size.
Distribution
LCP, INP and CLS with percentile, range and field/lab distinction.
Causal trace
Network timeline, affected element, task or resource and tested hypothesis.
Decision
Change, owner, observed effect and monitoring threshold.
Compare other situations and exercises
PRACTICAL CHECK
Before reaching a conclusion
A frequent misreading and the check that helps avoid it.
Premature conclusion
A laboratory score alone does not represent every visitor’s experience. Devices, networks, pages and measurement time create differences.
Decisive check
Define priority pages and journeys, compare field and lab measurements, then isolate image, script and font costs. Check that a fix improves the journey without moving the problem elsewhere.
AFTER THE REVIEW
Decide from the evidence
Lab results improve while field data stays flat
Do not claim user improvement yet. Check collection delay, population, cache, device mix and URLs before attributing the gap.
Loading is fast but an interaction is slow
Inspect the interactions affecting INP, JavaScript tasks and third parties; retest the same journey after a fix.
Decision and review trail
Decision and review trail
What the check must help decide and what to retain so the choice can be reviewed.
Sufficient evidence
Measure representative pages with the same device, network, cache and version; distinguish field from lab data. Retain the dominant resource trace.
Next decision
Treat the hero image, CSS or script that causes the observed delay. Compare before and after under the same method and watch for regressions.
Detailed inspection cases
Typical situations for preparing a check. They do not describe completed assignments or actual observations.
A fast local measurement hides a slow mobile journey
What to inspect
Compare repeated loads, network conditions and devices. Separate laboratory measurements from usage observations and inspect the spread, affected pages and collection conditions.
Decision and action
Address the identified bottleneck in the priority journey. Do not generalise a local average to every visitor or attribute a variation to a fix without comparable conditions.
Record to retain
Keep the scenario, environment, measurement count, distribution and resources that delayed useful content.
The main image waits for an avoidable dependency
What to inspect
Inspect the request timeline and when the image is discovered, downloaded and displayed. Check scripts, styles and loading options that delay this sequence.
Decision and action
Fix the observed cause and measure again. Reducing file size is insufficient when the browser discovers the main content resource late.
Record to retain
Keep before-and-after traces, resource URL, dimensions, size and the priority changes actually applied.
An average hides a slow page
What to inspect
Separate templates, languages, devices and measurement conditions.
Decision and action
Prioritize the observed slow task over a reassuring overall average.
Record to retain
URL, conditions, dominant resource and post-fix measurement.
Review before deciding
These questions complement the method. They help establish what is actually supported while retaining qualifications in the record.
Comparable measurement
Do before and after measurements specify matching device, network, cache, page and conditions? Retain several observations and distinguish laboratory tests from real usage.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- The before observation uses a phone and cold cache; the after observation a desktop and warm cache.
- Declared state
- Observed discrepancy
- Decision and next check
- Recreate comparable conditions before claiming a gain. Retain initial observations as different contexts.
Journey without regression
Does faster loading preserve search, interactions, forms and useful images? Test a late interaction and an error state, not only initial arrival.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- The main image loads faster, but the search button stops responding after input.
- Declared state
- Observed discrepancy
- Decision and next check
- Fix the functional regression before closing the improvement. Retest empty search, useful search and error state.
Population and percentile
Are percentile and device category retained? Do not confuse an average of isolated runs with a real-use distribution.
Documentation consulted : web.dev · Web Vitals ·
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- Three lab runs yield a mean; no real-visit distribution is available.
- Declared state
- Not checked
- Decision and next check
- Label the result as a lab measurement. Leave the real-use percentile unverified and specify device class.
TOOLS / REGISTERS
Information to record
Separate lab measurements from field data. Compare the same page, device and comparable windows; retain the available percentile and sample size.
- Access date and time zone
- Exact URL
- Device / browser
- Metric / measurement
- Sample / population
- Observed result
- Decision / next action
- Review owner
- Next review
03 / FAQ
Frequently asked questions
Why do numbers disagree?
Field data spans real devices and networks; a lab uses a controlled scenario. Compare populations and dates.
What is the 75th percentile?
A value that 75% of measured visits meet or improve on for a given metric and population.
Can one test diagnose INP?
No. Test multiple interactions and use field data; a lab trace explains a particular case.
Should every image be optimized?
Start with images that actually affect perceived loading, including dimensions and priority.
What value should one keep in mind when measures vary?
Keep the executions and describe their dispersion with an explicit synthesis rule. The choice must meet the objective of control and enable a comparison to be made again under the same conditions.
04 / Official references
Official references
Describe a context
DOCUMENTED REFERENCE
Read Core Web Vitals thresholds without inventing a verdict
LCP, INP and CLS describe three different dimensions of experience. Published thresholds classify a value; they do not turn an isolated test into a representative observation of every visitor.
| Reference | Value or form | What it identifies |
|---|---|---|
| LCP | ≤ 2500 ms · > 4000 ms | LCP describes rendering of the largest eligible content. Good through 2500 ms inclusive; needs improvement above that through 4000 ms inclusive; poor above 4000 ms. |
| INP | ≤ 200 ms · > 500 ms | INP describes responsiveness to eligible interactions. Good through 200 ms inclusive; needs improvement through 500 ms inclusive; poor above that. It is not the full duration of a business task. |
| CLS | ≤ 0.1 · > 0.25 | CLS is a unitless visual stability score. Good through 0.1 inclusive; needs improvement through 0.25 inclusive; poor above that. Do not convert this score into milliseconds. |
| p75 | 75% | Field assessment uses the 75th percentile: about three observations in four are at or below this value. An arithmetic mean answers a different question. |
| COHORT | URL / origin · device · period | Compare the same scope: page or origin, device and period. Thresholds are identical on mobile and desktop; populations must be read separately. |
| MISSING | ≠ 0 | A missing metric, including one with no eligible interaction, is not zero. Without all three required metrics and their context, do not announce an overall pass. |
Classify three values using published thresholds
Initial values: limits of the good category. No network request or site measurement. You declare the context; the data are not verified.
Enter three nonnegative decimals without units or thousands separators (64 characters maximum). Decimal dot or comma accepted.
Initial example: all three limits belong to the good category. Numeric classification only: no conclusion about passing field assessment.
| Metric | Entered value | Numeric category |
|---|---|---|
| LCP | 2500 ms | Good |
| INP | 200 ms | Good |
| CLS | 0.1 | Good |
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2500 ms | > 2500 · ≤ 4000 ms | > 4000 ms |
| INP | ≤ 200 ms | > 200 · ≤ 500 ms | > 500 ms |
| CLS | ≤ 0.1 | > 0.1 · ≤ 0.25 | > 0.25 |
Implication for the record
The reader below applies only the published numeric boundaries. Initial values are the limits of the good category, not measurements of this site.
Do three good values prove that the site passes?
Only under field assessment conditions: three comparable, eligible p75 values at the declared scope. A laboratory result or manual entry does not verify these conditions.
Primary documentation
Documentation consulted on .
DOCUMENTED REFERENCE
CrUX: separate the window, scope and available observations
A CrUX response describes an eligible population within a rolling window. Before comparing two p75 values, retain the requested key, devices and returned dates with the result.
| Reference | Value or form | What it identifies |
|---|---|---|
| url / origin | page / origin | A URL query targets a page; an origin query aggregates pages of that origin. A good origin result does not automatically replace a specific page measurement. |
| formFactor | PHONE · DESKTOP · TABLET | The formFactor filter isolates a device category. Omitting it aggregates available categories; it does not mean desktop. Different filters change the population. |
| collectionPeriod | firstDate · lastDate | The response schema uses firstDate and lastDate within collectionPeriod. Archive both boundaries with the metric, rather than only the API consultation date. |
| WINDOW | 28 days | The period spans 28 days even for a more recently created page. This window proves neither 28 days of actual observations nor continuous sample inclusion. |
| percentiles.p75 | ≠ mean | The p75 field is a percentile, not a mean or an instantaneous measurement. Successive windows overlap substantially; their values are not two independent samples. |
| ELIGIBILITY | public · popular | Eligibility depends on users, pages and a minimum popularity whose exact threshold is not public. A missing response implies neither zero traffic nor poor performance. |
Implication for the record
The API updates daily with a collection delay. Repeating a query does not produce real time measurement; retain the scope actually returned.
Is it possible to describe the period as 28 measured days?
Prefer a 28-day aggregation window. A recent or temporarily ineligible page may supply only some of the possible observations.
Primary documentation
Documentation consulted on .
DEEPER READING / PRACTICE
Connect a technical measurement to a use case
A page receives a variable score depending on the tool or performance. To understand the experience, it is necessary to document the context and distinguish the laboratory measurement from the available usage observations.
Updated on .
Priority checks
Release device, simulated network, page, cache status and repetitions. Examine the resources that delay the useful display or interaction, and then reproduce the measurement after correction.
Interpretation pitfalls
Comparing two scores from different conditions can attribute to an optimization an effect that comes from the test. A technical gain can also leave a confused path unchanged.
Working record to retain
A measurement file contains conditions, gross values, dispersion and changes made. It connects the correction to the stage of the path it seeks to improve.