VROOOMS Speed Test Methodology
This page summarizes how the shipped browser client measures network performance using this app’s own API routes. It avoids claims about third-party datacenters or backbone topology—only behaviors present in the repository are described here.
How download speed is measured
The client runs repeated GET requests to /api/test/download with a configurable payload size (the default client loop requests 1 MB per fetch). Each response is an application/octet-stream body with cache-control: no-store. The downloader aggregates bytes received for a timed window (implemented as roughly eight seconds in measureDownload), recomputing megabits per second as elapsed time grows, and returns an average Mbps over the full window.
How upload speed is measured
The client sends repeated POST requests to /api/test/upload with a fixed binary chunk (currently 512 KB per request in measureUpload) and Content-Type: application/octet-stream. The server reads the body and acknowledges with JSON. The uploader sums bytes sent for roughly six seconds, updating estimated Mbps while the window is open, then returns the average Mbps for the entire interval.
How ping (latency) is measured
The client issues multiple sequential fetches to /api/test/ping (with a cache-busting query parameter). Each round-trip time is recorded with high-resolution timestamps around the await; the reported “ping” is the median of those samples (defaults to ten iterations in measurePing), expressed in milliseconds.
How jitter is measured
Using the same ping samples, the client computes the standard deviation of the round-trip times and surfaces it as jitter (also in milliseconds). This highlights variability: two connections with similar medians can feel different if one has wide swings between samples.
Why VROOOMS uses HTTPS requests (not raw TCP)
Browser security models route measurements through standard fetch calls to your deployed origin—over HTTPS in production—which mirrors how web apps move data, including TLS handshakes and HTTP semantics. That choice ties results to “what a browser session can achieve on this path,” not to a separate synthetic protocol outside the web stack.
What affects your results
Everything on the path from the device that runs the test to the server can move the numbers: Wi‑Fi airtime versus Ethernet, VPN tunnels, other tabs or devices saturating upload or download, CPU load on the client, router firmware and buffer behavior, and Internet congestion at the time of the run. The public landing copy in this repo notes that complete runs move tens of megabytes or more depending on line speed—plan accordingly on metered connections.
How to get the most accurate result
Close heavy background transfers, test from the network you care about (wired baseline versus your real Wi‑Fi seat), pause VPNs when you want a direct ISP snapshot, and repeat at another time of day before treating a single run as definitive. For interpretation help beyond the raw mechanics, read what an internet speed test actually tells you.