How to Actually Read a Speed Test

A speed test that reports one number, “your speed is 340 Mbps”, is answering a much smaller question than most people think. A connection is several numbers, not one, and this guide covers what each number on the results screen means, followed by exactly how the Sygnal Score turns them into a single honest verdict.

Download and upload

These are what everyone expects: how many megabits per second move in each direction. They matter, but less in isolation than the marketing on your ISP’s homepage suggests. See the companion guide on how much speed you actually need for the real per-activity numbers. One asymmetry worth knowing: most home plans are far more generous with download than upload, which is fine for browsing and streaming and a real constraint for anyone who sends video regularly.

Idle latency

The round-trip time to a nearby server when nothing else is happening on the line, the baseline “how far away is the internet, right now” number. Idle latency in the 10–30ms range is typical for a wired or good WiFi connection to a nearby server; higher than that, and interactive things (calls, games, even a page feeling instantly responsive) start to suffer regardless of how much download speed you have.

Loaded latency and the delta

The same round-trip measurement, taken while the download and upload phases are actively saturating the line. On a clean connection this barely moves from the idle number. On a connection with an oversized, unmanaged queue somewhere in the path, it can balloon to hundreds or thousands of milliseconds. This is bufferbloat, and it has its own dedicated guide because it’s the single most underrated problem in home networking. The number that matters is not either latency reading alone, it’s the delta between loaded and idle: a small delta means the connection stays responsive under real use, a large one means it falls apart exactly when you’re using it hardest. The results screen grades that delta on a letter scale: A+ under 5ms, A under 15, B under 50, C under 150, D under 400, and F above that. The grade is taken on the spikes (the 90th percentile of the pings under load, in whichever of the download and upload phases was worse), while the loaded-latency figure on screen is the typical (median) reading, so a line that is usually fine but spikes still gets the grade it deserves.

Jitter

The variation in latency from one packet to the next, not the latency itself. A connection with 40ms latency that stays at 40ms is far better for a call or a game than one that swings between 20ms and 90ms, even though its average might look identical. Jitter is what causes a call to stutter or a game to feel inconsistent even when the “ping” number looks fine on average.

Jitter is also the number most likely to look fine on average and still ruin a call or a match. One bad two-second stretch is exactly what a video call’s freeze-and-catch-up moment looks like. If something felt bad during a call or a game but the test afterward looks clean, that’s not necessarily a contradiction. It can mean the problem was a brief spike the single test run didn’t happen to catch. Running the test two or three times, especially during the activity that felt bad, gives a much more honest picture than any single run.

Failed requests (and why this is not packet loss)

The last number on the results screen is the share of the test’s own requests that failed outright: a latency check that never came back, or a download or upload stream that broke off before it finished. On a healthy connection it reads 0%. A test makes a limited number of requests, so a single failure can already read as several percent. Run the test again before reading anything into it.

It is not packet loss, and we don’t call it that. Packet loss is packets that never arrive, and it is brutal for real-time traffic: a live call or a competitive game has no time to wait for a resend, so even a small loss rate is felt as a stutter, a freeze or a dropped word. A browser speed test can’t see it directly. Its requests travel over TCP, which quietly resends lost packets, so real loss shows up here only indirectly, as lower speeds and higher or spikier latency, never as a count of missing packets. Measuring true packet loss takes a different kind of test, one that sends packets without resending them. Because failed requests are a much blunter signal, they are shown for information only and play no part in the Sygnal Score or the use-case ratings.

What the Sygnal Score does with them

The Sygnal Score turns five of those measurements into one 0–1000 number, weighted like this: download 300 points, upload 150, idle latency 175, bufferbloat 275, jitter 100. The weights sum to exactly 1,000 when every measurement is present. Failed requests are not part of it, for the reasons above. Download and upload are log-scaled rather than linear, because that’s how the real value of speed actually behaves: on download, the anchors are 25 Mbps → 150 points, 100 Mbps → 225 points, 300 Mbps → 270 points, 1,000 Mbps and above → the full 300. The jump from 5 to 25 Mbps changes what a household can actually do; the jump from 500 to 1,000 barely changes anything, and the score reflects that instead of pretending gigabit is ten times better than 100 Mbps.

Bufferbloat is the single largest block at 275 points on purpose: full credit at a 15ms loaded-minus-idle delta or below (grade-A territory), measured on the same spikes the grade uses, zero credit at 400ms or above, because a connection that looks fast but collapses the instant it’s actually used is not a good connection, and a score built purely from throughput would call it one anyway.

The final number lands in one of five bands: exceptional (900+), strong (750+), decent (550+), struggling (350+), or weak (below 350).

Why a fast line can still score low

There’s one more rule layered on top of all of that, and it exists because of a genuine gap in the arithmetic above: a slow-but-clean connection can post a surprisingly high score from the latency-family blocks alone, even though a household on that line could not reliably stream 4K or run more than a device or two. A 0.5 Mbps download with otherwise perfect latency can score in the 600s from idle latency, bufferbloat and jitter alone, clearly wrong for a line that slow.

The speed gate exists to stop that: the score is capped by download speed, on a ladder, no matter how clean the rest of the connection measures. Under 25 Mbps, the score cannot read above 749 (the top of the “decent” band): a household under that line genuinely cannot do everything a modern connection should, regardless of how clean its latency is. Under 5 Mbps, the cap tightens to 549. Under 1 Mbps, it tightens again to 349. Clear 25 Mbps and the gate lifts entirely; nothing above that threshold is capped by speed at all, only by how the connection actually performs. If your score looks capped, this is why, and it’s the honest answer, not a penalty: “your Sygnal is only as strong as its weakest link” is the whole idea, and for a very slow line, speed itself is that link.