iSpeedTestA transparent speed test methodology
Our speed test methodology measures browser-level performance between your device and Cloudflare HTTP measurement endpoints. It is designed to provide an accessible connection check with a bounded payload budget. It does not certify an access line, replace a provider's diagnostics, or predict the performance of every application. Each completed result is an observation of one path at one time.
The speed test methodology is implemented in this site's client-side measurement code. It uses the browser's monotonic performance clock and real network requests. No demonstration values, random scores, or fabricated provider identities are presented as measurements. The tool starts only after an explicit user action. Every result should be read with its mode, profile, and conditions in mind, particularly when comparing it with a tool that uses a different destination or transfer strategy.
Idle timing in our speed test methodology
The session begins with a zero-payload HTTP request intended to warm the path before the idle measurements. It then performs ten sequential zero-payload requests. Each sample measures elapsed time from initiating the fetch until the response body is consumed. We report the median of those ten durations as idle HTTP latency.
Jitter is the mean absolute difference between consecutive idle sample durations. This speed test methodology therefore uses a specific, published definition rather than implying that every tool calculates jitter identically. Browser scheduling, endpoint processing, and request overhead remain included. The latency is not raw ICMP round-trip time, and it is not a game-server measurement. A short sequence can miss intermittent problems, so the speed test methodology supports controlled repetition rather than claiming that ten samples establish long-term network reliability.
Adaptive transfers in our speed test methodology
For each selected transfer direction, the test begins with a 200,000-byte payload. Later payload sizes adapt to the observed rate, aiming for a transfer of roughly 800 milliseconds while limiting each payload to 16 MB. Each direction performs at most five transfers and stays within its total payload budget. A transfer lasting more than three seconds ends that direction's sequence after it completes.
The speed test methodology calculates direction throughput as total successfully transferred payload bits divided by the total elapsed time of those requests. Downloads consume the complete response body and verify its expected size. Uploads send generated random bytes and include the response wait in elapsed time. This speed test methodology does not subtract request startup overhead or use multiple parallel bulk transfers. Consequently, it may produce lower readings than a saturation-oriented tool, especially on very fast connections.
Loaded timing in our speed test methodology
During each active transfer direction, the tool attempts small HTTP probes at spaced intervals and retains up to twenty-four successful timing samples. The median of those samples becomes the loaded latency for that direction. When no sample completes, the result remains unavailable. Missing data is never silently replaced with a zero that might look like an excellent result.
This part of the speed test methodology is an observation under the tool's own workload. It does not guarantee that a link was fully saturated. Browser connection scheduling and endpoint overhead can affect the probes, while a short transfer may be too brief to characterize sustained queueing. The speed test methodology therefore avoids assigning a definitive bufferbloat grade. Compare the readings with a real workload and an appropriate longer diagnostic when investigating persistent delays under load.
The speed test methodology and payload budgets
The standard full session permits up to 64 MB of download payload and 32 MB of upload payload. Data saver permits up to 8 MB down and 4 MB up. These are decimal payload budgets; protocol overhead, response bodies, and small timing requests are additional. A slow connection or an early stopping condition can use less data than the maximum.
Each request has a fifteen-second timeout, and the session has a ninety-second overall timeout. The user can stop a run, and navigating away aborts its active measurement requests. The speed test methodology distinguishes completed, cancelled, and failed sessions. Only completed sessions are eligible for optional local history. The speed test methodology never promotes a partial reading into a completed result merely because some numbers appeared before a timeout or connection interruption.
Limits of our speed test methodology
The observed path includes the device, browser, local network, router, provider, internet routing, and measurement endpoint. A slow result does not identify which component is responsible. Wireless tests include the local radio hop but cannot directly measure its signal strength, channel utilization, or negotiated link rate. Mobile tests cannot reliably identify or switch the active radio technology.
This speed test methodology does not measure UDP packet loss, raw ICMP latency, NAT type, DNS resolver performance, or website rendering speed. It does not infer an ISP name or server city from guesswork. Bounded payloads can under-read gigabit and faster links. Background tabs, device processing, VPNs, filtering software, and other traffic can also affect the result. The speed test methodology makes these limitations explicit so that a convenient browser tool does not imply the authority of a laboratory certification.
Data handling in our speed test methodology
The measurement requests go directly from the browser to Cloudflare endpoints. Cloudflare therefore receives the network requests and the IP address used for that connection. Its own privacy practices apply to that processing. The site does not ask for a Wi-Fi password, select personal files, or request precise location permission to run the test.
Our speed test methodology generates upload payloads in memory. Completed results are stored in local browser storage only if the user enables history, with a maximum of ten entries. Clearing history removes those local entries. Copying a result uses the clipboard only after a deliberate click. The speed test methodology is separate from any general hosting logs or optional site analytics; the privacy policy explains those distinctions. A promise that results stay local is not a claim that network providers receive no connection information.
Compare tools with their speed test methodology
Use the same device, profile, endpoint method, and connection type when comparing runs. Pause unrelated transfers for an idle baseline and record the time. Compare Ethernet with Wi-Fi to investigate the local link. Repeat during the period when the actual problem occurs rather than relying on a convenient but unrelated quiet-hour reading.
Other services can use different destinations, connection counts, durations, and statistical calculations. A difference does not automatically prove that one tool is wrong. Keep the speed test methodology attached to the result when sharing it. For an important decision, combine several comparable observations with the application's own diagnostics and, where necessary, a longer independent test. We revise the documented speed test methodology when the implementation changes and avoid presenting a content date as evidence that a measurement was performed on your connection.
Sources & further reading
Our explanations distinguish the browser measurement from the underlying connection. These primary references provide context; they do not endorse this site.
Cloudflare: browser measurement methods Netflix: connection recommendations for streaming MDN: browser resource timingLet’s clear things up.
Is this speed test methodology the same as Cloudflare’s official app?
No. We use Cloudflare HTTP endpoints with our own bounded measurement sequence and calculation. This site is independent and does not claim Cloudflare endorsement.
Does the speed test methodology guarantee accuracy?
No method removes every variable. This page specifies the calculation and limitations so you can judge whether the observation is suitable for your question.
Why publish the speed test methodology?
A result is more useful when you know what was transferred, how timing was calculated, and which conclusions the experiment can and cannot support.