Your average response time is lying to you
The mean hides the requests that make people leave. Percentiles, and the arithmetic of how often a user meets your worst case.
Mean response time is the most quoted and least useful performance metric. A handful of very slow requests barely move it, and those are precisely the ones users notice.
Percentiles describe experience
The median is the typical request. The 95th and 99th percentiles describe the tail — the slowest 5% and 1%.
The tail matters more than its share suggests, because a page load is rarely one request. A page making twenty backend calls will, on average, contain one call from the slowest 5%. Your p95 is a routine occurrence at page level, not an edge case.
This is why teams optimising the mean see no change in complaints. They improved the requests nobody was unhappy about.
Where tails come from
Garbage collection pauses, which hit randomly and hurt the request unlucky enough to be in flight.
Cache misses, where the slow path is the real cost of the operation and the fast path was hiding it. Right after a deploy, everything is the slow path.
Contention: a connection pool with nothing free, a lock, a saturated thread pool. Queue time is invisible in application timings unless you measure it deliberately.
And data variance — the customer with fifty thousand records rather than fifty, taking a code path nobody profiled.
If you have never looked at your slowest 1%, you have never looked at the requests that lose you users.
Budgets make it a design constraint
A latency budget states what a page may cost, then divides it: so much for the database, so much for rendering, so much for external calls.
It changes the conversation. "Is this fast enough" becomes "does this fit", and a new external call has to come out of somewhere rather than being added to the total.
It also makes trade-offs explicit at design time rather than after a complaint.
Measure the whole thing
Server-side timing excludes DNS, connection setup, TLS, asset download and rendering. A response served in 80ms can produce a page that feels slow.
Real user monitoring reports what people experienced, across their devices and networks rather than yours. It is routinely humbling: a fast server on a slow phone over a mobile network is a slow product, and only one of those three is visible in your application logs.