Your overall p75 LCP of 2.4 seconds puts you in the "good" band by Core Web Vitals standards. Congratulations. Now break that number down by device type, connection class, and geography, and watch what happens to it. For many products, that single aggregate metric conceals a population of users — often 20-40% of total sessions — for whom performance is dramatically worse than the aggregate suggests. Those users are real. They are bouncing or converting at a lower rate than their faster counterparts, and your aggregate p75 does not show you they exist.
Segmentation in real-user monitoring is not a reporting nicety or a dashboard feature to enable eventually. It is the mechanism through which performance data becomes actionable. Without segments, you know something is slow. With segments, you know which users are slow, under what conditions, and what to fix first.
The Three Primary Dimensions
The dimensions that carry the most diagnostic weight for web performance are device category, connection type, and geography. These three interact in ways that make the combination more informative than any single dimension alone.
Device category separates users whose hardware constraints dominate performance from users whose network constraints dominate. High-end devices on slow networks are network-bound: their CPUs can parse JavaScript fast, but they are waiting for bytes. Low-end devices on fast networks are compute-bound: bytes arrive quickly, but JavaScript parsing and layout calculation are slow due to weak CPUs. Mid-range devices on variable connections face both constraints simultaneously, which is why they consistently appear at the slow end of p75 distributions.
Connection type (4G, WiFi, 3G, and the increasingly relevant 5G segment) interacts with device in predictable ways. The largest performance gains for mobile users almost always come from reducing resource payload rather than optimizing execution — because network RTT and bandwidth are the binding constraints, not CPU time, for most 4G users. But for 3G users or users in coverage-limited areas, even small payload reductions create significant LCP improvements because the connection RTT and throughput floor is so much lower.
Geography encodes CDN edge proximity, regional carrier network quality, and local infrastructure conditions that are entirely outside your control but still affect your users' experience of your product. A product that performs well in Western Europe may have dramatically different p75 numbers in Southeast Asia, sub-Saharan Africa, or Latin America — not because the product code is different, but because the distance to the nearest CDN edge is different, the typical carrier network characteristics differ, and the device mix in those markets skews toward lower-end hardware.
What Unsegmented p75 Hides
Consider a SaaS product with a global user base. Their aggregate mobile p75 LCP is 2.8 seconds — just at the edge of "good." When they segment by geography, they discover that 28% of their mobile sessions originate from three Southeast Asian markets where they have recently run acquisition campaigns. p75 LCP for those sessions is 6.1 seconds. The remaining 72% of mobile sessions — predominantly North American and Western European users — have a p75 of 1.9 seconds. The aggregate of 2.8 seconds is a weighted blend of 1.9 and 6.1 that accurately describes neither population.
The 6.1-second p75 for their Southeast Asian users is entirely attributable to CDN edge distance: their assets are being served from a US-East origin with no regional edge in that geography. Adding a CDN PoP in Singapore brings that p75 to 2.3 seconds. Without the geographic segment, the problem would have remained invisible — the overall p75 looks fine, and no threshold alert fires.
This pattern repeats across product types. The specifics vary (CDN gaps, image sizes, JavaScript payload, third-party scripts with regional infrastructure issues), but the mechanism is the same: aggregate metrics hide population subsets with dramatically different performance profiles.
New vs. Returning Visitors as a Segment
The new-vs-returning dimension is often treated as an analytics metric rather than a performance metric, but it is one of the most useful performance segments available. New visitors are by definition cold-start experiences: no browser cache, no service worker entries, no HTTP cache for sub-resources. Returning visitors may have substantial cache coverage depending on your cache policy and their revisit interval.
The performance gap between new and returning visitors on mobile is typically 50-100% in p75 LCP. If your product relies on acquisition traffic — paid search, social, referral — then new visitors are a disproportionately important population. They are also the population most likely to bounce on slow pages, because they have no prior experience with your product to motivate patience.
Tracking p75 separately for new vs. returning visitors tells you whether your caching strategy is working (it should close the gap significantly) and whether your cold-start experience is acceptable for the users who are most likely to bounce on first impression.
Browser and OS as Secondary Dimensions
Browser and operating system are secondary segmentation dimensions — useful for debugging specific browser behavior but rarely the primary driver of p75 variability. The exception is Safari on iOS, which has historically had different performance characteristics for specific operations (service worker support, memory management, JavaScript engine behavior) that can make Safari p75 LCP diverge from Chrome by 15-30% on the same device.
If you see a notable divergence between Chrome and Safari in your p75 data, it usually points to one of a few specific issues: a JavaScript API used on the critical path that has different performance characteristics between V8 and JavaScriptCore, a resource loading priority behavior that differs between Blink and WebKit, or a CSS feature that triggers more expensive layout in one browser than the other. Browser segmentation is most useful for flagging this class of browser-specific regression rather than for day-to-day performance target setting.
How to Implement Meaningful Segmentation
Segmentation requires that your RUM data collection includes the relevant dimensions alongside each metric observation. At minimum, each LCP event should be tagged with: effective connection type (from the Network Information API), device category (derived from navigator properties or UA), geographic region (at country level, coarser is fine for most products), and navigation type (new session vs. returning, back-forward vs. fresh navigate).
We are not saying you need to segment across all possible dimension combinations simultaneously. A four-way cross-segment of device × connection × geography × visit type produces too many cells to manage without statistical sampling issues. The practical approach is to start with the two-way segments that matter most for your product's user distribution: mobile vs. desktop, and geography by your top-5 traffic markets. Add connection type once you have a clear picture of your geographic distribution. Drill into browser when specific regressions point there.
The goal is not maximum dimensional complexity. The goal is finding the 20-30% of your user population that has a dramatically different experience than your aggregate suggests, and understanding what is causing that difference well enough to fix it. A well-designed two-way segmentation answers that question faster than an eight-way matrix that requires a data analyst to interpret.
Setting Segment-Specific Budgets
Once you have segmented data, the natural next step is setting p75 budgets per segment rather than just for the aggregate. A single budget of "p75 LCP under 2.5 seconds" for all users is achievable if you optimize for your fastest segments while leaving the slow ones unaddressed. Segment-specific budgets prevent that outcome.
A practical budget structure for a product with global mobile traffic: overall mobile p75 LCP under 3.0 seconds, desktop p75 LCP under 2.0 seconds, and for your top-3 traffic markets by session volume, mobile p75 LCP individually under 3.5 seconds. The higher threshold for specific markets acknowledges infrastructure constraints (CDN edge distance, carrier network characteristics) that cannot be fixed with application-level changes alone. It also makes the budget meaningful — a threshold that is never expected to be met for a given segment is not a budget, it is a liability.
Performance budgets at the segment level turn your RUM data from a monitoring dashboard into an engineering specification: these are the populations, these are the targets, this is the gap you are closing. That specificity is what makes performance work tractable rather than a perpetual "p75 is still too high on mobile" backlog item.