A 106 Millisecond Ping Spike Sent Us Chasing the Wrong Provider

Pages that offered both a newer and an older address made our browser try the newer road first, and that road had a locked gate at the adapter. The browser waited out one failed attempt before it fell back to the older road that worked. A modern page asks for dozens of pieces, and each font, script and picture paid that same wait again. Pages that used only one road loaded fine, which is why a few sites looked frozen while the rest of the web behaved normally. One music site let us reproduce it at will.

The complaint, and the wrong suspect

It started with a familiar kind of complaint: the internet felt unstable. A site would sit there, loading and loading, while other pages opened just fine. The music site made the problem easy to repeat, but it was not the only one. We could visit much of the web, then hit one of these pages and wait until our patience ran out.

So we did what most people would do. We checked whether the connection was dropping. It was not. We checked whether the computer could find website addresses quickly. It could. We checked whether it could make a basic connection to a secure website. That worked quickly too.

The tests gave us a clean report. There was no packet loss in a 30-check run. The connection speed jumped around more than we liked, with some checks taking as long as 106 milliseconds, but it was not losing traffic. That pointed toward the internet provider, or at least made it tempting to blame the provider.

That was the costly part. We spent time following a clue that sounded reasonable because the numbers looked unusual. We also kept treating the stalled pages as a vague outside problem.

The second road system

The answer was IPv6, one of the newer ways computers are given an address on the internet. Think of it as a second road system. Many websites publish both an older address and a newer address, and a browser often tries both paths so it can use the one that gets there first.

That race has a cheerful technical name, Happy Eyeballs. It just means the browser tries two possible routes at nearly the same time rather than betting everything on one. When both roads work, nobody notices. In our case, the newer road was written down on the map, but the computer had no route onto it.

So each time the browser reached a website that offered both choices, it tried the unusable road first. The attempt went nowhere. Only after waiting for that failure did it fall back to the route that worked. One delay might be annoying but manageable. A modern page is not one request, though. It asks for many little pieces: pictures, fonts, scripts, buttons, and information from other places. Every piece paid the same wait-then-try-again cost. The page could look frozen even though the underlying connection was fine.

That explained why the earlier checks had missed it. We had tested the older road directly, and it was healthy. The browser was doing more work than our simple tests. It was choosing between roads again and again while building the page.

A checkbox that only did half the job

The next question was how our computer ended up in this half-working state. Years earlier, we had opened the network settings and unchecked a box that said we did not want the newer road on our Wi-Fi connection. We thought we had turned it off.

We had not. We had only closed one lane at the driveway.

The computer still saw the newer road listed in the map book. It still offered that road to the browser. But the adapter, the part that lets the computer talk over Wi-Fi or a cable, was no longer allowed to carry that traffic. It was like telling a delivery driver that a bridge exists, then putting a locked gate in front of it. The driver keeps trying the bridge, loses time at the gate, and eventually takes the other way around.

Four quick checks made the picture clear. Websites were still giving the computer the newer kind of address. The computer had no general route to reach those addresses. A test to a public address on that route failed. And the browser kept trying it before coming back to the route that worked. The provider was not the source of the fault. It was a setting we had changed long ago.

The fix

Tearing the newer road system out of the computer could break other things that use it inside a private network, so we did not go that way. Instead, we changed a Windows setting that tells the computer to prefer the older road for ordinary internet trips while leaving the newer one available when something specifically needs it. That setting only takes effect after a restart.

After the restart, the stalled pages opened normally. The change was small. Finding the right question took much longer.

When pages stall while basic network tests look healthy, check whether the browser is waiting on a route the computer cannot use before blaming the provider. The 30 checks, with the slowest at 106 milliseconds, never measured the delay that froze the pages. That delay was one failed attempt on the newer road, paid again for every font, script and picture before the browser fell back to the older one.

dxdev LESSON · paste into your AI coding agent
LESSON: A green result on a narrow test doesn't rule out a browser doing more work than your test covers
SOURCE: dxdev.com/everyday-ai/one-checkbox-that-made-the-web-feel
WHAT HAPPENED: Intermittent page hangs were traced past clean connectivity, DNS, and TLS tests to IPv6 Happy Eyeballs: a years-old unchecked Wi-Fi setting had left IPv6 addresses advertised but unroutable on the network adapter, so the browser, which races IPv6 and IPv4 in parallel per request, wasted a full timeout-then-retry cycle on every single asset on a page, invisible to the simple single-connection diagnostic tests that had been run and come back clean.
THE RULE: A clean result on a narrow diagnostic test, a single connection check, doesn't rule out the actual failure mode, because a browser loading a real page performs more complex, repeated connection logic, such as racing multiple protocols per asset, that a simple test never exercises. Reproduce the actual behavior, not a simplified proxy for it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any network or connectivity diagnostic that tests a single request or connection type when the real failure occurs during a browser's more complex per-asset connection logic, such as dual-stack racing.
  2. Any system setting, a checkbox or a toggle, assumed fully disabled based on its label, without verifying its actual effect at the protocol or routing level.
  3. Any intermittent performance issue blamed on an external party, such as an ISP, before confirming the local environment's connection behavior differs from what a simple test measured.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.