Response Timing measures how long an HTTP request to a URL takes, splitting out the DNS lookup, the time-to-first-byte (TTFB) and the full request duration so you can see where time is spent loading a URL.
Enter a full URL (https://example.org) and run the tool. The probe performs a full request and records the duration of each phase.
Input: URL — e.g. https://example.org.
The output shows the time spent in DNS resolution, the time-to-first-byte (how long until the server started responding), the full request duration, the HTTP status and the response size in bytes. A high DNS time points to resolver issues; a high TTFB points to slow origin processing; a large gap between TTFB and the full request points to a large or slow response body.
→ Find which request phase is slowing down a page load.
→ Measure origin TTFB separately from CDN edge time.
→ Compare IPv4 vs IPv6 connection performance.
→ Verify a performance optimisation actually reduced TTFB.
Under 200 ms is excellent, 200–500 ms is acceptable, and over 500 ms is slow for most sites. TTFB behind a CDN should be very low (the edge serves cached content); a high TTFB from the edge means the origin is slow or the content is uncached.
Cache dynamic content at the CDN, optimise database queries and application code, use HTTP/2 or HTTP/3 and connection reuse, and ensure the origin has enough resources. Each phase in this tool’s output tells you where the time is actually going.
It includes the cold resolver lookup. Subsequent requests reuse the cached answer, so a single high DNS time is normal on first load. Persistently high DNS time points to a slow resolver — try a faster public resolver like 1.1.1.1 or 8.8.8.8.