How GlobeLatency Measures Latency From Your Browser

Quick answer: GlobeLatency measures how long a real HTTPS request takes to travel from your browser to a public server and for the response headers to start coming back. It repeats the request several times per destination, averages the successful passes, and compares your result with the global average for the same destination. It does not use ICMP ping, because web browsers are not allowed to send ICMP, and because HTTPS timing is closer to what real websites and apps experience.

The measurement in one sentence

For every destination, the page calls the browser fetch() function with a unique address, starts a timer, and stops the timer when the response headers arrive. The elapsed time in milliseconds is one reading. Several readings of the same destination are called passes. Everything else you see in the tool (average, best, worst, percentiles, colours, verdicts) is calculated from those readings.

What exactly is timed?

A single timed request can include several steps, depending on whether your browser already has an open connection to that server:

Step	Included in a first request?	Included when a connection is reused?
DNS lookup of the hostname	Usually yes (unless cached by your OS or browser)	No
TCP connection setup (one round trip)	Yes	No
TLS handshake (one or two round trips, fewer with resumption)	Yes	No
Sending the request and server processing	Yes	Yes
Time until the first bytes of the response arrive	Yes	Yes

This is why GlobeLatency reports an application-level round-trip time. It is the number a person using a website would feel, not the number a network engineer would get from a bare ping. For the full comparison read Ping vs HTTPS latency; for how the pieces add up see TLS and the HTTPS handshake and DNS explained.

Why a no-cors fetch?

Websites normally cannot read responses from other domains unless those domains allow it. The Fetch API has a no-cors mode that sends the request anyway but gives the page an "opaque" response: no body, no status code, no headers. For latency this is perfect, because the only thing needed is when the response arrived. It means GlobeLatency can measure thousands of public servers without any cooperation from them.

The trade-off is that a server answering with an error still counts as a reply. A 404 Not Found arrives just as quickly as a 200 OK, so the tool measures reachability and speed, not correctness. A connection that cannot be made at all (server offline, blocked by firewall, TLS failure) produces no reply.

Cache-busting: why every request is unique

If a browser answered from its own cache, the "latency" would be near zero and meaningless. To prevent this, every request URL gets a unique query string (a random value and a timestamp), and the request is sent with cache: no-store. Intermediate caches see a new URL each time and have nothing to serve. CDNs may still answer from their edge, which is exactly what you want to measure for a CDN destination.

Cache-busting does not stop connection reuse. Your browser may keep the TCP and TLS connection open between passes, which makes pass 2 and 3 cheaper than pass 1. That is realistic: real browsing reuses connections too.

Which servers are measured?

Destinations are public servers in many regions, grouped into categories such as cloud providers, CDNs, gaming platforms, DNS and public services. Each is a small public URL, often a favicon or other small static file, so the response is quick and the number reflects the network rather than a heavy page. You can also add your own hosts; see Destinations and custom hosts.

Passes, concurrency and timeouts

• Passes per destination: 1 to 20, default 3. More passes give a steadier average and make percentiles meaningful.
• Concurrency: up to three destinations are measured at the same time. Each destination is still measured one pass after another so passes do not compete with each other.
• Timeout: a single request is abandoned after 10 seconds in Test mode. In the live Map and Monitor modes the default is 5 seconds and can be changed.

Running three requests at once keeps a full test short without flooding your connection. If you have a very slow link, the concurrent requests can slightly inflate each other; running fewer destinations gives the cleanest result.

From readings to numbers on screen

For each destination, GlobeLatency shows:

• Average: the mean of all successful passes. Failed passes are not included.
• Best: the lowest pass, the closest estimate of the path's floor.
• Worst: the highest pass, a hint about spikes and instability.
• p95 and p99: nearest-rank percentiles of the passes. With only three passes they equal the worst pass; they become meaningful with many passes. See percentiles explained.

Then each average is compared with the world average for that same destination to colour it and produce a verdict. That comparison is covered in The world comparison explained.

Three modes, one engine of ideas

Test runs once, saves a report you can share, and keeps your history in the browser. Map and Monitor run continuously: they re-measure every selected destination at a fixed interval and keep the last 60 readings in your browser. Nothing from the live modes is sent to the server. Learn more in the live map guide and monitor guide.

What GlobeLatency does not measure

• It does not measure download or upload speed. For that difference see latency vs bandwidth vs throughput.
• It does not measure one-way delay or the exact hop-by-hop path (traceroute does that).
• It does not read server status codes or page content.
• It cannot remove the cost of your own browser, operating system, Wi-Fi or extensions. See Accuracy and limitations.

Worked example

You test a destination with 5 passes and get 48, 41, 43, 120 and 44 ms. The average is (48 + 41 + 43 + 120 + 44) / 5 = 59.2 ms. The best pass is 41 ms and the worst is 120 ms. Because 120 is more than 2 times the average but less than 3 times, no "Unstable" flag is raised; at 3 times the average (here about 178 ms) it would be. If the world average for that destination is 52 ms, your ratio is 59.2 / 52 = 1.14, which falls in the "good" band. The one slow pass raised your average, so looking at the best value tells you what the path can do when nothing interferes.

Common mistakes and myths

• "The number should match my ping." It will usually be higher, because HTTPS includes more steps. Compare HTTPS numbers with HTTPS numbers.
• "One run is the truth." A single run is a snapshot. Run it again at another time of day, or use Monitor for a longer view.
• "A red tile means my internet is broken." It means that destination is slower for you than for the typical visitor. See Reading your results.

What to do next

Ready to try it? Run a latency test, then read Running a test for every option, and Reading your results to interpret what you see.