Support forwards complaints that the application is unusably slow. Every engineer who checks finds it responsive. Both observations are accurate: performance is a distribution, not a number, and the team is sampling the fastest end of it on high-end hardware over an excellent network. The users complaining are somewhere in the tail you have no visibility into.
01Lab data cannot find this
Synthetic tests run from a data centre on a fixed device profile produce a repeatable number, which makes them useful for catching regressions between deploys. They cannot tell you what your actual users experience, because they do not sample your actual users.
Field data from real sessions is the only thing that answers the question. Collect timings from real browsers with device, connection type, geography and application version attached, then look at the ninety-fifth percentile rather than the median. The median describes the users who were not going to complain.
| Lab | Field | |
|---|---|---|
| Answers | Did this deploy regress? | What do users experience? |
| Sample | One synthetic profile | Real device and network mix |
| Catches | Code regressions | Device, network, geography effects |
| Blind to | The tail | Causes without instrumentation |
02Segment before you theorise
Aggregate numbers hide the pattern. The same overall average can describe a uniformly mediocre experience or an excellent one for most users with a severely degraded one for a specific segment, and those require completely different responses.
Break the data down by device class, connection type, country and browser. A problem confined to mid-range Android points at JavaScript execution time on slower processors. One confined to a country points at network latency and missing edge caching. One confined to a browser version points at a polyfill or an unsupported API.
03JavaScript costs far more on slow devices
A bundle that parses and executes in two hundred milliseconds on a development machine can take well over a second on a mid-range phone that is several years old. The difference is not proportional to price - single-core performance on budget hardware lags by a wide margin, and JavaScript execution is largely single-threaded.
This is why a site can score well in a lab test and still feel unresponsive in the field. The device sitting on the desk is not representative, and the fix is usually shipping less JavaScript rather than optimising what is shipped.
| Segment affected | Likely cause |
|---|---|
| Mid-range Android only | JavaScript execution and main thread blocking |
| One geography | Latency, no edge caching, distant origin |
| Mobile networks only | Payload size, too many round trips |
| Logged-in users only | Uncached personalised responses |
| Intermittent, all segments | Backend contention or a slow dependency |
04Buy one cheap phone
Keep an inexpensive Android device on the team and test on it over a throttled connection. It converts an abstract percentile into something people feel directly, and it changes decisions in a way that dashboards do not.
Browser throttling is a reasonable approximation and costs nothing, but it models a slower processor rather than the thermal behaviour, memory pressure and background load of a real budget device. Both are useful; the physical device is more persuasive.
05Instrument first, then fix
Without field measurement you are guessing, and optimisation guided by guesses tends to improve things that were already fast. Collect real user timings with enough dimensions to segment, establish where the tail actually is, and only then decide what to change.
Set the target as a percentile rather than an average - for instance, largest contentful paint under two and a half seconds for ninety-five percent of sessions. That framing keeps attention on the users who are having the worst experience, which is where the complaints originate.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer