Bufferbloat, Explained: Why Fast WiFi Still Lags

A gigabit connection that turns into a slideshow the moment someone starts a download is not a contradiction. It is the single most common thing wrong with home networks, it has a name — bufferbloat — and it has nothing to do with how much bandwidth you’re paying for.

What bufferbloat actually is

Every router, modem, and ISP hop keeps a small queue of packets waiting to go out. That queue exists for a good reason: network links are not perfectly smooth, and a queue absorbs the bumps. The trouble starts when that queue is much bigger than it needs to be — sized for maximum throughput on a benchmark, not for a household video call.

TCP, the protocol behind almost everything you do online, only knows how fast to send by watching for signs of a full network. Traditionally that sign is a dropped packet: the queue is full, something gets thrown away, and the sender backs off. A too-big queue delays that signal instead of sending it. Packets keep queuing up rather than dropping, TCP keeps ramping up because nothing has told it to stop, and every packet — including your video call’s, your game’s, your DNS lookup’s — now has to wait behind a queue that can be seconds long. The connection isn’t slow. It’s just standing in a very long line.

Why it only shows up under load

An idle connection has an empty queue, so its latency looks great — 15, 20, 30 milliseconds, exactly what the distance to the server should cost. Start a large upload or download in the background and that same connection’s latency can jump to 500ms, 1,000ms, occasionally more, because now there’s a queue’s worth of somebody else’s packets in front of yours. This is why bufferbloat is so easy to miss on a normal speed test: a plain download/upload number never puts the link under sustained two-way load the way real use does, so the queue never fills.

The number that actually matters is not idle latency and it is not loaded latency in isolation — it’s the delta between them. A connection with 40ms idle and 60ms loaded (a 20ms delta) is basically fine. A connection with 15ms idle and 900ms loaded (an 885ms delta) is badly bloated, even though its idle number looked perfect a minute earlier.

How to see it in 30 seconds

Run a speed test that measures latency both idle and under load — this site’s Speed Test does exactly that, on purpose. Watch the loaded-latency number while the download and upload phases run. If it stays under about 15ms of the idle number, you’re clean — that is the A this site’s test grades it. Up to about 50ms is a B, and still perfectly usable. Into the hundreds of milliseconds is a D or an F, and that’s bufferbloat — and now you have a number to compare before and after any fix.

What actually fixes it

The real fix is a smarter queue on the device that owns the bottleneck link — almost always your router, occasionally your ISP’s modem or ONT if it does its own queuing. Modern queue management algorithms, fq_codel and its successor cake, actively manage queue depth instead of letting it grow unbounded: they keep just enough buffer to smooth out bursts and no more, and they give competing flows (your call, your download, your game) fair turns instead of first-come-first-served. Most routers running OpenWrt, and a growing number of stock consumer firmwares, expose this as “Smart Queue Management” or “SQM” — turning it on is usually the single highest-leverage setting on the entire router.

There’s a second, less obvious piece that matters just as much: SQM only works if it knows the real ceiling of your link. Setting a bandwidth limit slightly below your actual line rate — routers with SQM typically ask for this directly, something like 90–95% of your measured speed in each direction — moves the queue from your ISP’s uncontrolled equipment onto your own router, where the smart queue management can actually manage it. Without that limit, the biggest queue in the path might sit inside a piece of hardware you don’t control and can’t configure, and no amount of router-side tuning reaches it.

What does not fix it

A faster plan does not fix it. This is the myth this guide exists to kill: upgrading from 300 Mbps to a gigabit does not shrink an oversized queue, it just lets that queue fill up faster. Plenty of gigabit connections are more bloated than plenty of 100 Mbps ones, because bufferbloat is a queue-management problem, not a bandwidth problem — you can verify this yourself by running the loaded-latency test on a fast connection with SQM off and watching the delta anyway. Buying more speed to fix bufferbloat is like widening a road to fix a badly timed traffic light: it doesn’t touch the actual cause, and on some routers a faster plan makes the queue math worse, not better, because the router now has to buffer more data per second before SQM (if it’s even on) gets a chance to manage it.

One more place it hides: your own router’s queue, not just your ISP’s

It’s worth being specific about where the oversized queue usually lives, because “somewhere in the network” isn’t actionable. Most of the time it’s the router itself, or the modem right behind it — the device closest to the actual bottleneck, which for most home connections is the WAN link, not the WiFi. A router with no queue management at all will happily buffer megabytes of data it has no hope of sending out in a reasonable time, because nothing tells it not to. This is also why a mesh system or a repeater rarely fixes bufferbloat on its own: those devices sit on the WiFi side of the network, downstream of the actual bottleneck, and a clean WiFi hop in front of a bloated WAN queue is still a bloated connection.

Why this is the single biggest factor in your Sygnal Score

The Sygnal Score weighs six measurements, and bufferbloat — measured exactly the way described above, as the loaded-minus-idle latency delta — is worth 250 of the 1,000 total points, more than any other single block. Full credit at a 20ms delta or below, zero credit at 400ms or above, sliding linearly between. That weighting is deliberate: a connection that posts huge download and upload numbers but falls apart the moment it’s actually used — for a call, a game, anything real-time — is not a good connection, and a score built only from throughput would call it one anyway. Bufferbloat is where a fast-but-broken line gets caught.