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 six numbers, not one, and this guide covers what each of them means, followed by exactly how the Sygnal Score turns all six 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 15ms, B under 50, C under 150, D under 400, and F above that.

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.

Packet loss

The percentage of packets that never arrive at all and have to be retransmitted or simply go missing. Loss is brutal for real-time traffic in a way the other numbers aren’t: TCP can often paper over modest loss by resending, but a live call or a competitive game has no time to wait for a retransmission, so even a small loss percentage is felt immediately as a stutter, a freeze, or a dropped word.

Loss and jitter are the two numbers most likely to look fine on average and still ruin a call or a match — a 0.3% average loss can still mean one bad two-second stretch where several packets in a row vanish, which 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.

What the Sygnal Score does with all six

The Sygnal Score turns those six measurements into one 0–1000 number, weighted like this: download 300 points, upload 150, idle latency 150, bufferbloat 250, jitter 75, packet loss 75 — the weights sum to exactly 1,000 when every measurement is present. 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 250 points on purpose — full credit at a 20ms loaded-minus-idle delta or below, 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, jitter and loss 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.