Metrics & Measurement
What Is Response Time?
Response time is the total elapsed time from sending a request to receiving the complete response — everything the client waits for, network included.
Also known as: Round-Trip Time, Request Duration
What response time includes
Response time is measured from the client’s point of view, which means it contains several things that are not your application code. When a number looks bad, breaking it into components usually shows where the time actually went.
- DNS resolution, then TCP connection setup, then the TLS handshake — paid once per connection, or every request without keep-alive.
- Time to send the request, which matters for large uploads.
- Server processing: routing, application code, database queries, calls to upstream services.
- Time to transfer the response body back, which grows with payload size and shrinks with compression.
Response time, latency, and server time
These three get used interchangeably and mean different things. Latency is the delay before data starts arriving. Server time is what your application logs — processing only, excluding the network entirely. Response time is the whole round trip.
The gap between server time and response time is where surprises live. An endpoint that logs 40 ms and measures 900 ms from the client is telling you the problem is in TLS setup, payload size, or the network path — not in the code you were about to optimise.
Never report the average alone
Response time distributions are skewed, not normal. A long tail of slow requests barely moves the mean while dominating what users experience, so a mean of 120 ms is perfectly compatible with 5% of requests taking three seconds.
Report percentiles instead, and keep the maximum in view. Mean plus P95 plus P99 plus max describes the distribution; the mean on its own conceals it.
Response time is not page load time
A load test reports response time per request, but a user waits for a page — and a page is many requests, some of them sequential. An endpoint with a 150 ms response time is not a 150 ms experience if the page fetches it after two blocking round trips that must finish first.
When translating a result into a user-facing promise, add up the critical path rather than quoting the fastest endpoint on it. This is also why shaving 20 ms off an already-fast API often changes nothing a user can perceive, while removing one sequential round trip changes a great deal.