We request the URL from our server with HEAD when supported (GET fallback on 405/501), follow up to 10 redirects with the same safety rules as our other URL tools, and stop after a small header/body read. Private and internal targets are blocked.
Compathub’s server requests the public URL you enter (HTTPS is assumed if you omit the scheme), follows up to ten redirects with the same safety rules as our other URL tools, and measures how long the scan takes. We prefer a lightweight HEAD request when the server allows it; on 405 or 501 we retry with a capped GET so timing still reflects a real HTTP response without downloading a full page.
The report shows total elapsed time in milliseconds, the final HTTP status code, original and final URLs, redirect count, protocol, and how many response bytes we read (headers plus a small body cap on GET). This is useful when you want a quick server-side latency snapshot after DNS or CDN changes, before deeper audits, or when a URL feels slow but you are not sure whether redirects or the origin is adding delay.
| Field | What it represents |
|---|---|
| Total elapsed | Wall-clock time for the whole scan: DNS on each hop, redirect handling, and the final request until response headers arrive (plus a capped body read when GET is used). |
| DNS lookup (all hops) | Sum of time spent resolving hostnames during the scan. Each redirect to a new host adds another lookup interval. |
| Time to response headers (final hop) | On the last request only: from sending the HTTP request until response headers are received. Includes TCP setup, TLS on HTTPS, and server processing on that hop. |
| TCP / TLS phases | Not reported separately. Splitting those phases would weaken our pinned-IP SSRF protections, so the UI shows Not measured instead of estimated values. |
| Bytes read | Approximate header size plus body bytes read (body is capped). Useful to see whether a GET fallback returned a large payload prefix. |
All timings are measured from Compathub infrastructure, not from your browser or office network. Results vary with geography, caching, CDN routing, and server load.
2xx means the final response completed successfully for this request. 4xx and 5xx mean the server returned an error or rejection for the URL tested; the scan can still finish and show timings. Use the Redirect Checker if you need each redirect hop listed separately.
Each redirect to a new hostname triggers another DNS lookup; that time is included in DNS lookup (all hops) and in Total elapsed. Confirm nameservers and records with DNS Lookup when you change hosting or CDN.
After a migration. Compare total elapsed time on the new canonical URL versus an old redirecting hostname.
CDN or DNS cutover. See whether extra redirect hops or slow DNS on a new name shows up in total elapsed time.
Incident triage. Confirm whether a URL still returns 200 from our server or fails with timeout or connection errors.
Before a deep scan. Pair with the Redirect Checker when you need hop-by-hop status codes, or the Website Stack Checker when you need headers and HTML signatures on the final response.
Do you store my URL? Results are not shared between visitors; see the on-page note and Privacy Policy for server-side handling.
Can I scan localhost or internal IPs? No. Private ranges, metadata hosts and blocked hostnames are rejected, including on redirect targets.
Why no separate TCP or TLS timings? Accurate phase splits would conflict with connecting only to validated public addresses. We report only intervals we can measure safely.
Does a non-200 status mean failure? The check can complete successfully while reporting 404, 403 or other terminal codes. Errors mean we could not finish the scan (timeout, DNS failure, blocked target, and similar).
Why is bytes read smaller than my page? We cap headers and body bytes to keep scans lightweight. The figure is what we read for timing, not the full download size of the page.
Can I compare results to Google PageSpeed? No. This tool measures server-side HTTP time from Compathub, not Core Web Vitals, rendering or asset waterfalls in a browser.
After latency looks reasonable on the final URL, review headers with the Security Headers Checker, confirm the certificate with the SSL Certificate Checker, map redirects with the Redirect Checker, and inspect stack clues with the Website Stack Checker.