Latency Test Accuracy: Browser Limits & How to Get Good Data

Quick answer: GlobeLatency gives you a realistic picture of what a user in your browser experiences, with an accuracy of a few milliseconds under good conditions. It is not a laboratory instrument. Everything between your browser and the server affects the number, including things inside your own device. To get a clean reading, use a cable or a strong Wi-Fi signal, keep the tab in front, pause heavy traffic, run more than one pass, and compare results measured the same way.

What "accurate" means here

There are two different questions. First: does the tool measure the thing it claims to measure? Yes, it times real HTTPS requests. Second: does the number equal the physical network delay? No, and it is not meant to. It is the experience-level latency, which includes software layers. For real use, such as browsing, APIs and cloud apps, that is the relevant number. For network engineering you may also want ICMP ping, traceroute or mtr; see ping vs HTTPS latency.

Sources of extra delay or variation

Factor	Effect	What you can do
Wi-Fi quality and distance	Adds milliseconds and random spikes	Move closer, use 5 GHz, or use a cable
Busy network (downloads, video, backups)	Queueing delay on every request	Pause traffic; see bufferbloat
VPN or corporate proxy	Extra hops, encryption, possibly distant exit	Test with and without
Browser extensions (ad blockers, security tools)	Intercept or inspect requests	Test in a clean window or private mode
Antivirus or firewall web shields	Inspect HTTPS traffic	Compare with them off if safe
Background tab	Timers throttled by the browser	Keep the tab visible
Weak device or many tabs	Delayed handling of responses	Close heavy tabs; use a desktop for tests
Mobile signal and handovers	Variable and sometimes high latency	Test at several moments; note signal bars
Time of day	Evening congestion	Repeat at a different time
Server load at the destination	Slower response	Compare several destinations

Connection reuse and the first pass

The first request to a server often includes DNS and the TCP and TLS handshakes. Later passes may reuse the open connection and skip them. That is why, in a multi-pass test, the first pass can be higher than the rest. Neither is "wrong": the first is a cold start, later ones are warm. The best value approaches a warm connection; the average includes the cold start if it was slower. See TLS and the HTTPS handshake.

Anycast and CDNs

For anycast services (many large CDNs and DNS providers), the same address is announced from many locations. You reach the nearest or best-routed one. Therefore a result to a CDN destination measures latency to your closest edge, which can be very low, and the pin on the map shows where that address was located in the geolocation database. It says little about the origin server behind the CDN. See CDNs and anycast.

What the tool cannot see

• Status codes and content: the no-cors mode hides them, so a server returning an error still produces a timing.
• The path: there is no hop-by-hop information. A traceroute is the right tool for that.
• One-way delay: only round trip is measured.
• Throughput: this is a latency tool, not a download or upload speed test. See latency vs bandwidth.
• Packet loss as a percentage of packets: only whether each request replied. The no-reply rate in Monitor is a rough indicator, not a measure of packet loss.

Statistical accuracy: how many passes?

The average of three passes is a rough estimate. With five to ten passes it stabilises, and with 20 passes the 95th percentile becomes meaningful. A single outlier pass can drag a three-pass average by 30% or more. When precision matters, increase passes, look at best and worst, and repeat the test at different times. See mean, median, min and max.

How the world comparison affects accuracy

The world average comes from visitors of the site, mixed across connection types and regions. It is a useful yardstick, not a scientific benchmark. If you are on a satellite link or in a remote area, expect to be slower than the world average on most destinations, and that is an accurate observation about your link. See The world comparison explained.

Checklist for a clean measurement

1. Close heavy tabs and pause downloads, cloud sync and streaming.
2. Use a wired connection if possible, otherwise sit near the router.
3. Keep the GlobeLatency tab visible during the run.
4. Disable VPN and proxy for a baseline, then enable for comparison.
5. Use at least 5 passes; 10 or more if you suspect instability.
6. Repeat at another time of day.
7. Save the report link for comparison.

Worked example: Wi-Fi vs cable

On Wi-Fi, a 10-pass test to a nearby server gives average 31 ms, best 14 ms, worst 96 ms. Connected by cable, the same test gives average 16 ms, best 13 ms, worst 21 ms. The best values are almost the same, which tells you the path itself is fine; the difference is in the stability of the wireless hop. A comparison of best values reveals the floor, and a comparison of worst values reveals the instability.

Common mistakes and myths

• "Different tools must give identical numbers." They measure different layers.
• "A single high pass invalidates the test." It is real data; look at percentiles and the pattern.
• "Lower than ping is impossible." It is rare, but an HTTPS request served by a very close edge can look similar to ICMP to a farther router.

What to do next

If a result looks wrong, use Troubleshooting GlobeLatency. To improve real latency, read how to reduce latency. Or run another test with more passes.