SpeedTest constructor to override any defaults. Every option is optional — omitting the config object entirely is valid.
Engine
Whether to automatically start the measurements when the
SpeedTest instance is created. Set to false to control start time manually using engine.play().APIs
The URL used for download GET requests. Each request appends a
bytes query parameter specifying the response size.The URL used for upload POST requests. Each request posts a body of the configured byte size.
The URI of the TURN server used for packet loss measurement over WebRTC.
A URL that returns TURN server credentials as a JSON response with
username and credential keys (and optionally a urls array of TURN server addresses). Used as an alternative to providing credentials directly via turnServerUser and turnServerPass. See TURN server setup for a complete example worker implementation.The username for TURN server authentication. Used together with
turnServerPass to authenticate directly, without fetching credentials from turnServerCredsApiUrl.The password for TURN server authentication. Used together with
turnServerUser.Whether to include cookies and other credentials with download and upload requests (sets
credentials: 'include' on the underlying fetch calls). Useful when the test endpoints require session-based authentication.Measurements
The ordered sequence of measurements the engine will perform. Each entry is an object with a
type field plus type-specific options. See Measurement types for the full reference and the default array.Whether to perform additional latency requests in parallel with active download measurements. This produces a “loaded latency” value that reflects real-world latency under download load.
Whether to perform additional latency requests in parallel with active upload measurements. This produces a “loaded latency” value that reflects real-world latency under upload load.
Minimum time in milliseconds to wait between consecutive loaded-latency requests. Reduces interference with the bandwidth measurement being run in parallel.
Duration threshold in milliseconds. When a download or upload request in a given direction takes at least this long, the engine stops executing subsequent measurement sets for that direction (ramp-up is considered complete). Set to
0 to disable early stopping and always run every configured measurement.Duration threshold in milliseconds. When a download or upload request exceeds this duration, the engine aborts the in-progress request early and stops further measurements in that direction. Defaults to
0 (disabled). Only set this when you want to cap total test time.A fixed duration in milliseconds subtracted from all time-to-first-byte calculations to discount server-side processing time. This value is only used when the download/upload API does not return a
server-timing response header containing the actual server processing time.Result interpretation
The percentile (between
0 and 1) used to derive a single latency value from the collected set of latency measurements. The default of 0.5 is the median.The percentile (between
0 and 1) used to derive a single bandwidth value from the collected set of bandwidth measurements. The default of 0.9 selects a near-peak value, filtering out outlier-low samples.Minimum duration in milliseconds a request must last for its result to be included in the bandwidth calculation. Requests that complete faster than this threshold are considered too short to produce reliable measurements.
Minimum duration in milliseconds a bandwidth request must last for the simultaneous loaded-latency samples captured during it to be counted. Shorter requests are not considered to be genuinely loading the connection.
Maximum number of loaded-latency data points to retain per direction. When more samples are collected than this limit, only the most recent ones are kept.
