How to diagnose a slow internet connection

"The internet is slow" is a symptom with at least six distinct causes, and the reason most people fail to fix it is that they test randomly instead of eliminating layers in order. This guide is a diagnosis workflow: each step isolates one segment of the chain (device → Wi-Fi → router → ISP → remote service) and tells you whether to stop there or move on.

One distinction up front, because it decides which tests matter: slow can mean low bandwidth or high latency, and they feel different. Downloads crawling and video buffering is a bandwidth problem. Pages taking ages to start, video calls lagging, typing in SSH feeling delayed: that's latency, and a speed test will look fine while everything feels broken. If your symptom is the second kind, the companion guide on testing network latency goes deeper on measurement; this guide covers the full elimination workflow for both.

Step 0. Define "slow" with one number each

Before changing anything, capture a baseline so you can tell whether later steps helped:

ping -c 20 1.1.1.1

Note the average RTT, the mdev (jitter), and the packet loss line. Then run your ISP's speed test or any reputable one and note down/up throughput. Two minutes, four numbers. Also confirm which connection you're actually on: What's My IP shows your public IP and ISP, which catches the surprisingly common case of a VPN or hotspot you forgot you were using. A VPN routes all traffic through an extra detour; turn it off for the rest of this diagnosis.

Step 1. Is it one device or all of them?

Test the same things from a second device on the same network.

• Only one device is slow → the network is fine. Look at that device: background uploads (cloud backup, photo sync, OS updates), a misconfigured DNS setting, an old 2.4 GHz-only Wi-Fi adapter, malware, or simply a saturated disk. Check the device's own network activity monitor for what's consuming the link.
• All devices are slow → continue down the chain.

Step 2. Is it Wi-Fi?

Wi-Fi is the single most common culprit, and the test is simple: plug a laptop into the router with an Ethernet cable and repeat your Step 0 measurements.

• Wired is fast, Wi-Fi is slow → it's the radio link. Usual causes, in order: distance/walls between you and the access point, congestion on 2.4 GHz (switch to 5 GHz), channel overlap with neighbors, or too many clients on one AP. High jitter in your ping output with a decent average is the classic Wi-Fi signature.
• Wired is also slow → Wi-Fi is innocent. Keep going, and do the remaining steps over the wired connection so you're testing the actual line.

Step 3. Is it something on your network eating the line?

A connection at full capacity behaves exactly like a broken one, and it also gets high latency, because saturating the link fills your router's buffers (bufferbloat) and every other packet waits in that queue. This is why "internet is slow" so often coincides with someone uploading video, a cloud backup running, or a console downloading a 90 GB patch.

Two checks:

1. Your router's traffic/client page (most show per-device usage). Find the device moving the bytes.
2. The bufferbloat test: run ping 1.1.1.1 continuously, then start a large upload. If RTT jumps from ~15 ms to hundreds while the upload runs, your router queues badly under load. The fix (smart queue management) is covered in how to reduce network latency; it makes a saturated line stay responsive instead of unusable.

If usage looks idle and loaded ping is sane, keep going.

Step 4. Is it DNS?

DNS failures masquerade as slowness in a specific way: pages stall for seconds before anything happens, then load at normal speed. Bandwidth and ping tests look perfect because they don't involve name resolution.

Time a lookup against your current resolver and a known-fast public one:

dig example.com | grep "Query time"
dig example.com @1.1.1.1 | grep "Query time"

If your resolver takes hundreds of milliseconds (or times out and retries; that's the multi-second stall) while 1.1.1.1 answers in tens, switch your router's DNS to 1.1.1.1 or 8.8.8.8. You can verify what a name resolves to with the DNS Lookup tool, and how to perform a DNS lookup walks through interpreting results.

Step 5. Is it your ISP?

You're now wired, the LAN is quiet, DNS is fast, and it's still slow. Time to test the line itself.

• Throughput vs what you pay for. Run a speed test wired, with everything else idle. Getting 250 Mbps on a 500 Mbps plan once is noise; getting it on every test across several days is a ticket.
• Time-of-day pattern. Re-run the ping and throughput tests in the evening peak (roughly 8-11 p.m. for residential lines) and compare to mid-morning. Fine at 10 a.m., bad at 9 p.m., every day → congestion in your ISP's segment. That's also a ticket, with your timestamps as evidence.
• Where does the path degrade? Run mtr --report --report-cycles 50 1.1.1.1 (or traceroute). Loss or a latency jump that starts at hop 1-2 and persists to the destination points at your modem, line, or the ISP's first-mile equipment; for cable/DSL, that includes physical issues like a degraded line or connector. Attach the report to your support ticket; it's the difference between "customer says it's slow" and an actionable fault report.

Reboot the modem/router once before calling, not as superstition, but because it forces the modem to retrain the line and clears genuinely wedged state.

Step 6. Or is it just that site?

If most of the internet is fast and one service is slow, your connection was never the problem. Confirm:

• Run the Ping Test against the slow service's hostname; this measures from our infrastructure, not your network, so a bad result there means the problem is on their end (or the path to them), not yours.
• Check response headers with the HTTP Header Checker; a slow time-to-first-byte from an origin with no CDN in front of it is the site's architecture, not your line. Big CDN-fronted sites being fast while a small self-hosted site is slow is the normal state of the internet: you're reaching a nearby edge node for one and a single distant origin for the other.

If it's a service you operate, stop diagnosing it by hand on demand: a website uptime monitor records availability and response time continuously, so the next "is it slow right now or always?" question is answered by a graph.

The decision tree, compressed

TL;DR

1. Baseline first: ping -c 20 1.1.1.1 plus a speed test. Kill the VPN.
2. One device or all? One → fix the device.
3. Ethernet vs Wi-Fi. Wi-Fi-only slowness → fix the radio, done.
4. Check for a saturating device and test ping under load (bufferbloat).
5. Time DNS lookups; switch resolvers if yours is slow.
6. Still slow wired and idle → mtr report + timestamps → ISP ticket.
7. Only one site → test it from outside with Ping Test; it's probably them.

Related

• How to test network latency: deeper measurement of RTT, jitter, loss, mtr
• How to reduce network latency: the fixes, once you know the cause
• DNS Lookup tool: check resolution when pages stall before loading