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.
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.
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.
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.
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.
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.
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.
©2025 DK New Media, LLC, All rights reserved | DisclosureOriginally Published on Martech Zone: App: Measure Your Website’s Response Time with This Simple Metrics Tool