Core Web Vitals are assessed at the 75th percentile of visits rather than at the median or the 95th. What does "p75 LCP is 2.4 seconds" actually tell you about your users, and why is p75 the chosen cut point?
answer
- a rank, not an arithmetic result
- three out of four loads
- p50 ignores a whole bad quarter
- the tail you cannot engineer away
- stable enough to hold a team to
basics
~20 sA p75 LCP of 2.4 seconds means three quarters of measured page loads reached their largest contentful paint at or before 2.4 seconds, and one quarter were slower. p75 is chosen because it represents most visits while staying far enough from the extreme tail to be stable and actionable.
solid answer
~50 sp75 is a statement about visits, not about users or about an average: 75% of the measured loads hit LCP at 2.4s or better, and 25% did worse. The choice of cut point is a deliberate compromise. The median would let you call a page fast while a quarter of visits are terrible, because p50 is blind to everything above the middle. p95 or p99 are dominated by genuinely extreme conditions — a dying phone on a dead network — so they swing week to week and can be almost impossible to move by improving your own code. p75 sits where a clear majority of visits are covered, yet the number still responds to real engineering work and is stable enough to hold a team to. Under the current guidance (LCP, INP and CLS), each metric is judged at its own p75.
go deeper
Be able to translate the number into plain words: three of every four measured loads were at least this fast, one in four was slower. Getting the direction right, and not calling it an average, is what is being checked.
Explain the tradeoff behind the cut point — why the median hides a bad quarter, why the extreme tail is noisy and dominated by conditions you cannot engineer — and note that each vital is assessed at its own p75 from its own samples.
Demonstrate that you use p75 as a bar and the distribution as the diagnosis: know why a shipped fix takes weeks to appear in a rolling field window, and why a site-wide figure needs segmenting before it can direct any work.
Own the reporting policy: whether teams are measured on the public rolling figure or on in-house monitoring, how to stop a single headline percentile from being gamed, and how to fund tail work that will never show up in the number you report upward.
## Reading the number correctly "p75 LCP = 2.4s" is a rank statement about a set of measurements: sort every measured LCP in the reporting window, walk three quarters of the way up, and read the value. Three quarters of loads finished at or under 2.4 seconds; one quarter took longer. Three things it is *not*: - It is **not an average**. No arithmetic is done to the values; only their order matters. - It is **not per user**. Field data is normally collected per page view, so a single visitor loading ten pages contributes ten samples. Heavy users are weighted more than casual ones. - It is **not a promise about any individual**. Someone at p90 experiences p90, and that person is included in the 25% the headline number does not describe. Each Core Web Vital is assessed at its own p75 independently — LCP, INP (which replaced FID as a Core Web Vital in 2024) and CLS each get their own percentile computed from their own samples. A page can be at p75 "good" for LCP and "poor" for INP, and those two percentiles come from different visits. ## Why not the median The median answers "is the typical visit fast?" and stops there. It is completely insensitive to everything in the upper half of the distribution. You could double the load time of the slowest 40% of visits without p50 moving a millisecond. As a bar to hold a site to, that is far too easy to satisfy while a very large number of real people are having a bad time. A programme that optimises for the median optimises for the users who were already fine. ## Why not p95 or p99 The top few percent of a load-time distribution is populated by conditions you largely do not control: a five-year-old budget phone, a train tunnel, a proxy that stalls, a device thermally throttling, a user who backgrounded the tab. Three practical problems follow. **Stability.** Only 1 in 20 samples sits above p95, and only 1 in 100 above p99, so those estimates are far noisier than p75 for the same volume of data. Small sites cannot compute a meaningful p99 at all, and even large ones see it jump for reasons unrelated to any deploy. **Actionability.** If your p99 is dominated by 3G-on-an-old-Android, shipping a 40 KB saving barely registers there, but it clearly moves p75. A target nobody can move stops driving work and starts being explained away. **Ceiling effects.** Some of the tail is not a web-performance problem at all. Optimising towards a number you cannot reach with engineering effort misallocates the team. ## Why p75 in particular p75 is the point where the two failure modes cross. It covers a clear majority of visits, so passing it means most people genuinely had a good experience — you cannot pass by fixing only the easy half. But it stays out of the extreme tail, so it is statistically stable at realistic traffic volumes and responds to ordinary optimisation work: shrinking the critical path, prioritising the hero image, cutting main-thread work. It is also deliberately paired with thresholds chosen to be *achievable* — the pass/fail bars are set so that a well-built site can realistically get a majority of its real-world traffic under them, rather than being aspirational targets only fast-network desktop users reach. The final ingredient is the reporting window. Public field datasets aggregate over a rolling multi-week period, which smooths day-of-week and campaign effects but also means a fix takes weeks to fully show up in the reported figure. Teams that ship an improvement and check the dashboard the next morning conclude nothing happened; they need their own real-user monitoring with a shorter window to see the change land, and the rolling field number to confirm it. ## Using it without being fooled p75 is the bar you are held to, not the whole picture. Two habits keep it honest. First, always look at the distribution behind it — the good/needs-improvement/poor split tells you whether you are at 74% good and one push away, or at 40% good with a structural problem. Second, always segment: a site-wide p75 is an average of populations, and mobile-versus-desktop or fast-versus-slow-country splits usually differ by more than any optimisation you are about to ship. The headline p75 tells you whether you pass. The segments tell you what to do.
- Is p75 computed per user or per page view?Per page view, in the field datasets that report it. Every navigation contributes a sample, so a visitor who browses twenty pages counts twenty times and a bouncer counts once. That means heavy users, and the page templates they visit most, dominate the number. It is one more reason to look at per-template segments rather than treating the site-wide figure as "how our users feel".
- You ship a real LCP improvement and the reported p75 barely moves. What is going on?Usually the reporting window. Public field data aggregates over a rolling multi-week period, so a fix released today is averaged with weeks of pre-fix traffic and only fully appears once the window has rolled past the deploy. Check your own real-user monitoring with a daily window to confirm the change landed, then wait for the rolling figure to catch up before concluding anything.
- Does a page pass Core Web Vitals if two of the three metrics are good and one is poor at p75?No — the assessment requires each metric to be in the good range at its own p75, so a single poor metric fails the set. This matters practically because the three metrics have different causes: LCP is usually a loading and discovery problem, INP a main-thread work problem, CLS a layout-reservation problem. Passing one says nothing about the others.
- Would tracking p95 alongside p75 ever be worth it?Yes, as a diagnostic rather than a target. p95 tells you how deep the tail runs and whether a release made the worst experiences worse while the headline improved. Treat it as a signal to investigate a segment — a device class, a region, a cache-miss path — not as a number the team is scored on, because at most traffic volumes it is too noisy to hold anyone to.
saying these in an interview costs you the question
- Says p75 means the page loads in 2.4 seconds on average
- Inverts it: claims 75% of loads were slower than the value
- Thinks p75 is computed per user rather than per visit
- Argues p99 would be a stricter and therefore better target
- Assumes all three vitals share one percentile calculation