With the changing landscape of connectivity types and increased utilization of privacy proxies and VPNs it has never been harder to understand which parties are able to observe your online activity, where performance bottlenecks may exist, and if your IP address is correctly representing the geographical location that you expect.
The purpose of this test page is help answer those questions, namely
What is the maximum throughput that can be sustained between your client and a test server?
Is this performance affected by the usage of a MASQUE proxy (if in use)?
What location-based information can be deduced based upon the public-IP address your client presents to an origin?
We have a couple of non-goals too. This page does NOT replicate the playback of segmented media or web site delivery or game downloads, therefore results obtained should not be translated to those application spaces.
What is the duration of each download test?
Each test lasts for the minimum of 12s of wallclock time, or the complete download of the 1.6GB test object by each thread. For most of us without a fiber link directly to the test server, the 12s limit will be encountered first :)
How are you calculating throughput value?
We start by sending a pre-warm instruction to the edge server to pull the test object to the edge. This is to prevent any origin-to-edge slowness falsely affecting our measurements. We then execute the PING estimation (for details see below) which conveniently provides some time for the pre-warm to take effect. Aggregate throughput is calculated by summing the throughput achived by a number of parallel download threads. The default is 4 but you may adjust it prior to a test between 1 and 6. For each thread we spin up a worker instance dedicated to that download. The worker uses FETCH to make a GET request for a 1.6GB binary test object. We observe the download at 500ms intervals. The data downloaded over each interval we term a 'chunk'. We calculate the throughput of the last chunk as byte-delta/time-delta and also the average throughput since the start of the download as total bytes downloaded/total time taken. On the chart in the UI we trace the last chunk throughput achieved by each thread, as well as the aggregate average throughput achived by all threads (the thicker red line). It is this aggregate average throughput value that is displayed as your download 'speed'. If the test object has not been completely downloaded within 12s, then each download worker will abort its fetch, to prevent consuming unnecessary data. In our emprical observations, your throughput will ramp up in the first few seconds and then stabilize, so there is little utility in continuing the test beyond 12s.
How are you calculating the PING and JITTER values?
In JavaScript we don't have access to the TCP stack directly, therefore we need to estimate the round trip time to the server. We do this make making a HEAD request to an API on the server, which returns a custom header 'rtt-estimate' whose value is the server's estimate of the rtt to the client. We also use the performance timing api to observe each of these requests, and we calculate a second client-side estimate of the rtt by subtracting 'fetchStart' from the 'responseStart' for the appropriate resource. We make 30 of these requests at 200ms intervals and calculate a running average of the last 10 results obtained for both the client-side and server-side estimates. If you are behind a MASQUE proxy then the server estimate will in fact be estimating the RTT to the egress proxy, so we display to you the client-side estimated running average value. If you are not behind a MASQUE proxy and have a direct connection to the edge server, then we display the server-side estimated running average value. The JITTER is calculated as the average difference between the last 10 RTT estimates.
Why don't my results don't match [insert-your-favorite-speed-test-here]?
Under the covers, each test site is using a different combination of test servers, test objects, parallel requests, test durations, transport protocols - all of which serve to introduce variability on top of the inherent variabilty already existing in your last mile network. This variability mirrors the reality of modern web delivery, in which content is drawn from multiple sources. For a coherent picture of your true connectivity, we encourage you to sample a wide variety of speed test sites.
Can we view the source code you are using?
By all means. The script is single page that is minified but not obfuscated, so any de-minifier will do. We appeciate you pointing out any errors and bugs via our issue tracker, linked in the footer below.
How do I see debug statements in the browser console?
Append a ?debug=true query arg to the page URL.
If I opt-in to sharing data with Akamai, what data exactly gets shared?
The following information is sent to Akamai (all of which is visible at some point in the UI). We store this information in the United States and use it to detect performance problems with our location estimation database as well as our implementation of MASQUE proxies.
| Field Name | Explanation |
|---|
| debug | true if the debug query arg is enabled |
| build | the build number of the test page |
| country | your estimated country code |
| region | your estimated geographical region within your country |
| city | your estimated city |
| timezone | your timezone |
| network | the name of the network to which you are connected |
| v4asn | the AS Number assigned to your v4 public IP address |
| v6asn | the AS Number assigned to your v6 public IP address (if you have one) |
| networktype | the type of network to which you are connected (cable, DSL, private relay etc) |
| clientV4ip | your v4 public IP address |
| clientV6ip | your v6 public IP address (if you have one) |
| clientEdgescapeLatLong | the latitude and longitude of your location as estimated by Akamai Edgescape |
| serverV4LatLong | the latitude and longitude of the ipV4 server you will be testing against |
| serverV6LatLong | the latitude and longitude of the ipV6 server you will be testing against |
| serverV4Ip | the v4 ip address of the server you tested against |
| serverV6Ip | the v6 ip address of the server you tested against |
| clientMMLatLong | the latitude and longitude of your location as estimated by Maxmind |
| clientBrowserLatLong | the latitude and longitude of your location as estimated by your web browser (if you enabled this location action) |
| DNSLatLong | the latitude and longitude of your DNS server |
| ECSLatLong | the latitude and longitude of any ECS info supplied to the DNS server |
| target | the IP address you selected to test with ( auto | v4 | v6 ) |
| time | the UTC time at which the test was started |
| ping | the PING result |
| jitter | the JITTER result |
| protocol | the protocol used for the PING test |
| masque | true if a private (MASQUE) relay has been detected |
| egress | the PING time to the egress node of the private relay, if one was detected. |
| threads | the number of parallel download threads used |
| throughput | the aggregate average throughput value measured at the end of the test |