Notes on measuring latency properly
Someone reports "the site is slow". You run curl -w '%{time_starttransfer}' three
times, get 180 ms and 900 ms, and now you have two numbers and no idea which one is real. A few rules
that save time.
Separate the phases
curl gives you the whole breakdown for free. time_namelookup,
time_connect, time_appconnect and time_starttransfer tell you
whether you are paying for DNS, TCP, TLS or the server. Without that split you are guessing.
curl -o /dev/null -s -w \
'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' \
https://example.com/If time_connect alone is 2× your ping, you are looking at a routing problem, not an
application problem. If time_appconnect − time_connect is large, TLS is the cost: usually
a full handshake because keep-alive got dropped somewhere.
One sample is not a measurement
Take at least ten, discard the first (connection setup), and look at the median rather than the mean. Medians ignore the one outlier that will otherwise dominate your conclusion. If the values are bimodal — half fast, half slow — you have connection reuse on one path and a fresh handshake on the other, and that is a finding, not noise.
Latency is not bandwidth
Users on a 180 ms path feel a 40 Mbit/s link exactly the same as a 400 Mbit/s one, because the first byte is what makes a page feel slow. This is why "we doubled the port" rarely fixes complaints about browsing, while reducing round trips — HTTP/2 multiplexing, session resumption, persistent tunnels — usually does.
Measure from where the users are
A test from your laptop in the same city as the server measures your laptop. I keep a handful of one-dollar VPS instances in different regions that do nothing but run a five-line probe, and I trust those numbers more than any synthetic monitoring dashboard.
The number that matters is the one collected by a machine that is not your machine.