My connection becomes noticeably slower as soon as everyone is home, especially while I’m on video calls for my remote work. I’ve checked that the slowdown affects both wired and wireless devices, and restarting the router only helps briefly. How can I determine whether the cause is local congestion or the internet connection itself?
If the slowdown remains after every other device is disconnected, the bottleneck is probably the ISP connection rather than Wi-Fi or household traffic. Use this internet speed test tool from a wired computer with everything else paused, then repeat while the house is busy. Record download, upload, and ping rather than looking only at download speed.
Upload saturation is easy to miss. Cloud backups, security cameras, gaming updates, and video calls can fill the upstream bandwidth, causing high latency and making the whole connection feel slow. Check the router’s traffic or per-device bandwidth page during the slowdown. If one device is sending heavily, pause it or enable QoS and prioritize your work computer.
For a cleaner split between local and internet problems, transfer a large file between two wired computers while the issue is happening. If that local transfer stays fast but internet performance collapses, your LAN is fine and the WAN link is congested. If performance still drops with all other home devices disconnected, especially at the same evening hours, document several tests and take that evidence to the ISP.
7 Likes
If the line slows only when several people are active, congestion is likely; if wired devices choke during modest use, the router itself may be underpowered or overheating. I’d test with QoS disabled as well, since poorly configured traffic shaping can make video calls worse rather than better.
If the slowdown starts when someone begins cloud backups or large uploads, your video call may be losing out on upload bandwidth rather than download speed. Run Speedtest by Ookla during the quiet period and again when everyone is home, paying close attention to upload speed and latency under load.
A “wired” test can be misleading if the cable runs through a mesh satellite, powerline adapter, or Wi-Fi extender. Test a laptop connected directly to the main router, then directly to the modem or ONT if your setup allows it.
If the direct-modem test is fine during the busy period, @secureninja1843pro is probably right about the router being the choke point. If it still slows there, you have solid evidence of ISP-side evening congestion. Reconnect the router afterward since a computer plugged straight into the modem loses the router’s firewall protection.
A speed test during an actual work call will probably make the call worse, so use a test call or run the checks outside working hours. Speed tests deliberately fill the connection. They are useful evidence, but terrible background entertainment for a meeting.
The missing term here may be bufferbloat. When the household fills the upload or download pipe, the router queues too much data instead of dropping or pacing it. Raw speed can still look respectable while latency jumps and your video freezes. That fits the “fine until everyone gets home” pattern better than a simple Wi-Fi problem.
Generic QoS is hit or miss, as @secureninja1843pro said. If the router supports SQM, CAKE, or FQ-CoDel, try that instead. Set the managed rates slightly below the speeds the line can reliably sustain. Giving up a little headline speed often produces a much steadier call. If the router only offers vague presets like “gaming mode,” expectations should remain low.
For an immediate workaround, cap backup software, photo syncing, game downloads, and cameras during work hours. Reserving upload capacity usually matters more than assigning your laptop the highest priority. If that fixes it, you have a capacity-management problem. If it changes nothing, then the direct-router and ISP tests suggested above become worth the inconvenience.
Don’t keep hammering the connection with speed tests and expecting the download number to explain everything. Video calls care much more about packet loss, jitter, and latency, because apparently clear audio is too much to ask from a connection that looks “fast” on paper.
During the slowdown, run two continuous pings from the wired work computer: one to the router’s local address and another to a public IP. If both start spiking or dropping packets, the router or local network is struggling. If the router stays steady while the public ping goes bad, the trouble is beyond your LAN, either household traffic filling the connection or ISP congestion.
That test uses almost no bandwidth, so it can run during a call without making the problem worse. It also gives you something more useful than another screenshot showing a respectable download speed while everyone sounds robotic.
Nobody’s asked what kind of line you’re on, and that changes the whole diagnosis. Cable, DSL, and fiber fail in different ways at peak hours.
If it’s cable, your upstream is shared with the neighborhood on the same node. That means the ‘everyone is home’ slowdown might not even be your household. It can be the whole street loading the segment at 7pm. In that case you can pause every device you own and still see it get worse in the evening, which lines up with what @linux_kate78 said about taking evidence to the ISP. The catch is cable upstream is tiny to begin with, so one backup or one call plus the neighbors saturating the node hits harder than people expect. DSL has its own version of this on older gear, and fiber usually doesn’t unless the provider is oversubscribing badly.
I mostly agree with @0xsprite7 on watching latency instead of the download number, and the two-ping trick is the right move. It costs nothing and it runs during a call. That’s more honest than staring at a speed result. Speedtest by Ookla is fine for grabbing a quick upload figure and a baseline ping, but treat it as the opening check, not the verdict. It fills the pipe on purpose, so it tells you almost nothing about how the line behaves under real mixed traffic.
The bufferbloat point from @falcon6612 is the one I’d actually chase first, because it’s fixable on your end without waiting on the ISP. Before you touch SQM though, find out whether your router can even do it at your line speed. A lot of consumer boxes run CAKE fine at 100 down but choke the CPU past a few hundred, and then you’ve traded video freezes for a hard bandwidth cap and gained nothing. Check that ceiling before you spend an evening tuning managed rates.
One thing everyone skipped: if the wired test slows only during calls and never during a large download, look at your call app, not just the network. Some setups quietly route calls through a relay server that gets busy at peak, and no amount of QoS at home fixes a congested relay. Worth ruling out with a plain test call before you blame the pipe.
A call that only stutters when a backup fires is a bandwidth problem you can fix at home, but one that stutters with nothing else running usually means the relay or the ISP, and no QoS touches that. Speedtest by Ookla is fine for grabbing that first upload baseline, just don’t expect it to tell you which of those two you’re dealing with. The two-ping check @0xsprite7 mentioned sorts it faster than any download number.
The timing needs to be separated from the headcount. Does it slow down at roughly 6 p.m. even when nobody else is using the connection, or does it begin within minutes of phones and laptops arriving home? Those point to different causes, and “everyone is home” can hide a regular peak-hour ISP problem.
Watch the router’s WAN traffic graph before and during the change. If throughput jumps as people arrive, check for phones uploading photos, laptops waking and syncing, consoles downloading updates, or streaming boxes starting automatically. Those devices may be “idle” from the user’s perspective while still moving plenty of data. If WAN usage remains low but latency rises, household bandwidth probably is not the main issue.
For cable service, check the modem status page for increasing corrected/uncorrected errors or repeated connection events during the bad period. @0xsprite7’s ping test helps locate the boundary, but modem errors can explain why the public ping degrades even without heavy traffic. Record the exact time, WAN usage, modem errors, and whether the router ping stayed clean. That gives the ISP something more actionable than “it gets slow at night,” while avoiding random router upgrades before you know which side is failing.