Speedtest.net operates entirely over HTTP for maximum compatibility. It tests ping (latency), download speed and upload speed.
- This test sends HTTP requests to the selected server, and measures the time it takes to get a response.
- Your computer downloads small binary files from the web server to the client, and we measure that download to estimate the connection speed.
- Based off this result, we choose how much data to download for the real test. Our goal is to pick the right amount of data that you can download in 10 seconds, ensuring we get enough for an accurate result but not take too long.
- We prevent caches from throwing off results by appending random strings to each download.
- Once we start downloading, we use up to four HTTP threads to saturate your connection and get an accurate measurement.
- Throughput samples are received at up to 30 times per second.
- These samples are then aggregated into 20 slices (each being 5% of the samples).
- The fastest 10% and slowest 30% of the slices are then discarded. We'll explain that more below.
- The remaining slices are averaged together to determine the final result.
Since we are measuring data transported over HTTP (via Flash), there are the following factors that can affect speed: potential protocol overhead, buffering due to the many layers between our application and the raw data transfer, and throughput bursting due primarily to CPU usage. These factors lead us to drop the top 10% and bottom 10% of our slices as outliers.
Additionally, we keep the default test length short for user experience. Because the test is shorter, the ramp-up period can take a significant part of the beginning of the test, leading us to drop another 20% of the bottom result slices.
- A small amount of random data is generated in the client and sent to the web server to estimate the connection speed.
- Based on this result, and appropriately sized chunck of randomly generated data is selected for upload.
- The upload test is then performed in chunks of uniform size, pushed to the server-side script via POST.
- We'll use up to four HTTP threads here as well to saturate the connection.
- Chunks are sorted by speed, and the fastest half is averaged to eliminate anomalies and determine the result.
Deciding the number of threads
Speedtest.net will use up to four http threads during the download and upload portions of the test. However, it will only use more than two threads if they are needed to accurately measure the speed, so as to minimize the effect of HTTP overhead on lower-speed connections. After the pre-test, if the connection speed is at least 4 megabits per second, then Speedtest.net will use four threads. Otherwise, it will default to two threads.
However, there is a hurdle on older browsers: on Internet Explorer 7 and earlier (as well as Firefox 2 and earlier), the browser strictly adheres to the HTTP specification of only two threads per hostname. So for those older browsers, in order to scale up to four threads we must open the third and fourth thread to a secondary URL provided by the host that points to the same server. This way, we can work around the limitations of those older browsers and still measure higher-speed connections accurately. Most of our hosts do have a working secondary URL, but if you're testing from an older browser to a host that doesn't, Speedtest.net will be limited to two threads at maximum. This is one reason why we recommend that all visitors use up-to-date browsers.