Network Latency Test

What a run does

1. 01

   One warm-up request

   It isn't counted, so the first request has already gone through before anything is measured.

2. 02

   Ten timed requests

   Each one is a tiny request to /api/ping on this site, which answers with an empty response. The page notes the time before sending and after the reply arrives, using performance.now(). That gap is the round-trip time (RTT).

3. 03

   Short pauses in between

   About 0.3 seconds separate the samples, each request has a 5-second timeout and nothing is retried. Every request carries a unique parameter and asks the browser not to cache, so a cache can't answer instead of the server.

4. 04

   A result or an error

   It needs at least five valid samples to show numbers. After three failures in a row the run stops instead of waiting for eleven timeouts.

Reading the numbers

The page adds a rough label that applies to this server only: under 50 ms is low, 50 to 150 ms is moderate and over 150 ms is higher. Those are guide values, not a standard and not a verdict on your connection.

Why jitter matters: a worked example

Two invented runs show why the average alone isn't enough. To keep the arithmetic short they use five samples instead of ten. Run A gives 20, 22, 21, 23 and 20 ms. Run B gives 5, 40, 8, 45 and 8 ms. Both average 21.2 ms.

Jitter is the average of the absolute differences between one sample and the next. In run A those differences are 2, 1, 2 and 3 ms, so the jitter is 8 ÷ 4 = 2.0 ms. In run B they are 35, 32, 37 and 37 ms, so the jitter is 141 ÷ 4 = 35.25 ms. Both runs would carry the same “low” label for the average, but run B was far less steady, and that is exactly what the jitter figure is there to show. The guide on latency and jitter goes further: what round-trip time is, how it differs from bandwidth, what exactly this test measures and how to compare runs by their variability rather than by the average alone.

Why your number can differ from other tools or games

• It isn't an ICMP ping. It times an HTTP request made through the browser, so browser, HTTP and server processing time are inside the figure.
• It measures the route to this one server, whose location you can't choose. A game server, a video service or another test site sits somewhere else and will give a different number.
• Wi-Fi versus cable, a VPN or proxy, other downloads or streams on the network and how busy the line is can all change the result from one run to the next.
• Failed requests are shown, but this isn't a packet-loss test: they mean a request didn't complete in time, not that a certain number of packets were lost.

What this test can't tell you

It isn't an Internet speed test and doesn't measure download or upload speed. It doesn't measure your general Internet latency, your provider or any server other than this one, and it can't show where along the route a delay appears. The guide on what browser tests can and can't measure covers the same limits for every tool. TryYourGear doesn't store the results; as with any web request, the hosting provider may keep technical logs of it.

What to do next

Run it two or three times, ideally at different moments, and compare a cable with Wi-Fi if you can, pausing large downloads and any VPN while you test. A steady result with low jitter matters more than one very low number. For a real speed figure, use a dedicated speed test, and for game or call performance, check the ping shown by that game or service. The latency you feel in a game also includes your display and input, which the Refresh Rate Test and the Reaction Time Test look at.