A big number on an idle line says very little about a connection that is actually being used.
Signalyzr mobile app launching soon — advanced diagnostics for radio signal and deeper cellular insight.
A speed test measures peak throughput on a quiet connection for a few seconds — and throughput is rarely what breaks. Stuttering calls, spinning buffers and pages that hang before loading instantly are usually caused by delay under load, variation in that delay, small amounts of packet loss, or slow name lookups. None of those move the headline number, which is exactly why the number looks fine while the connection does not.
Bandwidth is capacity, not speed — it tells you how wide the road is, not how long the journey takes. A three-hundred-megabit line with a queue that swells the instant anything uploads will fail a video call that a twenty-megabit line handles without complaint. The wide road is not helping if every car waits two seconds at the junction.
This is not a rare edge case; it is the ordinary condition of most home connections. Speed tests are built to report the best number a link can produce: they run briefly, on an otherwise idle line, against a nearby server chosen for its friendliness. Real usage is the opposite of every one of those conditions — sustained, contended, and pointed at whatever server the service happens to use.
So the headline figure is not lying, exactly. It is answering a narrower question than the one you asked, and the gap between those two questions is where the frustration lives.
Almost everyone in this situation has already been told to run a speed test, seen a healthy number, and been left with nowhere to go — by their provider, by a support forum, and by the tool itself. The number becomes a dead end that quietly implies the problem is imaginary. Measuring the right things turns an unfalsifiable complaint into a specific, checkable one: not 'the internet is bad', but 'delay rises to four hundred milliseconds whenever anything uploads'. That is something you can act on, and something a provider has to engage with.
Because throughput and responsiveness are different properties, and only one of them is being measured. Three hundred megabits describes how much can move per second once data is flowing; it says nothing about how long each request waits before it starts, or how steady that wait is. Calls, games and page loads are dominated by waiting, not by volume — which is why they can degrade badly while the headline number stays magnificent.
Possibly, but this pattern usually has a duller explanation. Throttling normally shows as throughput capped near a consistent ceiling. What far more often causes this specific complaint is delay swelling under load, which is generated by queueing in your own equipment and is entirely fixable at home. Worth measuring before assuming bad faith.
Usually not, and this is the expensive mistake. If the cause is jitter, loss, a slow resolver or a swollen queue, a bigger plan changes none of them — you would be widening a road whose problem is the traffic light. Find out which measurement is wrong first; if throughput turns out to be genuinely inadequate, upgrading is then the right answer rather than a hopeful one.
That signature — a long pause, then everything arriving at once — is characteristic of name resolution rather than the connection. The wait happens before any content is requested, so the transfer that follows is perfectly fast. We time that step separately for exactly this reason, because it is the one most often blamed on the website.
Often it is not, and that is a useful finding. If your line measures clean while a single service misbehaves, the likely explanation is the route to that particular service or the service itself, neither of which is repaired by touching your router. Knowing this saves you from changing settings that were never the cause.
Measure what the speed test missed →
Signalyzr is a free, privacy-first network diagnostic tool made in India. Loading the diagnostic app…