Metrics come from the high percentiles of real users, not the mean
Aliases: p75 · p95 · CrUX · RUM · lab mean · long tail
What it is
The mean of a controlled lab run describes that machine, that network, that cache. Real users stretch the same page into a long tail: device, network, background work, warm and cold caches stacked together. The mean is pulled back by the fast half and looks "on target"; high percentiles (p75, p95 — the usual reading of field LCP / INP) are where the slow side is still stuck. Take metrics from the high percentiles of the real-user distribution, not from the lab mean.
This is which statistic to report — not which device profile a budget should bind to, and not whether missing a budget keeps the work out of the pipeline.
Why it happens
Performance is a distribution, not a point. Median and mean are dull to a right tail: a few sub-second sessions paint the average green while a mass of mid- and low-end sessions still sit before interactive. Field RUM (including the public Chrome UX Report) collects LCP, INP, and CLS per visit and defaults to p75: a quarter of sessions are slower than that number. The lab (one M-series chip, wired network, empty or warm cache) is a single point under those conditions; averaging a few repeats still does not sample the tail. Optimising to the mean prefers already-fast paths (squeeze one more image) because they weigh more; the percentile points at the slice that still fails (a long task on a low-end CPU).
Percentiles also force "on target" to mean "at least this many users clear the line", not "the average cleared it". p75 green and p95 red means a long slice of users lives on the side you did not report. Report only the mean, and that slice disappears from the sheet.
Where it stops holding
Tiny internal tools (tens of visits a day) make percentiles jumpy; one outlier knocks p95 over, so read raw sessions instead of worshipping the quantile. Lab regression is still useful: the same conditions can be compared repeatably, to catch "this change made it worse", not to declare the user side fast enough. Region, channel, and first visit vs return split into several distributions; one sitewide p75 drowns cold starts in return-visit speed. INP is counted per interaction, not per page load — several clicks on one page all enter the distribution and cannot be mean-compared with LCP's "one per page". Reading the high percentile as "those 25% do not matter" inverts it: p75 exists so that 25% is still inside the target.
Applying it
- Read field LCP, INP, and CLS at p75, and p95 on critical flows. Keep lab numbers as regression probes; do not write them into an external "already fast" claim.
- Split the distribution by first visit / return, region, and device class so one sitewide average cannot hide cold starts.
- Point optimisation at percentile sessions (low-end, slow net, cold cache), not at shaving already-fast lab means.
- How to check: for the same week, three columns — lab mean, field p75, field p95. If the lab is green and p75 is not, you reported the average, not the user. Sample a few p95 sessions to see whether paint or input is late, so the wrong probe is not used.