Measuring the true speed of a server from a web browser can be challenging due to several factors inherent in the way browsers operate. Browsers are multifunctional tools that not only fetch HTML content but also interpret and execute CSS and JavaScript, retrieve linked assets such as images and scripts, and render the final webpage. These additional tasks introduce complexities when attempting to isolate and measure a CDN or standalone server's raw throughput.

Here are some reasons why it is difficult to measure the true speed of a server accurately from a web browser:

Parallelized Loading: Browsers often employ parallelized loading strategies to fetch multiple resources simultaneously, aiming to improve page load times. This means that various elements, such as images, scripts, and stylesheets, may be fetched concurrently, making it challenging to attribute the timing of each to the server's performance.

Caching: Browsers cache resources locally to enhance subsequent page loads. Cached resources are retrieved from the local storage rather than the server, potentially skewing measurements and not reflecting the actual server speed.

Asynchronous Execution of JavaScript: JavaScript, which is commonly used for dynamic content and interactions, may execute asynchronously. This means that certain requests initiated by JavaScript might not be accurately timed or measured in relation to the initial page load.

Client-side Processing Time: After receiving server responses, browsers spend time processing and rendering the content on the client side. This processing time is not indicative of the server's throughput but contributes to the overall page load time.

To obtain a more accurate measurement of server throughput, it is recommended to use specialized tools that operate independently of the browser's intricacies. Tools like cURL or dedicated benchmarking applications allow for precise control over the timing and execution of requests. Which is where this tool comes in.

I used a low-level script in Golang to measure time in nanoseconds and calculate the bytes received within that time frame, to obtain a more reliable measure of the CDN or standalone server's performance in terms of throughput—bytes per second while requesting from Chicago, IL. This approach eliminates the confounding factors introduced by the browser's multitasking and hardware-accelerated nature to provide a clearer picture of the server's raw speed. The front-end was made entirely using vanilla js.