Speedtest.net operates mainly over TCP testing with a HTTP fallback for maximum compatibility. Speedtest.net measures ping (latency), download speed and upload speed.

TCP Test Components

Latency/Jitter

1. This test is performed by measuring the time it takes for the server to reply to a request from the user’s client. The client sends a message to the server, upon receiving that message, the server sends a reply back. The round-trip time is measured is measured in ms (milliseconds).
2. This test is repeated multiple times with the lowest value determining the final result.

Download

1. The client establishes multiple connections with the server over port: 8080. The client requests the server to send an initial chunk of data.
2. The client calculates the real-time speed of the transfers, then adjusts the chunk size and buffer size based on this calculation to maximize usage of the network connection.
3. As the chunks are received by the client, the client will request more chunks throughout the duration of the test.
4. During the first half of the test, the client will establish extra connections to the server if it determines additional threads are required to more accurately measure the download speed.
5. The test ends once the configured amount of time has been reached.

Upload

1. The client establishes multiple connections with the server over the defined port and sends an initial chunk of data.
2. The client calculates the real-time speed of the transfers and adjusts the chunk size and buffer size based on it to maximize usage of the network connection, and requests more data.
3. As the chunks are received by the server, the client will send more chunks throughout the duration of the test.
4. During the first half of the test, the client will establish extra connections to the server if it determines additional threads are required to more accurately measure the upload speed.
5. The test ends once the configured amount of time has been reached.

HTTP Legacy Fallback Testing

Latency

1. This test is performed by measuring the time it takes to get a response for a HTTP request sent to the web server
2. This test is repeated multiple times with the lowest value determining the final result.

Download

1. Small binary files are downloaded from the web server to the client to estimate the connection speed
2. Based on this result, one of several file sizes is selected to use for the real download test
3. The test is performed with cache prevention via random strings appended to each download
4. Throughput samples are received at up to 30 times per second
5. These samples are then aggregated into 20 slices (each being 5% of the samples)
6. See bottom of document for details to fill here (see * below for more detail)
7. The remaining slices are averaged together to determine the final result

Upload Test

1. A small amount of random data is generated in the client and sent to the web server to estimate the connection speed.
2. Based on this result, an appropriately sized chunk of randomly generated data is selected for upload.
3. The upload test is then performed in chunks of uniform size, pushed to the server-side script via POST.
4. We’ll use up to four HTTP threads here, as well, to saturate the connection.
5. 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: Internet Explorer 7 (or earlier) and Firefox 2 (or earlier), the browser strictly adheres to the HTTP specification of only two threads per hostname. To scale up to four threads in these older browsers, 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.

How results are calculated

All samples are sorted by speed. The two fastest results are removed and hte bottom 1/4 which is left (which is approximately 22% of the total). Everything else is then averaged.