Measure an HTTP Request with curl Without Guessing

“The site is slow” does not tell you whether the delay happened in DNS, the TCP connection, TLS negotiation, server processing, or response transfer. curl can expose the main milestones from one request.

curl --silent --show-error --output /dev/null \
  --write-out 'dns=%{time_namelookup}s\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  https://example.com/

These values are cumulative from the start of the operation. To estimate an individual phase, compare milestones rather than treating each line as an independent duration. For example, TLS setup is roughly time_appconnect - time_connect, while application wait after TLS is roughly time_starttransfer - time_appconnect.

If the endpoint redirects, measure the path a user actually follows:

curl --location --silent --show-error --output /dev/null \
  --write-out 'status=%{http_code} url=%{url_effective} redirects=%{num_redirects} total=%{time_total}s\n' \
  http://example.com/

Run several samples. One request may include a cold DNS cache, a new connection, or a temporarily slow backend. Also test from the network where the complaint occurs; a fast request from the server itself says little about a distant client.

curl timing is not full observability. It does provide a clean first split: before connection, before first byte, and through completion. That is usually enough to decide whether to inspect DNS, the network path, TLS, or the application next.

Reference

• curl man page: –write-out

Cover photo: Unsplash.