Response Time Checker

Measure how fast a URL responds and see where the time goes. Enter an address and this tool fetches it and breaks the timing into phases — DNS lookup, TCP connect, TLS handshake, time to first byte and content download — with a visual breakdown. A single "load time" number hides the cause of slowness; the phase split shows whether the bottleneck is the network, the handshake, or the server itself.

How to use the Response Time Checker

Enter a URL and press Measure response time. The tool fetches the page and reports:

• The total response time as a headline, colour-coded (green under 300 ms, amber to 1 s, red beyond).
• A segmented bar and table splitting the time into DNS, TCP connect, TLS handshake, server processing (TTFB) and content download.
• The TTFB on its own, which is the clearest single signal of server-side speed.

The measurement is taken from our server, so the absolute numbers are not what a visitor in your city would see. What travels is the shape of the response: a high TTFB points at the application, a high download time points at a large or uncompressed body.

What the timing phases mean

Fetching a URL is not one event but a sequence, and each step takes measurable time. Splitting them apart is the only way to know what to fix:

• DNS lookup — translating the hostname into an IP address. Usually a few milliseconds; a slow result points at the DNS provider or a cold cache.
• TCP connect — establishing the connection to the server. Dominated by network round-trip time, so it grows with physical distance and on high-latency mobile links.
• TLS handshake — negotiating the encrypted HTTPS connection. Adds one or two extra round-trips on a fresh connection (zero for plain http).
• Time to first byte (TTFB) — the wait after the request is sent until the first byte of the response arrives. This is the server thinking: routing, application code, database queries, template rendering. It is the phase you most directly control.
• Content download — streaming the response body. Driven by how big the response is and how much bandwidth is available, which is why compression helps here.

The practical reading is straightforward. If TTFB dominates, the server is slow — look at backend code, database queries, caching, or an under-resourced host. If download dominates, the response is too heavy — enable compression and trim the payload. If connect and TLS dominate, the issue is network distance or a missing CDN, and moving content closer to users (an edge cache) is the fix. One number cannot tell you which of these is true; the breakdown can.

Common use cases

• Diagnosing a slow site — find whether the delay is the server (TTFB) or the payload (download).
• Benchmarking a backend change — measure TTFB before and after a caching or query optimisation.
• Comparing hosts or CDNs — see the connect and TLS phases to gauge network proximity.
• Spotting handshake overhead — check how much TLS negotiation adds on a cold connection.
• Validating compression — confirm a smaller body actually shortens the download phase.

What is a good TTFB?

Time to first byte is the metric most worth watching, because it isolates server speed from network and payload effects. As a rough guide, measured close to the server:

• Under 200 ms — excellent. The application and any caching are doing their job.
• 200-600 ms — acceptable for dynamic pages, but worth investigating if it is the norm.
• Over 600 ms — slow. Common causes are uncached database queries, heavy server-side rendering, an overloaded host, or a cold serverless function.

Because this tool measures from our server rather than a visitor's device, treat the numbers as relative. Use them to compare before/after a change or to compare two URLs, and rely on the phase breakdown rather than the raw total to decide what to fix. For a real-user view you would combine this with field data from your analytics.