A list of speed results is easy to make and surprisingly difficult to use. The fastest row is attractive, but you may not remember its destination, the connection state or the background activity. A useful testing notebook keeps enough context to let tomorrow’s reader understand today’s result. That reader is often you.
Write the question first
“Which route is best?” is too broad for a short experiment. Try “Does this route complete the same download more consistently this evening?” or “Does voice remain usable during a household upload?” A narrow question helps choose a measurement and a stopping point before the numbers begin to influence your expectations.
Decide how much data and time you can spend. Use bounded requests rather than an endless transfer, especially on a shared or metered connection. Choose a small number of planned attempts. Do not keep repeating the test until a preferred route finally wins.
Keep the comparison symmetrical
Use the same endpoint, requested payload and timing method. If you compare one stream with four streams, keep the total transferred amount visible. Four simultaneous small requests are a different workload from four copies of a large request. Record both stream count and bytes per stream so the distinction survives.
Also record whether the measurement includes connection setup. A whole-request result answers how long that task took from the beginning. A body-only result describes a smaller interval. Both can be useful, but a table should not silently mix them or label either as an unlimited, permanent capacity.
Give failure its own column
An HTTP refusal, a certificate error and a timeout are different outcomes. Record the category without turning every failure into a zero-speed result. A service that refuses a request has answered a question about that request; it has not supplied a successful transfer measurement.
Keep an unexpectedly slow run too. Note what happened without assigning blame from one sample. A later success belongs on the next line, with a new timestamp. If the endpoint or settings changed, mark the boundary rather than presenting the two attempts as identical.
Finish with a decision and a limit
A good notebook entry ends with a modest decision: use route A for the next ordinary session, investigate route B’s repeated setup failures, or leave the setting unchanged because the evidence is mixed. Add the practical limit: one device, one location, a short window, or no test during peak household use.
This approach is less dramatic than publishing a giant winning number. It is much more useful when something breaks later. You will have the original conditions, the failed attempts and a clear explanation of why the previous choice made sense.
