A single timing result is tidy, persuasive, and usually incomplete. It hides the warm-up, the slow tail, and the route changes that users actually notice.
When I compare two paths, I begin by asking what the measurement includes. DNS lookup, connection setup, TLS negotiation, time to first byte, and transfer time describe different parts of the trip. Folding them into one number makes diagnosis harder.
Record the conditions
The same test can change with time of day, resolver, source network, cache state, payload size, and connection reuse. A useful note records those conditions beside the result. This does not make the test scientific, but it keeps later comparisons honest.
I prefer several short runs spread across a normal day to one large burst. The median describes the ordinary experience. A high percentile shows how unpleasant the slow requests become. Failure count belongs next to both; a fast route that occasionally disappears is not fast in practice.
Look for the outline
Plots help, but a small table is often enough. If most requests cluster tightly and a few are dramatically slower, investigate queueing, retransmission, or cold work. If the whole distribution moves together, the route or origin may have changed. If only the first request is slow, setup cost is the likely candidate.
The goal is not to produce the smallest number. It is to understand the outline well enough to predict what a person will experience on the next request.