Methodology

How the speed test works

The test runs in your browser and moves real data to and from Cloudflare’s network, timing it. It measures four things: download throughput, upload throughput, round-trip delay (ping), and how much that delay varies (jitter).

It runs a sequence of transfers at increasing sizes rather than one large one, so a slow connection is not kept waiting and a fast one still reaches full speed. Latency samples are interleaved between them. Throughput is taken at a high percentile of the samples rather than the mean, because a single stalled request should not define the result.

We use Cloudflare’s edge because the bandwidth is theirs. A test is only as fast as the narrowest link in it, and a server we ran ourselves would be measuring our own connection rather than yours.

Why Wi-Fi and Ethernet give different answers

A wired connection is a dedicated cable at a fixed speed. Wi-Fi is a radio signal shared with your neighbours’ networks, absorbed by walls, weakened by distance, and negotiated separately by every device. It is normal for Wi-Fi to deliver a fraction of what the line supports, and normal for that fraction to change between rooms.

This is why the connection type changes the diagnosis rather than being a detail. A result of 40 Mbps over Wi-Fi and the same result over a cable mean very different things.

Why one result cannot prove a cause

A speed test measures the whole path: your device, its Wi-Fi adapter, the air between it and the router, the router, the line into the property, your provider’s network, and the route to the test server. A poor result proves that something in that chain is limiting you. It cannot say which link, because it only ever produces one number for the whole chain.

Comparison is what isolates a cause. Two results that differ in exactly one respect — wired against wireless, beside the router against across the house, evening against morning — tell you about the thing that changed. This is why the tool asks for a second test rather than guessing, and why it will return “not enough evidence” instead of naming a cause it cannot support.

Comparing against your package

UK broadband is advertised using an average speed available to at least half of customers at peak time, under the ASA and Ofcom rules. It is not a promise to every customer. On top of that, protocol overhead costs a few percent between the line rate and usable throughput, and Wi-Fi and older devices can cost a great deal more.

So we use three bands rather than a pass or fail:

• 80% or more of the advertised speed — consistent with the package. Combined with acceptable latency, this is reported as healthy.
• 50% to 80% — below expectation. This is a real shortfall and we say so, but the gap alone does not indicate where the speed is being lost, so the result is “not enough evidence” plus the retest that would narrow it down. We do not describe this band as normal.
• Under 50% — materially below. Too large to explain by overhead or ordinary variation, and worth investigating properly.

For latency, we treat ping above 60ms or jitter above 15ms as worth mentioning, and ping above 100ms, jitter above 30ms or packet loss above 2% as poor.

These are judgement calls, not measured constants. They are kept in one versioned configuration file, cited here, and stamped onto every result — the rules that produced your diagnosis were version 1.1.0. If we change them, the version changes with them.

Confidence levels

• Low — a single observation, or a conclusion that rests on something you told us rather than something measured. Treat it as provisional.
• Moderate — the evidence supports the conclusion, but a plausible alternative has not been excluded.
• High — corroborated by a second measurement that isolates the cause. Deliberately hard to reach.

Two rules apply on top of whatever a diagnosis would otherwise claim:

• Figures you type in are weighted below figures we measured, because a typed number may be mistyped or taken under different conditions.
• Any claim about a cause is capped at moderate without a second test. One test can show a symptom; it cannot locate a fault.

Limits of the provider we measure against

The measurement runs against Cloudflare, which places some real limits on what the result means. You are measuring the path to Cloudflare’s nearest edge, not to any particular website. A route that is fast to Cloudflare could be slower elsewhere. These are free public endpoints with no service guarantee, so a failed test may reflect their availability rather than your connection — which is why failures are reported as failures and never filled in with a plausible number.

The measurement is also only as good as your device. An older phone or laptop can be the limit regardless of the line, and a browser cannot tell us that it is.

How free fixes are prioritised

Every action we suggest is ordered by effort first: things you can do in the next thirty seconds, then things that take a few minutes, then things that take real work. Within that, the ordering reflects how much each typically buys.

Free actions always come before any paid suggestion. Most home broadband complaints are resolved by moving a router, switching band or plugging in a cable, and a tool that leads with a purchase is not diagnosing anything.

How commercial recommendations stay separate

The diagnostic engine has no access to commercial data. It cannot see prices, merchants or commission rates, so those cannot influence a result — not as a policy, but because the information is not available to the code that reaches the conclusion.

What it can do is name a category that is relevant, such as networking hardware or a different broadband package, and only where the evidence supports it. Choosing and ranking specific products happens separately, after the diagnosis is fixed, and any provider ranking will exclude commission from its quality score.

Nothing commercial is active on this site yet. When it is, it will be labelled.

Privacy covers what happens to your data during a test.