Three questions a visitor asks without noticing
Those are the Core Web Vitals, and they were chosen because each one maps to a thing people complain about: a blank screen, a button that moved as they reached for it, and a tap that did nothing. Everything else — total bytes, request count, a Lighthouse score — is a means to those ends, not an end.
| Question | Metric | Good |
|---|---|---|
| Is it there? | LCP — when the biggest thing appeared | under 2.5 s |
| Does it stay still? | CLS — how much the layout jumped | under 0.1 |
| Does it answer me? | INP — how long a tap takes to show something | under 200 ms |
Read the 75th percentile, never the average
Half your users are faster than the median, which tells you nothing about the ones having a bad time — and averages are dragged around by a handful of very slow sessions. The convention is the 75th percentile: the experience three quarters of visits are at least as good as.
A page with a 1.3 s median and a 5.2 s 75th percentile is not a fast page. It is a fast page for people on a fast device in a city, and a slow one for everybody else.
sessions (LCP, ms): 900 1100 1200 1300 4800 5200 6100
mean: 2943 ← dragged up, describes nobody
median: 1300 ← describes the good half
p75: 5200 ← the sixth of seven: what a quarter of your users are worse thanMeasure before you change anything
Performance work done from intuition is a coin flip. Almost every page has one dominant problem — a 4 MB hero image, a render-blocking font, a query that takes two seconds — and the second-largest problem is usually an order of magnitude smaller.
So: measure, find the biggest thing, fix that, measure again. Three cycles of that beats a week of general tidying, and the measurement is what tells you when to stop.
A development machine on office wi-fi hides everything. A mid-range Android on a throttled connection is what most of the world is using — and it is the difference between "JavaScript is 300 KB" being irrelevant and being the whole problem.
Lab and field
You need both, in that order: the field data says there is a problem and where, the lab reproduces it and says why. A team with only lab numbers optimises things nobody was waiting for.
| Lab | Field | |
|---|---|---|
| What it is | you, running a test | real visits, reported by real browsers |
| Tool | Lighthouse, WebPageTest, a profile | the web-vitals library, CrUX, your analytics |
| Good for | diagnosis, and comparing two versions | knowing whether anything is actually wrong |
| Bad at | representing real conditions | telling you why |
And the cost of being slow
Every study of this says the same thing in a different currency: abandonment rises with load time, conversions fall, and mobile users leave first. You do not need the numbers from somebody else's e-commerce site — you need your own funnel, split by LCP bucket. Once that chart exists, performance work stops needing to be argued for.