Slow internet when the speed test says it's fine

You pay for 500 megabits. The speed test agrees: 480 down, 45 up, green all the way. And yet pages take three seconds to start loading, file transfers to the NAS crawl, and video calls stutter. Somebody in the house says "the internet is slow" and the speed test says they are wrong.

They are not wrong. The speed test is just answering a different question than the one being asked.

A speed test measures how fast a single well connected server can push a large amount of data to you over several parallel connections, right now, over a few seconds. Almost nothing you actually do looks like that. Loading a page involves a DNS lookup, a TCP handshake, a TLS handshake and dozens of small requests to different hosts. Copying a file to a local NAS never touches the internet at all. A video call cares about consistency, not peak throughput.

Why speed tests miss real slowness

Four blind spots, and all four are common.

They open several connections at once. Peak throughput is measured across parallel streams, which hides problems that only affect a single connection. A lot of real work, including many file transfers and API calls, runs on one connection.

They pick the closest, fastest server. Usually one inside your ISP's own network. That is a measurement of your last mile, not of the path to the services you actually use. Your ISP can look perfect to its own test server and still route badly to everything else.

They run for a few seconds. Long enough to find peak speed, too short to catch a problem that appears every 30 seconds.

They ignore the setup cost. A page that takes two seconds to start loading has usually spent that time on DNS and connection setup, not on transferring bytes. Throughput is irrelevant to that delay.

Split the problem: LAN or WAN?

This is the single most useful step and most people skip straight past it. If your local network is the bottleneck, nothing about your internet plan matters.

Run an iperf3 test against a machine on your own network. A laptop or NAS running an iperf3 server takes about a minute to set up, and the result tells you what your LAN is genuinely capable of, with no internet involved.

LAN result	Internet result	What to fix
Slow	Slow	Your local network. Wi-Fi, cabling, a switch, or an old device. The internet is not involved.
Fast	Slow	The connection or the route out. Now it is worth talking to your ISP.
Fast	Fast, but things still feel slow	Setup latency: DNS, TLS, server response time, or a path problem like MTU.

If your Wi-Fi tops out at 90Mbps because a device negotiated a slow rate, you will never see your 500Mbps plan no matter what the speed test on a different device reports.

# What is my LAN actually capable of?
https://netdebug.app/open/iperf3?target=192.168.1.50&port=5201&duration=20&direction=download

# Latency, jitter and throughput to the internet in one pass
https://netdebug.app/open/speed?download=32&upload=8

The six things that are usually responsible

1. Slow DNS

Every hostname a page references needs resolving before anything can be fetched, and a modern page can touch a dozen hosts. If your resolver takes 300ms to answer instead of 15ms, that delay lands at the front of everything and compounds. Slow DNS feels exactly like a slow connection and is completely invisible to a speed test, which resolves one hostname at the start and then measures bytes.

Run a DNS Lookup against your normal resolver, then against 1.1.1.1, and compare the response times. If your router's forwarder is ten times slower, you just found your problem.

2. Bufferbloat

When a link fills up, packets queue instead of being dropped, and the queue can be enormous. Latency goes from 20ms to several hundred milliseconds while throughput stays high. Everything interactive feels dreadful while the speed test posts a great number, because the speed test is the thing filling the buffer.

Test it: run a continuous ping, then start a large upload. If latency climbs from 25ms to 300ms and recovers when the upload ends, that is bufferbloat, and smart queue management on the router fixes it properly.

3. Wi-Fi, not the internet

Signal strength, band, channel congestion and client capability all cap your real speed well below what the line delivers. An older device that only supports 2.4GHz, a channel shared with six neighbours, or a laptop three rooms away will each produce "slow internet" that has nothing to do with your provider. Comparing the same test on Ethernet settles it in one minute.

4. The server on the other end

Sometimes the site is just slow. An HTTP(S) Check shows the status code, the redirect chain and how long the request took. A page that redirects four times before reaching content is spending a full round trip on each redirect, which on a 120ms path is half a second wasted before a single byte of content arrives.

5. Path MTU problems

This one produces the strangest symptoms: small requests work instantly, large transfers hang and then time out, and the pattern repeats reliably. It happens when something along the path cannot carry full sized packets and the "packet too big" messages that would normally fix it are being blocked. VPNs and PPPoE connections are the usual context.

Path MTU Discovery finds the largest packet that actually makes it through. If the answer is well below 1500, you have an explanation for a lot of odd behaviour.

6. Something else on the network is eating everything

A console downloading a 90GB update, a cloud sync working through a photo library, a security camera uploading continuously. A LAN Scan at least tells you how many devices are actually connected, which is often more than people expect.

Measuring the right thing

Instead of one speed test, collect four numbers that describe how the network behaves rather than how fast it can burst:

• Idle latency to a fixed target, as a baseline.
• Latency under load, measured while something is uploading. The difference between the two is your bufferbloat.
• Jitter, which predicts call quality far better than throughput does.
• DNS response time, which sets the floor on how quickly anything can start.

Chain those into a single automation and run it when things feel slow and again when they feel fine. The comparison is where the answer lives. Run History keeps every result and charts them, so "it was slow last Tuesday evening" becomes a data point instead of a memory.

The short version

A good speed test result does not mean a good network. Test your LAN separately from your internet, because a Wi-Fi bottleneck makes your plan irrelevant. Check DNS response time, check latency while the link is busy, and check whether large packets survive the path. Those four numbers explain almost every case of "fast connection, slow internet."