Troubleshoot slow internet one variable at a time
A single speed result cannot identify a cause. Build evidence by repeating the same measurement after one controlled change.
Workflow reviewed July 10, 2026.
1. Define the observed failure
- Which application, site, or device is affected?
- Is the symptom low throughput, delay, disconnection, buffering, failed name lookup, or inability to reach one service?
- Does it occur continuously or only during recorded windows?
This distinction matters because a download-throughput test does not directly test DNS resolution, radio signal, application-server load, or every internet route.
2. Record a repeatable baseline
- Use one device and browser in one location.
- Pause avoidable local traffic and record the time.
- Run several tests and retain the median and spread.
- Record HTTP sample failures separately; do not call them packet loss.
The site's method page publishes its endpoint, stream counts, sampling windows, and formulas.
3. Separate WiFi from the upstream path
If the device supports Ethernet, repeat the same test with WiFi disabled and a known working cable. If Ethernet and WiFi differ under otherwise matched conditions, the comparison isolates a variable in the wireless/device path; it does not by itself identify interference, channel, access-point load, or hardware failure.
For WiFi-only testing, repeat at a fixed near-access-point location and at the problem location. Record the device and band reported by the operating system or router. A normal browser cannot read dBm, channel utilization, or nearby access points, so WiFiSpeedTest does not invent those values.
4. Separate one device from the whole local network
Repeat on a second device using the same connection type and location. Check the router's own status page for WAN state, link rate, connected devices, and vendor-reported errors. Device-specific and network-wide symptoms lead to different next tests, but neither outcome alone proves an ISP fault.
5. Check documented service state
Consult the ISP's official outage/status channel and the affected application's status page. If you restart network equipment, follow the manufacturer's documented procedure and capture before/after results; do not assume a restart fixed the underlying cause merely because one later sample improved.
6. Use the right diagnostic
| Question | Appropriate evidence | What this site can provide |
|---|---|---|
| Is browser-to-edge throughput changing? | Repeated tests with controlled conditions | Main speed test and browser-local history |
| Is RTT changing under load? | Idle and loaded timing to the same endpoint | Loaded HTTP RTT change, without a standardized grade |
| Is there IP packet loss? | An appropriate OS/network probe and its exact target/protocol | Not measured; HTTP failures are reported separately |
| Which routers are on the route? | Operating-system traceroute or a network diagnostic service | Not measured; the browser route page shows only device/edge context and edge RTT |
| Which recursive DNS resolver answered? | Resolver-specific test infrastructure | Not identified; the DNS page checks public egress consistency only |
| Is a public TCP port reachable? | A test from the required source network | Connection attempt from a Cloudflare edge, not from your LAN or device |
7. Escalate with evidence
Provide the ISP or vendor with timestamps, plan name, device and connection type, matched Ethernet/WiFi comparisons, repeated results, outage checks, and the exact affected application. Ask which test endpoint and procedure they accept for support or service-level review.