HTTP Latency Test
Measure round-trip latency and jitter from your browser to any HTTPS endpoint - the closest a browser can get to ping.
Result
About HTTP Latency Test
Browsers cannot send ICMP, so a real ping is impossible from a web page. What you can measure precisely is HTTPS request round-trip time, which includes the same network path plus TLS and server handling. For comparing endpoints, watching jitter or proving a link is degraded, it is more than good enough.
What is actually being measured
Each sample covers DNS (cached after the first), TCP handshake or connection reuse, TLS resumption, the request, server processing and the response. Connection reuse means later samples are usually much faster than the first - that first sample is your connection setup cost, and it is worth noticing separately.
Latency budgets that matter
Under 40 ms feels instant. Voice stays comfortable to about 150 ms one-way (ITU-T G.114). Interactive SSH becomes annoying past 200 ms. Jitter matters more than absolute latency for real-time media: a stable 120 ms is far better than an average of 60 ms that swings by 80.
Common use cases
- Comparing latency to several providers or regions from a user location.
- Demonstrating that a link is jittery when a user reports "the internet is slow".
- Sanity-checking a CDN or edge deployment is serving from a nearby POP.
Edge cases and gotchas
- Results include server-side processing time and cannot be compared directly with ICMP ping figures.
- Cross-origin responses are opaque, so failures cannot be distinguished from CORS rejections - a target that returns all failures may still be up.
- Browser connection pooling, HTTP/3 and proxies all shift the numbers. Use the same target when comparing over time.