HTTP Latency
Send N HyperText Transfer Protocol (HTTP) HEAD requests to a Uniform Resource Locator (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 HyperText Transfer Protocol (HTTP) HEAD requests to a Uniform Resource Locator (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 Domain Name System (DNS) resolution, Transport Layer Security (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 Internet Control Message Protocol (ICMP) echo round-trip time (RTT) at the network layer — it doesn't involve HyperText Transfer Protocol (HTTP) or Transport Layer Security (TLS). This tool measures end-to-end HTTP latency including Transmission Control Protocol (TCP) handshake, TLS negotiation, and server response time — what a real browser or Application Programming Interface (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 Application Programming Interfaces (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 Content Delivery Network (CDN) to serve responses from edge nodes close to your users.