API Response Latency Calculator

response = DNS + TCP (1 RTT) + TLS (RTT × handshake round trips) + request RTT + server processing + body ÷ throughput; a reused connection zeroes the first three terms. A cold request pays DNS, then one round trip for TCP, then one or two more for TLS, before the request itself makes a round trip and the server does its work. Decomposing it this way shows which term actually dominates, and the p95/p99 multiples project the tail that users complain about but averages hide.

Optimising the wrong term is the most common latency mistake — shaving 20 ms of server time is pointless when the client is spending 96 ms on handshakes it could have skipped by reusing a connection or terminating TLS at the edge.

This calculator takes 9 inputs: DNS resolution, Round-trip time to the endpoint, TLS handshake cost, Server processing time, Response body size, Effective client throughput, Connection already established, p95 multiple of the median, p99 multiple of the median. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

The mean is dragged down by fast cache hits and hides the slow tail. If 1% of requests take five times as long, a user making a hundred calls to render one page almost certainly hits it — so the p99, not the average, is what the page actually feels like.