How this browser test works

One server route for every phase

The test exchanges traffic with /api/network on internetspeedtest.io, hosted on Namecheap. Download and upload use that same origin. It is not a distributed nearest-server network. We do not send measurement payloads to Cloudflare’s speed-test service.

Results include your device, local network, ISP route and our hosting service. They do not isolate those components. A server bottleneck can look like a slow connection. We do not convert a result into a certified line speed, a provider ranking or a gaming score.

Latency and request failures

1. A bounded warm-up request establishes a connection and is excluded from latency statistics.
2. For about ten seconds, the browser sends sequential uncached HTTP requests. Each has a maximum 2.5-second deadline. The final request retains its full deadline rather than creating an artificial failure when the sampling window closes. A pause of up to 70 ms separates attempts.
3. The clock starts before the request and stops after the full response is read. Only a successful JSON response with ok: true counts as completed.

The attempt count varies with response time. An earlier description incorrectly said there were always 24 requests. The result now shows the actual attempts, failures and percentage resolution.

HTTP latency (median)

The middle successful round-trip time after sorting. For an even number of samples, the two middle values are averaged.

HTTP jitter

The mean absolute difference between adjacent successful attempts. Failed attempts break the sequence; we do not bridge across a missing sample. With no adjacent successful pair, jitter is unavailable.

HTTP request failure rate

Failed or timed-out requests ÷ attempted requests × 100. If all attempts fail, the run stops without recording a complete result.

What the loss percentage can tell you

A failure is an HTTP outcome, not an individual IP packet. TCP can retransmit lost packets and still complete a request; a server delay can cause a timeout without proving packet loss. Zero observed failures does not establish a perfect network.

We do not apply sub-percent “excellent/good/fair” bands to a sample that cannot distinguish those rates. Use repeated observations and the affected application’s diagnostics.

Download and upload throughput

Each transfer phase starts requests during a ten-second window, then allows in-flight requests to finish within their five-second deadlines. Download uses three concurrent request loops and upload uses two. Payloads start at 65,536 random bytes per request. A loop doubles its payload when a response takes less than the measured median latency plus 500 ms, up to 4 MiB for download or 2 MiB for upload. This latency-aware threshold avoids trapping distant connections at the smallest payload. Responses slower than the greater of two seconds or four times the measured latency, and failed attempts, halve the next payload, down to 65,536 bytes. This adapts the request size to slower connections without assuming the connection speed. Requests are uncached and the binary download is not compressed by the application.

A download counts only after a complete binary payload of the expected length arrives. An upload counts only after the server replies with ok: true and the exact received byte count. Browser upload progress events alone do not count as delivered data.

Mbps = confirmed payload bytes × 8 ÷ elapsed milliseconds ÷ 1,000. The denominator is the entire phase, including response time, scheduling and unsuccessful attempts. A timed-out or incomplete transfer contributes no bytes. This is conservative application throughput, not wire speed. Failure counts and durations are included in the report.

Download requests reserve at most 150 MiB and uploads at most 50 MiB. A phase ends early if its data allowance is exhausted. The report identifies that condition. Control requests and protocol overhead are additional. Expect about 30–45 seconds including warm-up and bounded final requests, with scheduling variation. Very slow connections may still fail to complete a minimum 65,536-byte payload before its deadline; that produces an explicit error, not a zero-speed estimate.

Cancellation and invalid runs

Cancel aborts active requests. Hiding the tab stops the run because background throttling can distort timing. Request deadlines also cover reading the response body. An unreachable server, invalid response or phase with no complete transfers produces an error, never a fabricated zero-speed result. A completed phase can contain failed attempts; those are disclosed.

Repeatable comparisons

Use the same device, route, connection type and service; pause unrelated traffic. Run three tests sequentially. Compare the median together with the range and retain failed attempts in your notes. Then change one condition, such as moving close to the router or using Ethernet.

Our report contains timestamps, raw latency samples, sample sizes, confirmed transfer bytes, durations and failures. Reports download to your device; results are not automatically submitted to an analytics service. Use the comparison worksheet.

References and boundaries

W3C High Resolution Time describes the browser clock. RFC 7680 describes one-way IP packet-loss metrics, and RFC 3393 describes IP packet delay variation. Our HTTP observations are not implementations or certifications of those one-way network metrics.

See the corrections policy and change record.