Inspect on BitSpeed.org

BitSpeed Inspect Case Study Traces a 180 ms Slowdown to First Byte Wait

Tue, 20 Oct 2026 00:00:00 +0000

Here’s the situation. A request feels slow. Someone changes something, and it feels faster. Was it the connection, the server’s first response, or reading the body? A single total won’t tell you, and a second total won’t either.

This case uses the saved recordings in the BitSpeed repository’s examples folder. They were made with the released Inspect binary against a local test server on loopback. The “before” server held its response headers for 200 ms. The “after” server held them for 20 ms. Everything else stayed the same: same URL path, same request settings, three fresh-connection samples each.

BitSpeed Inspect Explains HTTP Transfers and Compares Saved Runs

Tue, 20 Oct 2026 00:00:00 +0000

A slow request gives you a duration. The next question is where that duration came from, and whether the same interval changed after you adjusted something. BitSpeed Inspect records the client events behind one HTTP transfer and turns them into an explanation you can revisit.

Inspect 0.1.1 is available as an independent Go command. It saves JSON, explains one recording and compares two sets of samples. Transfer has its own release and delivery checks, and neither command depends on the other.

How BitSpeed Inspect and Transfer Were Tested

Tue, 20 Oct 2026 00:00:00 +0000

Each tool makes one main promise, and the tests go after that promise first. Inspect promises to explain where observed request time went without inventing a cause. Transfer promises that an interrupted file transfer resumes from verified pieces and ends in one complete, checked file. Happy paths are covered too. They just aren’t where the effort went.

Every push to main runs the full suite on Linux and macOS: formatting, go vet, race-enabled tests, both command builds and smoke checks against the built executables. The outcomes are written to recorded results with the Go version, platform and a fingerprint of the source tree.

HTTP Transfer Timing Needs More Than a Stopwatch

Tue, 20 Oct 2026 00:00:00 +0000

Two HTTP requests can take the same total time for very different reasons. One may spend most of its observed interval establishing a connection. Another may receive its first response byte quickly and then spend longer reading the body. A stopwatch hides that distinction.

Inspect records trace events and keeps the interval boundaries explicit. Some events can be missing or ambiguous. Concurrent connection attempts also make a neat additive waterfall less honest than it looks. The report leaves unavailable values unavailable instead of filling them with zeroes.