DNS lookup
Time spent resolving the hostname before a connection can begin. Resolver location, cache state and CNAME chains can affect it.
HTTP performance tools
HTTP Response & Timing Analyzer
The website is reachable—but where is the delay? Measure DNS lookup, TCP connection, TLS negotiation, time to first byte, content transfer and redirect overhead from one controlled server-side request.
Stage-by-stage timingSeparate connection setup from server response and transfer time.
Redirect overheadSee the time added before the final URL responds.
Public targets onlyPrivate, local, reserved and unsafe redirect destinations are blocked.
Analyze a public website
Use GET for a complete transfer measurement or HEAD for headers without downloading the response body.
Run an analysis to see the response summary, timing waterfall and areas to investigate.
HTTP response & timing
Summary of the final response and complete request path.
Timing breakdown
Each phase is measured from the Netest server. Redirected request stages are included in the totals.
Request timeline
TTFB qualification: Time to first byte can include network latency plus CDN, WAF, reverse-proxy, application and backend processing. A remote test cannot assign it to one component.
Response details
Protocol, TLS and content metadata reported by the final response when available.
Redirect chain
Each measured response, including the final destination. No-follow mode shows only the first response.
Interpretation
Use the largest phase as a starting point for investigation, not as a remote root-cause verdict.
How to use the HTTP timing analyzer
- Enter a public domain or full HTTP/HTTPS URL, including a path or query string when needed.
- Choose GET to measure content transfer or HEAD to request headers without downloading a body.
- Keep redirect following enabled to measure the final destination, or disable it to inspect only the first response.
- Compare the breakdown, waterfall and redirect overhead, then repeat the test to account for normal network variation.
What each timing means
TCP connection
Time to establish the TCP session after resolution. Distance, packet loss, congestion and path latency can contribute, but one result does not prove a network fault.
TLS handshake
For HTTPS, time spent negotiating encryption after TCP connects. TLS termination may occur at a CDN, WAF, proxy or load balancer.
Time to first byte
Time from connection readiness until the first response byte. It combines transport effects with any edge, proxy, application and backend processing.
Content transfer
Time from the first response byte until the measured body completes or reaches the 2 MB safety limit. HEAD normally reports no transfer.
Total request time
Wall-clock time across DNS, connection, TLS, response wait, transfer and any redirects followed by the analyzer.
Practical examples
example.comchecks the HTTPS home page after automatic normalization.http://example.comreveals whether an HTTP-to-HTTPS redirect adds another request.https://example.com/loginmeasures a specific public route without cookies or authentication.https://api.example.com/v1/statuschecks a public API status endpoint with GET or HEAD.
Limitations, privacy and responsible use
Results are measured from the Netest server, not from your browser or network. They can differ because of CDN geography, DNS resolver location, anycast routing, WAF behavior, server load, connection reuse, browser caching, HTTP/3, authentication, cookies and client location.
The analyzer sends a clean request without user-supplied Authorization or Cookie headers, follows at most five redirects, allows only public Internet destinations on standard web ports, stops after 10 seconds and limits downloaded content to 2 MB. Every redirect hostname is resolved and validated again.
Use this tool only with public websites you are authorized to test. It performs one bounded request and is not a load test, vulnerability scanner or substitute for application performance monitoring.
HTTP response timing FAQ
Does high TTFB prove the backend is slow?
No. TTFB may include network latency and processing by a CDN, WAF, proxy, load balancer, application, upstream API or database.
Why does the browser show a different time?
Browsers may reuse connections, cache DNS and content, negotiate HTTP/3, send cookies and use a different geographic path.
When should I use HEAD?
Use HEAD when you want status and connection timing without transferring the body. Some servers handle HEAD differently, so GET is the better end-user comparison.
Are redirects included?
Yes when redirect following is enabled. The totals include each followed request and the chain reports redirect overhead separately.
Can it test an intranet site?
No. Local, private, reserved, multicast, link-local and metadata destinations are blocked, including destinations reached through redirects.
Does one result represent normal performance?
No. Repeat measurements and compare regions because DNS cache state, load and Internet routing vary between requests.