Table of Contents
This is where the actual speedtest code is. It receives the settings from the main thread, runs the test, and reports back the results.
The worker accepts 3 commands:
start: starts the test. Optionally, test settings can be passed as a JSON string after the word start and a spacestatus: returns the current status as a JSON string. The status string contents are the ones described in the Event handlers section in the section about making a custom front-end.abort: aborts the test
Parameters
In addition to the parameters listed in the Test settings section in the section about making a custom front-end, there is one additional setting:
mpot: set this to true to run the test with multiple points of test. This will addcors=trueto all requests (all responses will contain CORS headers) and enable some extra quirks. Default:false
Download test
The download test is performed by transferring large blobs of garbage data using XHR from the server to the client.
The test uses multiple streams. If a stream finishes the download, it is restarted. The amount of downloaded data for each stream is tracked using the XHR Level 2 onprogress event.
The test streams are not perfectly synchronized because we don't want them to finish all at the same time if they do.
Every 200ms, a timer updates the dlStatus string with the current speed and calculates a "bonus" time by which to shorten the test depending on how high the speed is, (when time_auto is set to true).
See the code for more implementation details.
Upload test
This works similarly to the download test, but in reverse. A large blob of garbage data is generated and it is sent to the server repeatedly using multiple streams.
To keep track of the amount of transferred data, the XHR Level 2 upload.onprogress event is used.
This test has a couple of complications:
- Some browsers don't have a working
upload.onprogressevent. For this, we use a small blobs instead of a large one and we keep track of progress using theonloadevent. This is referred to as IE11 Workaround (but the same bug was also found in some versions of Edge and Safari) - When
mpotis set totrue, an empty request must first be sent in order to load the CORS headers before the test can start
See the code for more implementation details.
Ping + Jitter test
The Ping/Jitter test is NOT an ICMP ping. This is a common misconception. You cannot use ICMP over HTTP, and certainly not in a browser.
This test works by creating a persistent HTTP connection to the server, and then repeatedly downloading an empty file, and measuring how long it takes between the request and the response.
Timing can be measured as a simple timestamp difference or with the Performance API if available.
Jitter is the variance in ping times.
See the code for more implementation details.