// LATENCY TEST
Latency test
Measures round-trip time to your server with real requests. One vantage point today — the location is shown with every result, and more regions are planned.
What this measures
Round-trip latency between our server and yours: the fixed travel cost every request pays before any page code runs. We take five timed round trips — the first pays the full TCP + TLS setup, the rest reuse the connection — over HTTP rather than ICMP ping (which is usually blocked and does not reflect what browsers actually do), and report the minimum, the average, jitter, and a phase breakdown of the first connection.
How to read your result
- Good — under 100 ms
- The network path is not the problem at this distance. 100–300 ms is acceptable; above 300 ms every request carries a noticeable delay before your server even starts working.
- Minimum vs average
- The minimum is the cleanest sample — close to the pure network travel time to your server. An average well above the minimum means individual requests are getting delayed by queuing or load rather than by distance.
- Jitter
- How much the repeat samples vary (10 ms or less is stable; over 30 ms is erratic). High jitter with a good average means unpredictable performance — some visitors' requests hit delays that the average hides.
- The first-sample breakdown
- The first connection pays DNS, TCP, and TLS setup costs that the four warm samples skip. Its phase bar shows what a brand-new visitor pays before the first request even starts — several round trips stacked, which is why distance multiplies.
- One location, possibly one edge
- We measure from a single location, named next to the result. If your site is behind a CDN we detect and name it — the number is then the distance to the CDN's nearest edge, not to your origin server, and visitors elsewhere will hit their own nearest edge.
Common causes & fixes
- High but stable latency
- Latency that is high with low jitter is distance — signals cannot travel faster, so no server upgrade fixes it. A CDN cuts it by answering from an edge near each visitor instead of one faraway origin.
- High jitter
- Erratic samples point at congestion or load: an oversubscribed shared host, a saturated network link, or a server juggling too much. If it persists across runs, the fix is capacity — better hosting — rather than geography.
- Only the first sample is slow
- Setup cost, not steady-state latency: DNS plus the TCP and TLS handshakes. Enabling TLS 1.3 and keep-alive trims it, and a CDN terminates those handshakes close to the visitor so the round trips are short ones.
- Latency is fine but pages are slow
- The path to the server is fast, so the wait is the server itself or the page. Run the TTFB test to time the server's processing, or the speed test to profile the page.
Frequently asked questions
Why not a real ICMP ping?
ICMP is widely blocked or deprioritized, and it measures a path browsers never use. A TCP + TLS round trip is what an actual HTTPS visit performs, so this number reflects what real visitors pay — typically slightly higher than an ICMP figure for the same route.
What is a good latency?
Under 100 ms from our vantage point is good; up to 300 ms is acceptable. For visitors near your server it can be far lower. Remember a page load spends many round trips — handshakes, requests, redirects — so latency compounds well beyond the single number shown.
Why is my own ping to the site different?
Latency is a property of the path between two specific points. We measure from our server's location (shown with the result); you measure from yours. Both are real — a visitor's latency depends on where they are.
Does jitter matter if the average is good?
Yes. Jitter is variance — with high jitter, a slice of requests is much slower than the average suggests, which visitors feel as intermittent sluggishness. A stable 80 ms usually feels better than an erratic 60 ms.
Related guides