Measurement Method and Sources
Implementation reviewed: July 10, 2026
Scope: the main test measures application-layer traffic between this browser and the Cloudflare edge serving WiFiSpeedTest. It does not directly measure the physical WiFi radio, the full capacity of an ISP plan, ICMP packet loss, or every route an application may use.
Main Speed Test
HTTP round-trip time and variation
After one uncounted warm-up request, the browser sends 10 sequential zero-byte HTTP requests to /api/down. Only responses with a successful HTTP status are samples. The displayed RTT is the median of the successful elapsed times. “Jitter” is the arithmetic mean of the absolute difference between each pair of consecutive successful RTT samples. Failed requests are reported separately as HTTP sample failures; they are not called packet loss.
Download throughput
The browser warms eight connections, then uses eight parallel HTTP workers for a 12-second sampling window. Received bytes are accumulated into approximately 500 ms slices. Each slice is calculated as bytes × 8 ÷ elapsed seconds ÷ 1,000,000 Mbps. With at least four slices, the implementation sorts them, removes the lowest 30% and highest 10%, and reports the arithmetic mean of the remainder. Otherwise it reports total received bytes divided by total elapsed time.
Upload throughput
The browser warms six connections and sends generated zero-filled payloads through six parallel XMLHttpRequests for a nominal 12-second sampling window. Browser-reported upload progress is accumulated into approximately 500 ms slices. It uses the same bits-per-second formula and 30%-low/10%-high trimmed-slice mean as the download result.
Loaded RTT change
During download, the test attempts one zero-byte HTTP timing sample per second. The displayed change is the arithmetic mean of successful loaded samples minus the idle median RTT. This is a browser-to-edge loaded-latency observation, not a standardized bufferbloat grade.
Live HTTP RTT monitor and saved-history rules
The live monitor reports the current value, arithmetic mean, minimum/maximum, and population standard deviation of successful HTTP RTT samples. After five prior samples, an observation is marked as an outlier when it is more than three population standard deviations above up to 20 preceding successful samples; when the preceding standard deviation is zero, it is marked only if it exceeds that preceding mean. This is a site-defined alert rule, not a network-failure diagnosis. The optional saved-baseline notification uses the percentage selected in the interface and compares the latest download with the mean of up to five preceding saved downloads.
Site-Defined Diagnostic Score
The 0–100 score is a visualization, not an industry certification or population percentile. It is the rounded sum of four bounded components:
- Download: up to 40 points, reaching the cap at 100 Mbps.
- Upload: up to 20 points, reaching the cap at 50 Mbps.
- RTT:
max(0, 25 − RTT ÷ 4)points. - RTT variation:
max(0, 15 − variation)points.
Labels such as “Strong in this rubric” refer only to this published formula. Service-readiness comparisons are shown separately and use the primary sources below.
Browser Network Analyzer score
This separate 0–100 diagnostic uses only available inputs and normalizes by their available weight. Browser Effective Connection Type contributes up to 40 points (slow-2g: 0, 2g: 5, 3g: 20, 4g: 40); downlink contributes up to 30 points, capped at 20 Mbps; RTT contributes max(0, 30 − RTT ÷ 10) points. If the Network Information API is unavailable, the measured downlink and RTT components are normalized across their 60 available points rather than inventing a connection type. “Rubric constraint” is exactly 100 − score, not measured channel congestion. The live monitor's optional stability component is max(0, 100 − 2 × mean consecutive RTT difference) and remains unavailable until two successful samples exist.
Other Tool Boundaries
| Tool | What is observed | What is not established |
|---|---|---|
| WiFi Analyzer | Browser Network Information API estimates when exposed, plus first-party HTTP throughput and RTT samples. | Signal strength in dBm, channel, nearby access points, radio interference, or guaranteed physical link type. |
| IP Lookup | Cloudflare request metadata such as public IP, ASN organization, country/region/city when available. | Precise device location, identity, or reliable VPN/proxy/Tor classification. |
| DNS Leak Test | Public egress IP consistency across first-party requests. | The recursive DNS resolver used by the browser or operating system. |
| Port Checker | Whether a Cloudflare edge worker can establish a TCP connection to the requester's observed public source IP and selected port before timeout. | UDP reachability, a private LAN host, an arbitrary third-party host, or whether the same path works from another source network. |
| Route Overview | Browser-to-WiFiSpeedTest edge RTT plus public-egress and Cloudflare-edge request metadata. | Router-by-router hops or per-hop RTT. Browsers cannot issue the TTL-controlled probes used by operating-system traceroute. |
| ISP Speed Test | The same browser-to-edge HTTP measurement family and comparisons with records saved in that browser. | A statistically representative ISP ranking or measurements from other users. |
Reported-Network Speed Test details
The page at /isp-speed uses a lighter browser-to-edge engine than the main test. RTT is the median of up to 10 successful zero-byte HTTP timings. Download progressively requests payloads from 100,000 through 25,000,000 bytes, using one, then two, then up to four parallel requests for a nominal 10-second window; it reports total successful bytes divided by total elapsed time. Upload sends sequential generated payloads that grow from 50,000 to 500,000 bytes for a nominal eight-second window and divides browser-reported uploaded bytes by elapsed time. The page stores at most 20 results in local storage and groups them by the ASN organization string supplied in Cloudflare request metadata. That string is not a reliable ISP/VPN/proxy classification.
Primary Sources Used for Product Comparisons
| Claim used on the site | Primary source |
|---|---|
| The FCC adopted 100 Mbps downstream and 20 Mbps upstream as its fixed-broadband benchmark in March 2024. The site treats this as a policy benchmark, not an average or speed guarantee. | FCC 2024 Section 706 Report |
| Netflix recommends 3 Mbps for 720p, 5 Mbps for 1080p, and 15 Mbps for 4K. | Netflix internet connection speed recommendations |
| Zoom's published web-app guidance lists up to 3.8 Mbps down and 3.0 Mbps up for 1080p group video. | Zoom bandwidth requirements |
| Microsoft lists 4 Mbps up and down as its best-performance meeting-video bandwidth figure for Teams. | Microsoft Teams network preparation |
The browser's downlink value is an estimate rounded for privacy, and effective connection type is based on measured application-layer performance. | MDN: NetworkInformation.downlink; MDN: effective connection type |
| Cloudflare can expose request properties such as ASN and colo to Workers. | Cloudflare Workers Request documentation |
| IPv6 is the Internet Protocol specified by RFC 8200; the site does not recommend disabling it as a generic privacy fix. | IETF RFC 8200 |
| Port service names and assignments shown by the port tool come from the authoritative registry. | IANA Service Name and Port Number Registry |
Interpreting a Result
A result is evidence for this device, browser, route, server edge, and test window. For comparisons, keep the device and connection type fixed, pause avoidable traffic, record the time and conditions, and compare several runs. Different tools can legitimately differ because they use different endpoints, routes, payloads, concurrency, protocols, and aggregation methods.
Implementation details can change with a site update. The review date at the top identifies the version documented here. Data handling is described separately in the Privacy Policy.