Skip to content
Back to speed test

Measurement methodology

How we measure your connection

Our testing methodology, measurement limitations and data handling practices.

Automatic server selection

Your browser checks the configured regions, warms each connection, then compares the median of three small HTTP latency probes. At least two probes must succeed. Automatic mode chooses the reachable region with the lowest median. It checks again before every test, and can try the next region if the first becomes unavailable before speed measurements begin. You can also select a region yourself.

Download and upload

The test transfers randomly generated data directly between your browser and the selected regional server. Multiple parallel requests adjust their payloads toward a 600 ms request duration. Throughput is the total payload received over elapsed wall-clock time, including request overhead. Uploads count only after the server acknowledges the entire body. The graph displays a one-second rolling average updated every 250 ms. The headline is sustained average payload throughput across the transfer phase. Aggregate P90 uses original intervals after the first second of calibration. Per-request P90 describes individual streams and is shown separately.

Latency and jitter

Idle latency is the median of ten HTTP round trips after connection warm-up. Jitter is the mean absolute difference between consecutive idle samples. During downloads and uploads, extra small requests measure latency under load. These are application-level HTTP measurements, including browser scheduling and server response time, rather than ICMP pings. A dash means no valid measurement is available.

Interpreting your results

This measures the path to the selected datacenter, not every destination on the internet or a guaranteed ISP line rate. Wi-Fi, VPNs, your device, other traffic, browser connection limits and server capacity can affect the results. Keep the tab visible and pause other large transfers for a more consistent comparison. Packet loss is measured separately over WebRTC/UDP when your browser and the selected region support it.

Packet loss

During each transfer and again after the HTTP phases, your browser sends 1,000 random, 64-byte messages over an unordered WebRTC data channel with retransmissions disabled. The selected region echoes each message. Unique replies count as received; replies missing after a three-second grace window count as lost. We also record duplicate replies, reordering and round-trip times. This is round-trip application-message loss over UDP, not one-way IP packet loss. A blocked or failed UDP test is unavailable, never zero percent loss. A loaded UDP result is retained only when the HTTP transfer remained active throughout the entire UDP measurement. Short transfers may not provide enough overlap. HTTP results remain available.

Responsiveness and quality

Loaded jitter is calculated separately for each transfer direction. The Measurements view also shows minimum, maximum, mean, median, P25, P75 and P95 latency, box plots and individual samples. Load increase (a bufferbloat indicator) is calculated separately for download and upload as the loaded median minus the idle median, floored at zero. Streaming, gaming and video-call ratings use OneMind Services scoring rules. We normalize throughput, response time, latency under load, jitter and packet delivery, then weight them for each activity. Video-call scores are also limited by throughput in both directions: a 3 Mbps uplink and 5 Mbps downlink reach the top of the capacity scale. Loaded UDP loss contributes when measured. These thresholds are product heuristics, not service requirements. Scores range from 0 to 100 and remain incomplete when a required measurement is unavailable. These ratings are estimates for the selected datacenter path, not guarantees of performance in a particular service.

Time and data limits

Standard tests begin with an eight-second window per direction and may extend to fifteen seconds. Extension depends on request duration, sample count and throughput stability. Requests aim for 600 ms and use payloads up to 32 MiB or the server’s lower limit. Quick tests use shorter windows and up to 512 MiB per direction. Extended tests use a thirty-second window and twice the Standard data budget. All modes respect operator limits. Standard allows up to 16 GiB per direction and Extended up to 32 GiB per direction; actual usage is shown during the test. Transfers still in progress at the maximum duration are cancelled. Only acknowledged uploads count toward throughput; a cancelled upload may have sent additional bytes, within the reserved data budget. HTTP, UDP and network overhead are additional. No bandwidth test starts until you select Start test.

Measurement confidence and network diagnostics

Consistent results contain at least sixteen aggregate intervals after calibration, with a relative interquartile range of at most 20% and stable recent windows. Variable results show greater spread or drift. Limited results have too few sustained samples or reach the data budget early. These labels are quality indicators, not statistical confidence intervals. Network diagnostics show the address observed by the API, an optional locally resolved ASN and separately configured IPv4/IPv6 reachability. Browser timing may expose DNS, TCP, TLS, request-to-first-byte, response duration and HTTP protocol. Reused or unreported connection timings remain unavailable. Datacenter maps use configured coordinates, not inferred customer locations.

Data handling and privacy

There is no analytics SDK or third-party results endpoint. The last ten completed summaries are saved in this browser when local storage is available; Clear history removes them. No files, credentials or personal payloads are uploaded. Test servers necessarily see your network address to serve requests; the API returns the observed address to this browser for network diagnostics and uses it temporarily for UDP capacity limits. The address is displayed in Network diagnostics, is never saved in result history and is not sent to an external lookup service. API logs record request IDs, routes, status codes, duration and byte counts. They exclude client addresses, request payloads and WebRTC negotiation data. Infrastructure operators may maintain separate access logs.

Built by OneMind Services. Brand assets and Roboto are served locally. Measurements run directly against the selected regional server.