Methodology · technical transparency

How we actually measure your connection

Never take a speed test's word for it. Here we explain step by step how RealMbps works: target servers, adaptive algorithms, percentiles, error handling. All verifiable, all transparent.

1. Architecture

The test runs entirely in your browser (client-side JavaScript), querying Cloudflare's global infrastructure:

• Latency/jitter: https://speed.cloudflare.com/__down?bytes=N with small N (1 KB), to obtain minimum RTTs
• Download: same endpoint with N varying from 1 MB to 50 MB
• Upload: https://speed.cloudflare.com/__up POST
• Geolocation: https://speed.cloudflare.com/meta

Cloudflare automatically selects the PoP closest to your IP (about 300+ global data centres). There are no "friendly" servers embedded in your provider's network, as happens with other tests.

2. Latency (ping) and jitter measurement

We run 12 consecutive measurements of a 1 KB download. For each we calculate the round-trip time (RTT). Then:

• Ping = median of the 12 values (excludes outliers)
• Jitter = mean absolute deviation from the median

Why the median and not the mean? The mean is sensitive to outliers (a single lost packet can inflate it). The median reflects the "typical" latency you experience during normal use.

3. Download measurement

We run requests of increasing size (1, 2, 5, 10, 25, 50 MB) until we have enough samples. For each request:

1. We measure transfer time using performance.now()
2. We compute throughput in Mbps = (bytes × 8) / (seconds × 1,000,000)
3. We add the value to the sample list

The final estimate is the 90th percentile of the second half of the samples. In plain terms: we discard the initial phase (TCP slow-start, where speed is artificially low) and take the "steady-state" value reached at cruising speed, excluding only anomalous peaks above the 90th percentile.

4. Upload measurement (with adaptive algorithm)

Upload is the trickiest part, especially on mobile networks. Our approach:

• Adaptive chunks: we start with small blocks (256 KB) and double them if the network holds. On fast networks (FTTH) we go up to 8 MB; on slow mobile (real 5 Mbps) we stay at 256-512 KB but take many samples.
• Parallel workers: 3 parallel connections on desktop, 1 on mobile (below 720 px) to avoid saturating the uplink with unnecessary concurrency.
• Per-request timeout: every POST has an AbortController that terminates it after 3 seconds (or the remaining time). A cellular blip does not stall the test.
• Error tolerance: up to 8 transient failures accepted, with backoff and automatic chunk-size reduction.
• Final estimate: 75th percentile of the second half of the samples (more conservative than download, because upload tends to be noisier).

5. What influences the results

Even with the best methodology, some factors are outside our control and affect the measurement:

• Wi-Fi: on a 1 Gbps FTTH line, home Wi-Fi rarely exceeds 400-600 Mbps in practice. To measure the line, use an Ethernet cable.
• Hardware: old PCs with 802.11n Wi-Fi cap around 150 Mbps in practice. Entry-level smartphones limit things similarly.
• Active VPN: adds an intermediate hop, reduces speed and increases ping.
• Other activities at home: TV streaming, smart speakers, cameras silently consume bandwidth.
• Obsolete browsers: poor HTTP/2 implementation lowers throughput.
• Provider network load: during peak evening hours (9-11 PM) real speed can drop 20-30%.

6. Typical error margins

Comparing RealMbps to official measurement tools (e.g. Ofcom-endorsed testers in the UK, FCC Measuring Broadband America in the US, breitbandmessung.de in Germany), typical errors are:

• Download: ±5% under controlled conditions (Ethernet cable, no other activity)
• Upload: ±10% (more variable by nature)
• Ping: ±2 ms
• Jitter: ±1 ms

For personal and diagnostic use, RealMbps is perfectly adequate. For legal use (formal complaint to your provider with evidential value), you need a measurement tool recognised by your national telecom regulator (e.g. Ofcom in the UK, FCC in the US, BEREC in the EU): see our local guides on how to measure properly.

7. Transparency and source code

The algorithm is entirely in JavaScript loaded by the browser. You can inspect it with:

• F12 (DevTools) → "Sources" tab → file script.js
• Search for the functions measureLatency(), measureDownload(), measureUpload()

No obfuscation, no hidden code. What you see is what we measure.

8. Differences with other speed tests

What makes RealMbps different from Speedtest by Ookla, Fast.com, etc:

• Neutral Cloudflare servers, not servers controlled by your provider (Speedtest.net often uses in-network servers)
• Privacy first: no tracking cookies, no IP collection, no data selling
• Adaptive algorithm for mobile: we deliver a measurable upload even on slow 4G/5G (Speedtest.net often fails or under-estimates on mobile)
• Open methodology: documented on this page and inspectable in DevTools
• Community wall: public leaderboard for gamification and comparison with other users in your country