Latency & Jitter Test

Pressing Start sends twenty requests to a small file on this site, one after another with a short gap between them, and times each one from the moment the browser starts the request to the moment the reply is complete. Each carries a fresh query string so it can never be served from cache, which would otherwise make the numbers meaninglessly small.

What is being measured is a full HTTPS round trip. That includes finding the server, opening a connection, the server reading the request and sending the file back, and the return journey to you. Every one of those stages is real work, and collectively they are what a page experiences when it loads anything. The first sample is almost always the slowest because it also pays for DNS resolution and the TLS handshake; the other nineteen reuse the open connection and measure something closer to the raw trip.

The three figures at the top tell different parts of the story. Minimum is the best the connection managed, usually the closest thing to the real trip time once everything is warm. Median is the middle value, which is more useful than the average because a single slow request cannot drag it around. Maximum is the worst case, and on a busy line it is often several times the minimum.

Distance sets a hard floor. Light in fibre travels at roughly 200,000 kilometres per second, so a round trip to a server 1,000 km away cannot take less than about 10 ms no matter how good the equipment is, and real routes wander further than the straight line. That is why a nearby server and a distant one can differ by tens of milliseconds with nothing wrong at either end.

Where the browser reports a network estimate of its own, the connection info test shows it alongside this measurement for comparison. The two often disagree, because one is a passive estimate and the other is an actual timed request.

The word ping has come to mean any round-trip measurement, but the original tool is specific. Ping sends an ICMP echo request at the network layer and times the echo reply. That happens below HTTP, below TCP, with no connection to establish and no handshake to complete. It is the cleanest measure of how long the network takes to carry something to a host and back.

A web page cannot do that. Browsers deliberately expose no raw socket or ICMP interface, because a page that could send arbitrary network packets would be a security problem. The closest a page can get is an HTTP request, which is why every browser-based latency test measures an HTTPS round trip instead.

The practical difference is overhead. A full request adds connection management, TLS records, the server’s own processing and the response body transfer on top of the raw trip. A conventional ping to the same host would typically report a somewhat lower number. That does not make this reading wrong, it makes it a different quantity: the time for a real web interaction rather than for a bare packet. If you want to know how the connection feels in practice, this is the more relevant figure.

A steady 60 ms and a connection that swings between 20 and 140 ms can share the same average, and they feel completely different. The first is fine for a call. The second produces clipped words and stuttering video, because real-time software has to play audio on a fixed clock: when a packet arrives late, it has either already been skipped or everything behind it has to wait.

That is what the jitter figure measures. It takes each pair of consecutive samples, works out how far apart they were, and averages those gaps. A low number means every request came back in about the same time. A high number means the connection is uneven, and the bar strip above makes that visible at a glance: a jagged profile with one tall bar is jitter, while a flat profile is a steady line.

Jitter usually comes from congestion, an overloaded Wi-Fi channel, or a router whose buffer fills up under load. It is a property of the path, not of the server, so it appears whatever you are measuring against.

The largest factor is distance, and it is the one you cannot change. The second is the medium: a wired connection is normally steadier than Wi-Fi, and a weak Wi-Fi signal adds retries that show up as jitter long before they show up as lower throughput. Moving closer to the router, or switching to a cable, often helps more than any setting.

A VPN adds a hop by design. Your traffic goes to the VPN server, is decrypted, and travels on to the destination, so the path is longer than it would be direct. If the exit server is far away, the added milliseconds can be substantial. There is no way to remove that cost while the tunnel is on; the trade is privacy against speed.

Tools like the connection info test show the browser’s own estimate of round-trip time, and the HTTP headers test shows what your browser attaches to each request. Neither changes the measurement above, but together they describe the connection this page is measuring.