Response Time Test

Response Time Test reports how long, in milliseconds (ms), a server takes to answer a GET request to the URL you enter. Our server makes a real HTTP request to the address and measures the time to the first response, so you can see at a glance whether the site responds snappily.

The result is graded as fast under 300ms, average from 300 to 800ms, and slow above 800ms. The status code and redirect count shown alongside help you tell whether a slow response comes from server processing delay or from unnecessary redirects.

What TTFB and server response time are

TTFB (Time To First Byte) is the time between sending a request and receiving the first byte of the response. It includes DNS lookup, TCP/TLS connection, and the time the server spends processing the request and producing a response. A high TTFB makes users wait before anything renders, affecting both perceived speed and search rankings.

• Server processing: dynamic page generation, database queries, slow external API calls
• Connection cost: DNS resolution, the TLS handshake, and round-trip time (RTT) to a distant data center
• Redirects: each extra 301/302 adds another round trip

How to read the measurement

This tool reports a single measurement for one GET request. Even for the same site, results can fluctuate with server location, cache hits, and momentary traffic, so measure a few times to see the overall trend. If responses are slow, start by checking CDN caching, removing unnecessary redirects, and optimizing server-side rendering. To cut transfer size itself, check whether gzip/brotli is on with the compression check, and whether the page is heavy with the page weight analyzer.

Response time grades and target thresholds

Google's published guidance treats a TTFB at or under 200msas good. This tool's grades (fast/average/slow) are based on the full response time including DNS, TLS, and round trips, so they read a little higher than pure server-processing TTFB — that is expected. Use the table below to see which band your measurement falls into.

A worked example

Say you enter http://example.com and get a response time of 740ms, status code 301, and a redirect count of 2. Here the 740ms is not one request — it is the time accumulated across two hops, an http → https redirect and a wwwnormalization. If one round trip is roughly 120ms, the actual content response is around 500ms and the rest leaked into redirect round trips. Enter the final URL (https://www.example.com) from the start and the same server typically returns 200–300ms faster — that gap is exactly what users feel when you trim redirects.

Common pitfall

• Treating a single measurement as your site's verdict — the first hit can be unusually slow due to a cold cache or cold start, so read the steady value after 2–3 retries (the same URL is cached for 30 seconds).
• Mistaking this number for the page load time users see — it measures only the first HTML response (a TTFB-style metric); it does not include downloading images, CSS, and JS, or rendering.
• Ignoring the measurement vantage point — it is taken from our data center, so a distant target reads slower and may differ from what your real users experience.