API latency: where the milliseconds come from

API latency is measured in four separate parts, not one number: DNS, TCP connection, TLS handshake and server time. Across twenty consecutive requests to https://ui.eneawork.it/api/stats the median is 100 ms, and only 36 ms of it belongs to the server: network and handshake spend the rest.

The breakdown of one request

The four phases add up to 100 ms, which matches the median of time_total. Does the connection reuse the same socket across the series? No: every curl invocation opens a new connection, so the handshake is paid every time. That is the worst case, and it is the one a client sees when it calls the API once.

The command

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{size_download}\n" \
    https://example.com/api/stats
done

The command needs bash, curl and a connection. Replace the URL with your endpoint. time_appconnect stays zero on plain-text connections, so over HTTP the TLS phase disappears and the comparison with HTTPS stops being honest.

Where the time goes when the response grows

The light endpoint answers in 102 bytes; the tags one in 22,866 bytes, 224 times more, and it moves from 100 to 421 ms. The bytes do not explain the difference: at 1 Mbps, 22 KB travels in under 200 ms. The rest is server work, aggregating tags before it answers. The right question is not "how do I compress better", it is "why is this response built on every request".

The limitation to name

The numbers come from one network at one moment: latency to the server changes with the client position, and a CDN in front of the API moves the DNS and TLS phases to an edge. A burst of requests also returned 429: with a rate limiter in place, latency includes its decision, so measure at the same frequency the real client uses.

Where to continue

The EneUI catalogue indexes 111,985 components, 1,556 blocks and the brand speedtest icon, useful to give the latency panel a face. For the metric that contains this one, read TTFB: what it measures; to remove the first handshake, preconnect and dns-prefetch; for the weight of the bytes, Brotli against gzip; and for the comparison between architectures, frontend frameworks compared.