Treat a speed test as an experiment with a specific route and moment. A repeatable protocol is more useful than a single impressive result.
Define the question first
Decide whether you are comparing Wi-Fi and cable, checking a problem period, or investigating a VPN. Each question needs controlled conditions. Comparing two services can illustrate route and method differences, but it cannot on its own establish that either service is wrong.
A repeatable procedure
- Record the device, connection, mode and approximate background activity.
- Run alternating measurements under the two conditions.
- Keep all valid results rather than selecting only the best run.
Explain uncertainty in your notes
Mark failures and missing metrics explicitly. Do not replace missing jitter with zero or treat a failed request as a valid low-latency sample. Use repeated results to guide troubleshooting and retain the application own diagnostics when investigating a particular game or call service.
Use the result without overstating it
Start with the DC SPEED connection test, choose the same mode for comparable runs and label the connection conditions yourself. The result panel separates idle latency from latency during download and upload. Its before-and-after view reports differences between compatible runs; it does not identify the cause automatically. History and CSV export let you keep a record without creating an account.
For a problem in a specific game, use the gaming diagnostic guide and the game own network statistics. Read the measurement methodology before comparing this tool with another service. These instructions are a troubleshooting workflow, not a report of laboratory experiments performed by the author.