Wi-Fi connected, status page green, yet pages crawl? Reachability and performance are different things. Here is how to tell which one is failing.
Every indicator says you are online: the Wi-Fi icon is full, the router lights are green, the provider's status page shows no outage, and a ping gets an answer. Yet pages crawl, calls break up and uploads stall. That gap is the whole subject of this post. A connection can be up and still be unusable, because "up" and "fast enough" are measured by different things.
Key Takeaways
- Reachability asks whether packets get there at all. Pings, outage maps and status pages answer that question, and nothing more.
- Performance asks how well they get there: latency, throughput and loss decide whether an application is usable.
- A degradation is invisible to an outage-shaped view by construction. M-Lab, the project behind the open NDT speed test, says it plainly: a network can stay reachable while rising latency or faltering throughput makes applications unusable.
- The fault is often somewhere along the path that neither end can see, such as a congested interconnect or a saturated queue.
- A single speed test cannot localize the fault, but four readings and a few quick comparisons tell you which kind of problem you have.
Reachability vs performance
Reachability is binary. Either a packet can get from you to a destination and back, or it cannot. A ping reply, a loaded status page and a green "connected" badge all prove only that: something answered.
Performance is a spectrum. It covers how long each round trip takes, how much data moves per second, how steady the delay is, and how much data goes missing on the way. An application does not care that a packet arrived eventually; it cares that it arrived soon enough, often enough and in a steady enough rhythm.
That is why a degraded connection can pass every reachability test. A video call needs round trips of well under a few hundred milliseconds. A ping that comes back in 900 ms is a perfectly good "yes, reachable", and a perfectly unusable call.
Why outage views cannot see slowdowns
Public internet observatories mostly track outages: networks or services becoming unreachable, with visible changes in routing or traffic. M-Lab's HERMES announcement points out that loss of connectivity is only one form of failure, and that a network "may remain reachable while rising latency or faltering throughput makes online applications unusable". Because those degradations do not remove connectivity, outage-focused tools can miss them. Catching them takes a different approach: measuring end-to-end performance rather than watching reachability and routing.
The same logic applies at home. Anything that only checks "can I reach it?" is built to say yes to a slow connection.
Where the problem actually sits
Your traffic crosses several segments on the way to a server: your device and Wi-Fi, your router, your provider's access network, interconnections between networks, transit, and finally the destination's own infrastructure. Each endpoint of a congested segment keeps reporting "up", because from its own point of view it is.
Typical places a connection can be up and degraded:
- Local Wi-Fi. Weak signal or interference adds retransmissions and delay, while the router light stays green.
- A saturated upstream queue. When something fills your uplink, packets wait in line. See bufferbloat for how oversized buffers turn a busy link into added latency.
- A congested interconnect or a distant peering point. Traffic to some destinations is slow while everything else is fine, and nothing on your side looks wrong.
- A busy or far-away server. The route is healthy; the far end is the bottleneck.
M-Lab's HERMES is built around exactly this problem. It takes user-initiated speed tests, groups them by access network, metropolitan area and test server, and, once a group has enough data (at least 25 tests from at least five distinct client IPs over the prior week), compares it with its own recent baseline, looking for the two signals of increased latency and reduced throughput. It then combines that with forward and, where available, reverse traceroutes to estimate whether a degradation sits in the access network, an interconnection, a transit network or near the destination. Its authors stress why the grouping matters: a single slow test may just be your Wi-Fi, your device or background traffic, whereas congestion in shared infrastructure shows up across many users at once.
What a speed test actually measures
M-Lab's NDT test is described as a single-stream performance measurement of a connection's capacity for bulk transport, reporting upload speed, download speed and latency metrics. Two things follow:
- A speed test measures the whole path from your device to a test server, not just your link. If the path to that server is congested, the result is poor even when your own line is healthy.
- It is a snapshot to one destination. It cannot tell you whether the fault is your Wi-Fi, your provider or an interconnection three networks away. Path delay is subtle enough that the IETF standardises how to measure it: RFC 7679, for example, defines a one-way delay metric.
The four readings that separate the cases
Four readings separate most cases. Match each one to a likely cause:
| Reading | What it shows | Pattern when it is the problem |
|---|---|---|
| Latency under load | Queueing delay | Fine when idle, jumps once the link is busy: a queue issue (bufferbloat) |
| Jitter | Stability of delay | Swinging values: an unstable link or wireless interference |
| Packet loss | Data that never arrives | Any sustained loss points at a faulty link or congested hop |
| Throughput | Capacity or congestion | Far below your plan, especially at the same time each evening: capacity or congestion |
BrowserInsight's network speed test reports download and upload throughput, latency and jitter, and also times connections to several major sites such as Google, YouTube and Netflix, which gives you more than one destination to compare. It does not report packet loss or loaded latency as separate numbers: the first step below shows how to get latency under load, and sustained loss usually surfaces as stalls and throughput well below your plan.
For what counts as a good value on each, see bandwidth vs latency vs jitter explained, and for the two consistency metrics in depth, jitter and packet loss explained.
A diagnostic sequence you can follow
- Compare idle and loaded latency. Run the speed test with nothing else running, then again while a large upload or download is in progress on another device or app. A big jump in latency means a queue on your own connection.
- Compare destinations. Look at the per-site latency checks in the speed test. If one or two destinations are much slower than the rest, the problem is along those paths, not at home.
- Compare wired and wireless. Plug into the router with a cable. If the cable is fine and Wi-Fi is not, the fault is local radio conditions.
- Repeat at different times. A slowdown that appears at the same hours daily suggests shared congestion rather than a fault in your equipment. If numbers move between runs, why speed test results vary explains normal variation.
An honest caveat
A client-side test cannot place the fault along the path. It can tell you that something between you and one server is degraded, and your comparisons can rule out your own Wi-Fi and queue. Pinning the problem to a specific interconnection takes aggregated measurements from many users plus path data, which is the gap projects like HERMES exist to fill. If your wired, idle tests are poor across several destinations, the evidence you have gathered is what to bring to your provider.
Frequently Asked Questions
Why is my internet slow but not down?
Because "down" means unreachable, while "slow" means high latency, low throughput, loss or unstable delay. A connection can deliver packets and still do it too slowly for the application you want.
Does a successful ping mean my connection is fine?
No. It shows the destination is reachable and gives one round-trip time. Latency under load, loss and throughput can still be poor.
Can the problem be outside my home?
Yes. A congested interconnect, an overloaded transit link or a busy server can degrade performance while your router and provider both report normal. Testing to several destinations helps show whether it is path-specific.
Is a single slow speed test proof of a network problem?
Not by itself. One slow result can come from your Wi-Fi, your device or background traffic. A pattern across repeated tests, destinations and times is much stronger evidence.
Conclusion
"Connected" only tells you packets can get through. Whether a connection is usable depends on latency, jitter, loss and throughput, and nothing that checks reachability alone can see those. Measure all four, compare idle with loaded and near with far, and you will know whether the fault is your Wi-Fi, your queue or somewhere further along the path.
Recommended Reading:
