Response time is the total elapsed time between the moment a client sends a request and the moment it receives the complete response, including network transfer, waiting in queues and the actual processing on the server. In server performance work, it is the primary measure of how fast a system feels to its users, and it is usually reported in milliseconds as percentiles rather than as a single average.
Response time is not a fixed property of an application. It depends on load, resource saturation and caching, and it grows sharply as a server approaches its capacity. For that reason it is always read together with throughput and error rates.
What makes up server response time
Response time is the sum of several stages, and optimization starts by finding which stage dominates. For a typical HTTP request, the time divides into network phases on the client side and processing phases on the server side.
| Component | What happens | Typical influence |
|---|---|---|
| DNS lookup | Resolving the host name | Usually cached, otherwise tens of ms |
| Connection setup | TCP and TLS handshakes | One to several round trips |
| Queue time | Waiting for a free worker or thread | Near zero until saturation |
| Service time | Application code, database queries, I/O | Dominant on uncached dynamic pages |
| Transfer time | Sending the response body | Grows with size and distance |
Engineers distinguish service time, the work done while a request is actively processed, from latency in the narrow sense, which is often used for the delay before processing starts or for network delay. The metric time to first byte (TTFB) captures the server’s part up to the first byte of the reply, while full response time includes the whole body.
Why percentiles matter more than averages
Response time distributions are skewed with a long tail: most requests finish quickly, while a minority waits for cache misses, slow queries or garbage collection pauses. An average hides this tail, so performance targets are expressed as percentiles such as p50, p95 and p99.
| Statistic | Meaning | Best use |
|---|---|---|
| Mean | Arithmetic average of all requests | Capacity calculations, not user experience |
| p50 (median) | Half of requests are faster | Typical experience |
| p95 | 95 percent of requests are faster | Common service-level target |
| p99 | Only 1 percent are slower | Tail behavior on busy systems |
| Maximum | Single slowest request | Spotting outliers, unreliable for targets |
Tail latency matters more than it seems. A page that triggers dozens of backend calls is slow whenever any one of them is slow, so a rare p99 delay in one service becomes a common delay for the page. Percentiles must also be computed from raw data or histograms; averaging percentiles from several servers gives a mathematically wrong result.
Response time, throughput and saturation
Response time and throughput are linked through Little’s law: the average number of requests in a system equals the arrival rate multiplied by the average time spent in the system. A server with 20 busy workers and a mean response time of 100 ms can sustain at most about 200 requests per second.
As utilization of the bottleneck resource approaches 100 percent, queue time grows non-linearly. Queueing theory predicts that at 50 percent utilization the waiting time is modest, while above about 80 to 90 percent small increases in load cause large increases in response time. This is why a system can look fine at moderate traffic and collapse during a peak.
| Symptom | Likely cause | Typical fix |
|---|---|---|
| Slow even at low load | Expensive code or queries | Profile and optimize, add caching |
| Fast at low load, slow at peak | Worker pool or CPU saturation | Add capacity, cache, tune pools |
| Periodic spikes | Garbage collection, cron jobs, backups | Reschedule or tune runtime |
| High TTFB only on first visit | Cold caches | Cache warming after deploys |
| Slow only for distant users | Network round trips | CDN, keep-alive, compression |
Typical targets and how to measure them
There is no universal good response time, but practical targets exist for common workloads. Cached responses from a full-page cache or Varnish typically return in a few milliseconds on the server, while uncached dynamic pages in a CMS often need 100 to 500 ms or more. Many teams treat a server TTFB under about 200 ms as a healthy goal for web pages.
- Server-side logs record precise service time per request, for example with request duration fields in web server logs.
- Application performance monitoring breaks time into code, database and external calls.
- Synthetic monitoring measures response time from fixed locations on a schedule.
- Real user monitoring captures what actual visitors experience, including network conditions.
Measurements should state where the clock starts and stops. A load balancer, an application log and a browser can report different response times for the same request, and comparing them without that context leads to wrong conclusions.
Ways to reduce response time
The most effective improvements remove work rather than speed it up. Server-side caching at several levels avoids repeated computation: OPcache stores compiled PHP bytecode, an object cache keeps query results in memory, and a full-page cache serves complete pages without running the application.
Further gains come from efficient connections and smaller payloads. HTTP keep-alive reuses connections and saves handshakes, while Gzip compression or Brotli shrinks text responses and reduces transfer time. Correct sizing of the PHP worker pool avoids both queuing and memory exhaustion. A common mistake is optimizing average response time while ignoring the p99 tail, which is where users notice delays most.
The idea in brief
Response time is how long you wait after you ask a server for something. Clicking a link sends a request, and the clock runs until the full page arrives back. It includes the trip over the network, any waiting in line, and the work the server does.
A good comparison is a coffee shop. Making one coffee takes a minute, but when the queue is long, the wait in line becomes the biggest part of your time. Servers behave the same way, which is why they can feel fast in the morning and slow at lunchtime. The goal is to keep most customers, not only the average one, served quickly.
A practical scenario
An online magazine notices that its pages feel slow during morning traffic peaks. Monitoring shows a median response time of 180 ms but a p95 of 2.4 seconds. The server has 16 PHP workers, and during the peak all of them are busy, so new requests wait in a queue.
The team enables a full-page cache for anonymous visitors, adds an object cache for repeated database queries and warms the cache after each deployment. Because most visitors no longer reach PHP at all, worker utilization falls to about 30 percent at peak. The p95 response time drops below 300 ms, and the team adds a p95 alert so the regression would be detected early.