mission

Why this exists

I built Bufferbloat.org because I could not find the tool I wanted.

Most people are told to judge their internet connection by download speed. More technical users know to look at ping. Both are useful, but neither fully explains a question millions of people ask every day: why is my internet still laggy if I have hundreds of megabits per second?

A connection can deliver excellent throughput while video calls freeze, games stutter, websites hesitate, and remote desktops become frustrating to use. The problem is often not bandwidth. It is latency under load.

That is the problem Bufferbloat.org measures.

This gap has been known for years. In a 2011 ACM Queue discussion, Vint Cerf, Van Jacobson, Nick Weaver, and Jim Gettys discussed bufferbloat as a real weakness in how the internet is experienced and measured. The core lesson still matters: if you test only bandwidth or only idle latency, you miss how the network behaves when it is actually busy.

Networking researchers have understood this for years, and there are excellent research projects and commercial products in this space. But I was surprised by how few open, transparent, browser-based tools existed for measuring it.

I wanted a tool whose methodology anyone could inspect, whose implementation anyone could verify, and whose measurements anyone could improve. A test that measures not just how much data your connection can move, but how well it continues to respond while moving it.

Bufferbloat.org is an independent open-source project built around that principle. The code is open. The methodology is public. The limitations are documented. The goal is to make internet reliability easier to measure, easier to understand, and easier to discuss.

I have spent more than two decades working on internet products and infrastructure, and the same pattern keeps coming back: the web gets better when important systems can be inspected, measured, questioned, and improved in public. Bufferbloat.org is my attempt to apply that idea to internet reliability.

Because internet performance is about more than megabits per second.

01

Open core

The methodology and implementation are public so developers and researchers can inspect how the test works.

02

Loaded latency

The test focuses on reliability while a connection is busy, not only on idle ping or peak throughput.

03

Public method

Measurements should be reproducible, methodology should be public, and implementation should never be a black box.

References and project links