When a frontend team reports their LCP as "1.8 seconds," the question worth asking immediately is: 1.8 seconds for whom? The median user? The 75th percentile? The user on a mid-range Android phone at the tail of your geographic distribution? That number, stated without a percentile, is almost always the mean or median — and the mean and median are the wrong statistics to use when you are trying to predict bounce rate and protect conversion.
The Core Web Vitals specification is explicit about this. A page meets the "good" LCP threshold when 75% of page loads complete LCP within 2.5 seconds. The entire framework is built around p75 for a reason: p50 is what happens to the average session, and the average session is not the one at risk of bouncing.
Why the Median Hides Your Problem
Performance distributions for web pages are not symmetric. They skew right — a long tail of slow sessions pulls the mean up, but the median sits comfortably below the pain threshold. If your page has a bimodal performance distribution (fast desktop-WiFi sessions plus slow mobile-4G sessions), the median lands between the two modes and accurately describes neither population.
Consider a simplified example. Your LCP data for the past seven days breaks down like this: 60% of sessions complete LCP in 1.2–1.8 seconds (desktop Chrome, WiFi, cached assets). The remaining 40% complete LCP in 3.8–5.2 seconds (mobile Android, 4G, first-time visitors with no cache). Your p50 would sit somewhere around 2.0–2.2 seconds — a number that looks reasonable, passes most internal performance targets, and gets reported to stakeholders as "LCP is under 2.5 seconds." Your p75, however, is around 4.1 seconds — firmly in the "needs improvement" range by Core Web Vitals standards, and representing one in four of your actual page loads.
The p50 is not lying to you. It is accurately telling you about the median session. The problem is that the median session is not the session that bounces. Bounce behavior is concentrated at the tail, and p75 is the metric that begins to represent that tail without requiring you to instrument all the way to p95 or p99.
The Bounce Correlation Is at the Tail
The relationship between page load time and user abandonment is not linear. It does not mean "every 100ms of additional LCP costs you X% bounce rate." The relationship is closer to a threshold effect: below a certain load time, most users wait. Above it, incrementally more users leave — and the rate of departure accelerates in the 3–5 second range on mobile. The users hitting your p75 and p95 LCP are the ones most likely to have already left before the page finishes loading.
This is why p75, specifically, became the Core Web Vitals threshold denominator. It is a practical balance between protecting most users and avoiding over-indexing on the very long tail (p95+), which may represent edge cases beyond your control — users on 2G, devices with active malware scanning, severely resource-constrained hardware. The p75 range is the range where your engineering work can actually move the needle on bounce.
What p50 Is Actually Good For
We are not saying p50 is useless. It is a meaningful signal for understanding typical-user experience, and for capacity planning exercises where you want to understand median load characteristics across your infrastructure. If your median LCP increases significantly, that is also worth investigating — it suggests a broad performance degradation, not a tail-concentrated problem.
The issue arises when teams use p50 as their primary pass/fail performance gate. "Our median LCP is under 2.5 seconds" sounds good. It does not prevent 30% of your sessions from having a 4.5-second LCP. If that 30% is disproportionately your highest-intent traffic — first-time visitors who discovered you through paid search, mobile users in growth markets where your business is expanding — then optimizing for p50 is optimizing for the wrong users.
A Real Segmentation Scenario
An e-commerce platform running a product catalog with heavy image assets found that their overall p75 LCP sat at 3.8 seconds — above the 2.5-second "good" threshold. That alone warranted investigation. But the useful insight came from segmenting: desktop users on WiFi had a p75 of 1.6 seconds. Mobile users on 4G had a p75 of 5.4 seconds. The aggregate p75 of 3.8 seconds was actually a blend of two very different populations — and the slower population was also the majority of sessions, since their catalog traffic skewed heavily mobile.
Their product images were unresponsive: same 800KB JPEG regardless of viewport. Desktop users on WiFi loaded them fast enough that LCP met the threshold. Mobile users on 4G loaded the same full-size image, paying the full bandwidth cost. The fix — responsive images with appropriate srcset breakpoints and next-gen formats — moved mobile p75 LCP from 5.4 seconds to 2.1 seconds. The desktop numbers barely changed because they were never the problem.
None of this would have been visible through p50 reporting. The median sessions — predominantly faster desktop traffic — masked the mobile tail entirely.
Setting Performance Budgets at p75
Once your team commits to tracking p75 as the primary LCP metric, the next question is how to set and enforce budgets. A few practical principles:
Segment your budgets. A single p75 budget applied to all sessions is better than nothing, but it still blurs the signal. Set separate p75 budgets for mobile and desktop, and consider connection type as a secondary dimension. "Mobile 4G p75 LCP under 3.0 seconds" is a budget you can engineer toward. "Overall p75 LCP under 2.5 seconds" may be achievable on paper by improving desktop performance while leaving mobile unchanged.
Gate on p75 in CI, not just lab scores. CI performance gates typically run synthetic Lighthouse tests. Those are valuable regression fences. But adding a field-data check to your deploy process — comparing the post-deploy p75 for affected pages against a baseline — catches the regressions that slip past lab tests. Third-party script interactions, runtime behavior, and real device CPU constraints do not show up in Lighthouse, but they will appear in your p75 within hours of a deploy going live.
Watch trend, not snapshots. A single p75 reading is less informative than p75 tracked over time. Gradual degradation — p75 LCP climbing 80ms per week for six weeks — does not trigger threshold alerts but represents the same cumulative impact as a single large regression. Time-series p75 monitoring catches the slow-moving problems that snapshot reporting misses.
The Reporting Shift
Changing which percentile you report is, in practice, a cultural change as much as a technical one. Stakeholders accustomed to seeing "LCP: 1.9 seconds" will need context when that number becomes "mobile p75 LCP: 4.2 seconds." The second number is more honest, but it is also harder to achieve.
The transition is worth making. Teams that track p75 field data make different optimization decisions than teams tracking p50 lab scores. They prioritize mobile image optimization over desktop rendering tweaks. They notice third-party script interactions that synthetic tests miss. They catch regressions before they compound into chronic slow-page problems that are expensive to untangle.
The percentile you track determines the users you protect. p75 protects the ones at risk of leaving.