How we measure

Press "Start test" and your browser spends about a minute doing four things: downloading a couple of files, probing ten domains, poking at ten commonly blocked sites, and loading a set of images whose dimensions we already know. Everything runs client-side; the server only receives the results. The procedure matches GreatFire's Circumvention Central, with two additions of our own: reachability and a parallel-stream peak. Each step has limits worth knowing about.

Speed

For each speed URL, the test issues one fetch with cache: 'no-store' and then reads the response body as a stream, counting bytes as they arrive instead of waiting for the whole file. It stops at end-of-file or at the time limit, whichever comes first. speed = bytes read / elapsed time.

There are currently two URLs: our own /api/speedtest-file (50 MB of random bytes, 15-second limit) and Cloudflare's speed.cloudflare.com/__down (also 50 MB, 10-second limit). Why two? The local file measures the path from you to our server; the Cloudflare file measures the path to the nearest edge of a global CDN. Those two paths often leave the country through different exits. A tool can be blazing fast to a CDN and sluggish to an ordinary VPS, or the other way around.

The "speed" shown on the board is avgAll, the mean of both files. It's the headline metric and corresponds to GreatFire's averageSpeedAllFiles. We also compute avgVideo, the mean of the non-local files only, which feeds the streaming estimate below.

Our addition: a 3-stream parallel burst for 5 seconds against the local file, with the combined throughput reported as max. Single-stream downloads are at the mercy of TCP congestion control and packet loss, which is exactly what lossy cross-border routes are full of. Three streams show what the route can carry; a big gap between max and the single-stream number usually means heavy loss.

Latency

The latency test sends 2 HEAD requests to each of 10 domains, with mode: 'no-cors', cache: 'no-store' and an 8-second timeout. Each successful request contributes one timing sample; the median of the twenty samples is the test's latency. Failures go into a failures list.

The no-cors choice deserves a word. Browsers won't let a page read responses from other origins, but in no-cors mode the request still goes out; you just get an "opaque" response back. No status code, no body, but you do know when it arrived. That's all we need; we only want the round trip.

The cost is that we can't distinguish a 200 from a 403 or a redirect. A request the server refuses looks identical to one it served. Connections that the Great Firewall resets or drops show up as timeouts or as fetch throwing; those are recorded as failures and excluded from the latency samples.

A few known sources of noise: browsers cache DNS, so the second request to a domain may skip resolution; HTTP connection reuse means the second request may ride an already-open connection and come back much faster than the first; some browsers pre-connect before you've even clicked. All of these push the number a little low. The median absorbs some of it, not all.

Reachability

This one is ours; GreatFire doesn't do it. One HEAD no-cors request each to YouTube, X, Instagram, Facebook, ChatGPT, Telegram Web, Discord, GitHub, Wikipedia and Google, 8-second timeout, recording whether it came back and how long it took.

It answers a plain question: with this tool, do these sites open right now? The latency median describes the route's overall quality; reachability tells you which specific sites this route (or this exit IP) can't reach. Some hosting ranges are blocked by Google or OpenAI outright, and no amount of speed helps with that.

Because of no-cors, again, we can only tell "it responded", not "it responded with the right thing". A site returning a 403 block page counts as reachable. That's a browser limitation, not laziness on our part.

Stability

The stability test uses a list of images with known dimensions, [url, width, height]. Each is loaded via new Image() with a cache-busting timestamp and a 10-second timeout; on load, naturalWidth and naturalHeight must exactly equal the expected values. stability = passed / total × 100%.

A size check works because most kinds of interference change the size. An ISP's transparent proxy swaps the image for a "this page cannot be displayed" graphic, which has different dimensions. A hijacking middlebox injects content into the response, and the image fails to decode or comes out a different size. DNS poisoning points the domain at a bogus IP that either doesn't answer or returns something else entirely. Conversely, if the image arrives intact at the expected size, that path is very likely clean.

What it doesn't measure is performance. An image that crawls in over nine seconds but has the right dimensions still passes. Stability and speed are separate axes; 100% stable does not mean fast.

Streaming estimate

No extra measurement here. avgVideo is converted to megabits per second (bytes × 8 ÷ 10⁶) and looked up in a threshold table:

Speed	Estimated quality
< 0.7 Mbps	240p
< 1.5 Mbps	360p
< 2.5 Mbps	480p
< 5 Mbps	720p
< 8 Mbps	1080p
< 20 Mbps	1440p
≥ 20 Mbps	2160p

The thresholds come from GreatFire's implementation and we kept them unchanged so the two sites agree. It's a rough guide: YouTube's real bitrates vary with content and codec, and the player adapts continuously. Measuring 3 Mbps for ten seconds doesn't guarantee a sustained 3 Mbps for a forty-minute video. Read it as "roughly which tier you'll land in".

Biases a browser test can't escape

In the end this is a test running inside a browser, not iperf. A few things to keep in mind:

A single download stream is bounded by TCP (or QUIC) congestion control, and on a high-latency, high-loss path it won't fill the pipe, which is why we added the parallel peak. The browser itself has overhead, noticeably so on phones. Your Wi‑Fi, a cloud drive syncing in the background, someone else on the router watching video: all of it is in the number. The same exit node can be three times slower at 9 p.m. than at 3 a.m.

And two things we cannot verify: the location you selected and the tool name you typed. We have to take your word. This is why the rankings require at least five tests across 48 hours, and why medians matter more than means. Individual noise and honest mistakes get diluted by volume.

If you want rigorous numbers, command-line tools (iperf3 or speedtest-cli straight to a server) are more accurate. But they don't capture what an ordinary person experiences using a browser through a tunnel, and that experience is what this site is about.

FAQ

Why do other speed-test sites show me a faster number? Most of them auto-select the nearest server and open many parallel streams. Our headline metric is a single stream to a fixed server, so it's naturally lower, but it is comparable across tools. The max figure will be closer to what other sites report.

Why do some domains always fail the latency test? Some servers handle HEAD slowly; some connections get reset by the network you're on. Failures don't count toward the median, but they appear in the detail view, and they're informative in their own right.

What gets stored from a test? The location you chose, the tool name and version you entered, the results and details of the four tests, and your browser and OS family. When a tool is in use we record the exit IP's country, never the raw IP.

Can I test without a tool? Yes, pick "None". Those results don't enter the rankings, but they feed each region's "bare connection" median, which serves as a baseline.