What’s the difference between latency and response time?

In short, latency usually means the network delay for data to make the round trip between client and server. Response time is the total time that elapses between sending a request and receiving the complete response, which includes latency plus server processing time plus the time to actually transfer the payloads in both directions. The two terms often get used interchangeably, but response time includes more than just the network latency.

What Latency Measures

Latency is dominated by physics and network topology: the geographic distance between client and server, the number of network hops in between, and connection setup costs like DNS lookups and TLS handshakes. A client in Sydney talking to a server in Virginia takes a certain amount of time on every request that no amount of server tuning can remove. After all, it’s nearly halfway around the world.

For this reason, network latency sets the absolute floor for response time. Even the fastest server can’t receive a request and respond to the client faster than the network can carry the bytes. Network pings (if ICMP is forwarded) are the closest approximation of latency, because it’s a small packet and the recipient of the ping does minimal processing before responding.

What Response Time Measures

Response time is the full user-perceived wait: network latency, plus the time it takes to send the request synchronously to the server, plus any time the request spends queued at the server, plus actual processing time (application code, database queries, etc), plus the time and latency of transferring the response body back to the client. Generally, response time is the number that maps most directly to how fast your site feels to the user.

This is also the number load tests typically report and the one your acceptance criteria should target. An end user typically doesn’t care about the exact reasons for a delay, just the total time it takes to get a response.

Why the Difference Matters Under Load

Latency typically stays roughly constant as the load on your server increases, because the speed of light is a constant and the network path doesn’t care how busy your server is. In some cases it’s possible to saturate the network, which can cause dropped packets and increased latency, but in most load tests this isn’t the first bottleneck you’ll encounter.

Rather, server processing time is what balloons under load, as the incoming requests queue up and server resources become saturated. If you see response times climb during a load test while the baseline latency hasn’t changed, the problem is likely a bottleneck in your application or infrastructure, not the network.

The delta between response time and latency tells you where to spend your effort. High baseline latency with stable response times points toward the network path: possibly a CDN, edge caching, or hosting closer to your users. Response times that degrade dramatically under load point toward the server or application: there are probably queries or code to optimize, or server capacity bottlenecks to address.

Load testing from multiple geographic locations is often a good idea because it helps pin down the differences in network latency between regions. Loadster can generate load from 32 cloud regions across AWS and GCP clouds, so you can measure response times from wherever your real users are in the world to get a more accurate latency picture.