BitSpeed Inspect Case Study Finds Our Own Homepage Waits 50 ms Longer for the First Byte

The first Inspect case study used a local test server, which is tidy but a little too easy. So we pointed the released binary at real sites on the public internet, including this one, and let it say what it saw. One of the findings was about us.

The runs came from two GitHub-hosted runners on October 21, 2026, one Ubuntu on x86_64 and one macOS on arm64. Each target got ten fresh-connection samples, one second apart. The workflow downloads Inspect 0.1.1 from the release, checks it against SHA256SUMS and commits every recording and report to the repository, so you can check each number below.

Same network, different wait

bitspeed.org and example.com both answer from Cloudflare addresses, and both negotiated HTTP/2. On the Ubuntu runner, connection setup took 31 ms for bitspeed.org and 27 ms for example.com at the median. That’s DNS, TCP and TLS, and it’s close enough to call the same.

Then the request goes out, and the two split. example.com sent its first response byte after 17 ms. bitspeed.org took 70 ms. The macOS runner tells the same story from closer by: 8 ms against 60 ms. The gap is about 50 ms both times, and it sits entirely in the wait for the first byte.

Inspect stops there, on purpose. Its report says that first-byte waiting includes more than server processing and doesn’t identify a cause. We can add what Inspect can’t see. Cloudflare doesn’t cache HTML pages by default, so a likely explanation is that bitspeed.org’s homepage goes back to its origin on every request, while example.com’s is served straight from the edge. It’s a lead worth checking. It isn’t a finding.

When Inspect refuses to compare

We asked compare to put example.com against bitspeed.org anyway. It printed every phase median and range, then blocked the verdict: the targets differ, the redirect chains differ and the page sizes differ, 577 bytes against 13,754. Two different sites aren’t a before and after. The numbers are still there to read, which is how the 50 ms gap above was found, but Inspect won’t call one site “faster”.

We also recorded bitspeed.org twice, a minute apart, with the other targets in between. Every phase came back inconclusive on both runners, because the two sets of ranges overlapped. The second run even reached a different Cloudflare address, and Inspect listed that as context. That’s the right answer. Nothing changed, and nothing should be claimed.

One bitspeed.org sample on Ubuntu took over four seconds to set up its connection. One. The median didn’t move, and the range shows it plainly instead of hiding it in an average.

The cost of a redirect

http://github.com/ redirects to HTTPS before anything useful happens. Inspect records each hop on its own. On Ubuntu, the plain HTTP hop spent 36 ms connecting and 33 ms waiting for the redirect, about 70 ms in all, before the HTTPS request had even started. On macOS it was about 40 ms. Most people never see that hop, because the browser follows it without saying anything.

What to take from it

Run against real sites, Inspect does what it did on the test server. It finds the interval where the time went, it keeps an odd sample visible without letting it skew the median, and it refuses a verdict when the comparison isn’t fair. Here it pointed at a likely fix for our own homepage. Whether a cache rule closes that 50 ms gap is a before and after, and that’s the comparison Inspect was built for.

Get it from the download page, or read how it compares with curl’s timing output.