When a website loads slowly, it’s not always clear what’s to blame. Is it the DNS provider? The server itself? Or something in between? To help web professionals pinpoint where delays occur, I’ve published this tool on this site that measures the full lifecycle of an HTTP request, from domain resolution to content delivery.
This browser-based tool uses server-side diagnostics to simulate a real-world HTTP request and break down its timing components. It can be helpful whether you’re auditing your domain, troubleshooting a slow-loading partner API, or just benchmarking CDN performance across URLs.
Use the tool below to analyze the performance of any public-facing URL:
How to Read the Results
When you run a test, the tool executes a live cURL request and reports detailed timing information in seconds. Here’s what each of the reported metrics means:
- DNS Lookup Time: This refers to the time it takes to resolve a domain name to its corresponding IP address. If this number is high, it may indicate slow name servers, DNS propagation issues, or poor performance from the DNS provider. Google recommends keeping this under 50ms, with anything over 100ms considered a potential bottleneck.
- TCP Connect Time: This measures how long it takes to establish a TCP connection with the server. Delays here could point to network latency, firewalls, or distance to the origin server. Values under 100ms are preferred; consistent times above 150ms may indicate network or routing inefficiencies.
- TLS Handshake Time (HTTPS only): If the request is made over HTTPS, this number reflects the time spent negotiating the secure connection. Outdated cipher suites, expired certificates, or overloaded edge servers can cause a long TLS handshake. Google considers anything under 100ms optimal, while over 200ms could be symptomatic of security or performance misconfigurations.
- Pre-transfer Time: This includes DNS, TCP, and TLS—everything that happens before the actual request is sent. It reflects the cumulative startup time before the server begins processing the request. Ideal pre-transfer times fall between 100–300ms; anything beyond 400ms should be investigated phase by phase.
- Time to First Byte (TTFB): This metric measures the time it takes for the server to start sending a response after the request is received. A high TTFB can indicate server-side delays such as slow database queries, uncached dynamic content, or poor server performance. Google’s guidance is to keep TTFB under 200ms; persistent values over 500ms suggest backend or infrastructure issues.
- Total Transfer Time: This is the complete duration from the start of the request until the final byte is received. If your TTFB is fast but the total time is slow, it may be due to response size, server throttling, or content delivery delays. Aim for under 500ms for HTML payloads on broadband; over 1 second may indicate uncompressed assets or inefficient delivery.
- HTTP Status Code: This is the response code returned by the server (e.g., 200 for success, 301/302 for redirects, 404 for not found). It gives context for how the server handled the request.
This tool doesn’t just simulate a request—it executes it live on my server using PHP’s cURL library. That means you’re seeing what the server sees, not just what your browser perceives. It’s handy for debugging performance issues that may not be visible from your local network.
Try the tool and feel free to test a variety of URLs—your homepage, a specific API endpoint, or a remote resource you rely on. The deeper your understanding of these timing metrics, the faster you’ll be able to diagnose and improve your web performance.
Related Martech Zone Content
