HTTP response and ping reference test
Explore how this site’s HTTP responses vary when it feels slow. Sequential, body-free HEAD requests target the same-origin /favicon.ico, with the first three kept as warmups. Read the distribution, failed requests and differences between consecutive successes instead of relying on one minimum.
Key features
- Fixed same-origin HEAD requests with no cache-busting query
- Three excluded warmups followed by 5,10 or 20 measurements
- Mean, minimum, maximum, median, P95 and consecutive-success jitter
- Separate HTTP errors, network errors and three-second timeouts
- Canvas trend, complete request table and CSV export
- First-request Resource Timing, reference bands, use cases and Windows ping notes
How to use
- Read the HTTP scope and choose the measured-request count.
- Start to send three warmups followed by sequential measurements.
- Cancel or press Escape to stop; hidden tabs and offline events stop automatically.
- Compare completed measurements, failed rows, the chart and first-request phases.
- Optionally save CSV and compare observations of the same target at another time.
Use cases
- Compare how the same site responds at different times
- Notice occasional delays hidden by a similar average
- Export a bounded HTTP request log for a support discussion
- Understand browser HTTP, command-line ICMP and in-game ping
Frequently asked questions
Is this actual internet or game-server ping?
No. It times browser HTTP HEAD requests to this site’s fixed path. HTTP processing, browser scheduling and connection reuse are included, so it is not ICMP or a game-server RTT. It does not contact arbitrary IP addresses or ports or measure overall internet speed.
What endpoint is measured, and is it a Korean server?
The observation follows the CDN, proxy or origin route currently answering this site. The tool does not establish the edge location or whether the origin was reached, so it does not label the target as Seoul or Korea. Compare observations of this same page at different times.
How are warmups and caches handled?
The first three attempts are separated as warmups for every connection. Requests use cache:no-store and query-free HEAD. This site’s existing service worker passes non-GET requests through, avoiding its cache-first static GET path. CDN, proxy and connection-reuse effects can still remain.
What are jitter, P95 and the failure rate?
Jitter is the mean absolute time difference when two adjacent measured requests both succeed. Pairs spanning a failure are excluded; no eligible pair means no jitter value. P95 is the ceil(success count×0.95)th sorted successful time. Failure rate describes completed HTTP measurement attempts, not ICMP packet loss.
What happens on cancel, offline or tab changes?
Only one run is active. Each request has a three-second limit, with at least 500 ms between requests, at most 23 requests or 90 seconds per run and a five-second minimum start gap. Cancel, hiding, offline and leaving abort the request and wait. Only completed records remain; cancelled or unsent attempts do not count as failures.
Why are first-request DNS or TLS times zero or absent?
The first request may reuse a connection. DNS, connections or browser timing precision can hide individual phases. Zero is an observed zero difference; an empty value means unavailable. Connection timing may include TLS, so do not sum every field to reconstruct the total.
Privacy
Starting sends HEAD requests only to this site’s fixed path. As with normal web requests, existing server or intermediary infrastructure can process connection information; requests omit login cookies and the referring URL. Measurements stay in page memory without separate server uploads, analytics events or browser storage. A CSV is created on your device only when you choose Save. The example sends no requests.
Comments & questions