HTTP Latency
Send N HTTP HEAD requests to a URL and report min/median/mean/max/stddev latency. From this server's vantage.
Single-vantage measurement (from our droplet). Multi-region scoring requires worker deployments in multiple regions and is deferred to a follow-up tool.
Monitor this automatically
NetTests can run this check on a schedule, preserve historical results, compare changes over time, and alert you the moment something breaks.
Start monitoring free → See all monitoring productsFrequently Asked Questions
What does this tool measure?
It sends multiple HTTP HEAD requests to a URL from our server and reports the round-trip time (RTT) for each. The summary shows minimum, median, mean, maximum, and standard deviation latency. HEAD requests fetch only headers — no body — so the result reflects pure connection + server response time, not download speed.
What causes high latency?
Common causes: geographic distance between our server and yours (speed of light sets a floor), slow DNS resolution, TLS handshake overhead, server-side processing time (slow database queries, no caching), network congestion or routing issues. High standard deviation indicates inconsistent response times, often caused by intermittent server load or variable routing.
How is this different from a ping?
Ping measures ICMP echo RTT at the network layer — it doesn't involve HTTP or TLS. This tool measures end-to-end HTTP latency including TCP handshake, TLS negotiation, and server response time — what a real browser or API client actually experiences. Ping can be fast while HTTP is slow if the server is responding to ICMP but slow to process HTTP requests.
What is a good latency target?
For web pages: under 200 ms median is good; under 100 ms is excellent. For APIs: under 50 ms median is typical for well-optimised services on the same continent. Geographic distance alone adds ~67 ms per 20,000 km (speed of light in fibre). Use a CDN to serve responses from edge nodes close to your users.