Why is my broadband slow? Run the five-minute fault test and match the result to the correct network layer before replacing equipment. The limit may be Wi‑Fi, the device, router, broadband line or provider path.
Slow broadband troubleshooting
Start with one controlled Wi-Fi and Ethernet comparison. The result should tell you whether to work on the room, device, router, broadband line or provider path.
Start here
Keep the device and test server consistent. Change one variable at a time so each result removes a possible cause instead of creating another guess.
Do not compare unlike results. A phone beside the router, an old television on 2.4 GHz and a wired desktop are testing different hardware paths. Use the matrix below to interpret the controlled result.
Recommended tests
Use the same device and location for each comparison. Download speed alone can hide packet loss, upload saturation and loaded-latency problems.
Result-led diagnosis
This single matrix replaces separate Issue, Likely Cause, Validate and Fix sections. Each card combines the symptom, the controlled check and the next action.
Boundary: room-level signal, interference, band choice, router placement or the wireless capability of the device.
Confirm: compare the same device beside the router and in the affected room, then compare 5 GHz with 2.4 GHz.
Open the Wi-Fi and device checks →Boundary: that device, browser, adapter, CPU, storage or a 100 Mbps network interface.
Confirm: test a second modern device in the same place and on the same connection type.
Check device and link-speed limits →Boundary: router queues, an exhausted upload path or insufficient processing headroom for traffic management.
Confirm: pause the heavy transfer and run the loaded-latency test.
Run the LinkSpeed Bufferbloat Test →Boundary: household demand, access-network capacity, exchange congestion or a wider provider path.
Confirm: run one controlled morning-versus-evening Ethernet comparison with household traffic paused.
Open the dedicated evening-slowdown workflow →Boundary: DNS lookup delay, a service-specific CDN path, app state or provider interconnection.
Confirm: compare several sites, another streaming service and repeated resolver tests.
Open the DNS and content-path checks →Boundary: 100 Mbps Ethernet negotiation, low router sync, DLM profile, line fault or package limit.
Confirm: compare device link speed, router line rate and repeated wired tests.
Interpret speed, sync and link rate →Speed and line interpretation
A low result can be caused before the broadband line, inside the router, at the Ethernet or Wi-Fi interface, or by the test device itself. Compare the layers rather than treating one browser result as the line speed.
| Negotiated device link | Typical practical speed-test ceiling | What the result means | Next controlled action |
|---|---|---|---|
| 100 Mbps | About 90–95 Mbps | A Fast Ethernet port, damaged cable, two-pair cable or older adapter is capping the test before the broadband line. | Try another gigabit port and known-good Cat5e/Cat6 cable, then confirm the operating-system link rate. |
| 1 Gbps | About 900–940 Mbps | This is the correct control link for most UK packages up to roughly 900 Mbps. Lower results still need comparison with router sync and processing load. | Keep this wired setup unchanged while testing router features, line rate and provider performance. |
| 2.5 Gbps | About 2.2–2.4 Gbps | A multi-gigabit port, cable and capable test device are required to validate packages above 1 Gbps. | Confirm both router and device ports negotiate at 2.5 Gbps and that the test device can process multi-gigabit traffic. |
| Wi-Fi link rate | Variable and usually well below the displayed PHY rate | Wireless link rate is not the same as usable internet throughput because airtime, walls, interference and protocol overhead reduce it. | Use Ethernet as the broadband-line control, then troubleshoot the affected room or device separately. |
The limit is likely in router processing, local cabling or the test hardware. Disable only non-essential traffic-processing features and compare a modern wired device.
The physical access line, DLM profile, package or provider configuration is limiting the connection before local Wi-Fi. Keep the line stable and collect sync and error evidence.
File transfers often use megabytes per second rather than megabits. Eight bits equal one byte, so a 100 Mbps service is roughly 12.5 MB/s before overhead and server limits.
The smaller upstream path may be saturated. Pause backups, cameras and synchronisation, then retest upload and loaded latency.
Avoid repeated router reboots on an unstable FTTC line. Dynamic Line Management can react to repeated drops by applying a more conservative profile. One controlled restart is different from repeatedly interrupting the line.
Local connection limits
Use the Ethernet result as the control. If the wired connection is healthy, keep the broadband package unchanged while you improve the affected room, band or device.
5 GHz and 6 GHz can provide high throughput but weaken faster through brick, foil-backed insulation, mirrors and metal objects. A device may fall back to 2.4 GHz or repeatedly retransmit damaged frames.
Action: improve router placement, compare a dedicated band only when steering is unstable, or use a correctly positioned mesh node with a strong backhaul.
Many phones, laptops and televisions use two spatial streams or older radio chipsets. A fast router cannot make a limited client exceed its own antenna, channel-width or processing capability.
Action: compare a current phone and the affected device in the same location before replacing the router.
Slow 2.4 GHz and older Wi-Fi clients occupy shared airtime for longer. This matters most on a busy channel, but one legacy device does not automatically slow every radio band.
Action: move capable devices to 5 GHz or 6 GHz and keep IoT devices on a separate 2.4 GHz network where practical.
Old CPUs, overloaded browsers, extensions, power-saving modes and 100 Mbps adapters can under-report the available line speed.
Action: close heavy applications, use another browser or native app, confirm adapter link speed and compare a second modern device.
Only one room is affected? Use the one-room Wi-Fi fault workflow before buying a faster broadband package.
Router capacity and household load
Device count alone does not prove that a router is overloaded. Concurrent flows, cameras, cloud uploads, traffic monitoring, SQM and Wi-Fi airtime can matter more than the headline number of connected devices.
| Household pattern | What to prioritise | Validation |
|---|---|---|
| Light use with a few active devices | Current firmware, gigabit Ethernet and stable dual-band Wi-Fi. | Check whether speed and loaded latency remain stable during normal use. |
| Busy connected home | CPU and memory headroom, airtime handling, guest or IoT isolation and sufficient upload capacity. | Monitor CPU, memory, connection count and loaded latency during the actual busy period. |
| Dense smart home or fast full fibre | A routing platform that can sustain the required throughput with any enabled SQM, VPN, parental-control or monitoring features. | Compare raw wired throughput with those features off and on, changing one setting at a time. |
Every tracked TCP or UDP flow uses a connection-table entry. Peer-to-peer software, cameras and many browser tabs can create far more concurrent flows than the device count suggests.
Backups, CCTV and synchronisation can fill the smaller upstream path. Downloads then slow because acknowledgement and control packets cannot leave promptly.
Deep parental controls, VPNs, traffic monitoring and software SQM can move work onto the main CPU. A router may route at gigabit speed without sustaining gigabit software shaping.
Linux uses spare RAM as cache. Judge pressure with MemAvailable, swap or out-of-memory logs and service stability rather than MemFree alone.
Use these commands only when ordinary wired, Wi-Fi and household-load tests point to router resource pressure.
free -mcat /proc/meminfocat /proc/sys/net/netfilter/nf_conntrack_countcat /proc/sys/net/netfilter/nf_conntrack_maxlogread | grep -i -E 'oom|out of memory|conntrack'Latency rises mainly under load? Use the hardware acceleration and SQM CPU audit before replacing the router.
DNS and content paths
DNS delay occurs before the main connection opens. CDN or peering congestion is destination-specific. Test these separately so a slow first page request is not confused with a slow broadband line.
A resolver translates a hostname before content loads. Cached answers can return almost instantly, so compare several hostnames and repeated lookups rather than relying on one result.
Cloudflare, Google or another public resolver may be faster from one network and slower from another. Test one device first before changing the whole router.
If one platform degrades during a live event while other services and general wired tests stay healthy, the path may involve the service, its cache or provider interconnection.
Intermediate routers can ignore or rate-limit probes. A silent hop is not proof of loss when later hops respond normally.
Measure-Command { Resolve-DnsName www.google.com }dig www.google.comdig @1.1.1.1 www.google.comdig @8.8.8.8 www.google.comIf every page pauses before loading, repeat resolver tests with multiple hostnames.
If only Netflix, YouTube or BBC iPlayer is affected, use the service-specific guide rather than treating it as a general line fault.
This removes Wi-Fi and makes a recurring service-path slowdown easier to separate from one isolated event.
Test the alternative on one device, confirm normal service behaviour, then consider a router-wide change.
Use it on one device first and check reliability before changing the entire home network.
Collect timestamps and wired comparisons. The issue may be the service, CDN cache or provider interconnection.
Return to the speed, router and provider checks because the problem is broader than DNS or one content path.
Focus on resolver delay, browser state and device processing before changing the broadband package.
Line and provider escalation
Remove Wi-Fi from the conversation and give the provider a repeatable pattern. One low wireless result is not enough to distinguish a home-network problem from a line or capacity fault.
Capture the downstream and upstream values, connection uptime and relevant error counters where the router exposes them.
Use the same gigabit-capable device and cable at different times, including the period when the slowdown normally happens.
Stop backups, uploads, cameras and updates so the provider cannot reasonably attribute the result to local demand.
Run one controlled comparison here. For multi-day peak and off-peak logging, use the dedicated evening broadband workflow.
State whether router sync is low, Ethernet is slow while sync is healthy, several services fail, or only one destination is affected.
Ask the provider to inspect the physical line, profile, DLM history and Minimum Guaranteed Speed position.
Provide timestamped wired results and ask for an investigation into backhaul, exchange or traffic-path capacity.
Continue with the evening slowdown evidence guide rather than duplicating that longer workflow here.
The incoming line is not the first fault boundary. Continue with room, device and router-placement checks.
Keep wording precise: ask the provider to investigate a repeatable wired slowdown or low line rate. Avoid claiming cabinet, exchange or peering congestion until the evidence isolates that layer.
Frequently asked questions
These visible answers match the FAQ structured data in the page head.
Run a speed test beside the router, repeat it over Ethernet, pause household uploads and downloads, then compare another device. These checks separate Wi-Fi, device and router-load problems from a slower incoming line.
A large Wi-Fi versus Ethernet difference points to local radio conditions, router placement, wall attenuation, interference, band selection or the wireless capability of the affected device rather than the broadband line.
Heavy transfers can fill the router or access-link queues, especially the smaller upload path. This delays browsing, calls and acknowledgement traffic even when the package has adequate headline download speed.
Contact the provider when repeated Ethernet tests remain below the expected range, router sync or line rate is low, the slowdown affects several devices, or timestamped peak-time evidence shows the problem beyond the home network.