How to deploy your own speed test with pure JavaScript without external services

Ever had a situation where your plan says gigabit internet, files download quickly, but your work call or access to your home server is painfully slow? Your first reaction is to open a well-known speed test site and hit the big round button. The thing is, public tests show the speed to the provider's servers, not the actual throughput within your local network, office environment, or personal cloud.

I came across the Speed-Test repository from the OpenSpeedTest project. The author has been developing it for over ten years, since 2011. It's an open-source network bandwidth testing tool written entirely in pure HTML5, CSS, and Vanilla JavaScript. No React, Vue, heavy bundles, or external dependencies.

What's under the hood

The main highlight of the source code is its elegance. All client-side logic is compressed into a gzipped script under 8 KB. The interface is entirely rendered in vector SVG, so it looks equally sharp on an old monitor and on a 4K smartphone display.

For the tool to work, the client side only needs a browser that supports XMLHttpRequest (XHR2). Even ancient Internet Explorer 10 will do. On the server side, it's enough to serve static files through any web server: Nginx, Apache, Caddy, or Express.

There are no hidden backend scripts or complex binaries, so the attack surface is minimal. Essentially, you're serving the browser a set of static files, after which the client starts sending a series of parallel POST and GET requests of a specified size.

Managing tests via URL parameters

Instead of building cumbersome settings menus, the author implemented control via GET parameters in the address bar. This is convenient if you want to give colleagues a ready-made link with pre-configured behavior.

Here are some useful parameters:

• Auto-start the test as soon as the page opens:

http://192.168.1.5?Run

• Stress test the network. You can set a preset or specify the test duration in seconds. For example, run traffic for 300 seconds in both directions:

http://192.168.1.5?Stress=300

Or a shorter syntax:

http://192.168.1.5?S=L

• Limit the number of parallel HTTP streams (default is 6, maximum is 32):

http://192.168.1.5?XHR=4

• Run a specific phase, for example only upload or latency check:

http://192.168.1.5?Test=Upload

If you want to collect statistics from a fleet of office machines, in the index.html file you can uncomment the saveData variables and specify your database webhook address:

var saveData = true;
var saveDataURL = "//metrics.internal.lan/save?data=";

How to run it yourself

The fastest way to deploy your own speed test is a ready-made Docker image. It's built on lightweight Alpine with a non-root Nginx user:

docker run -d \
  --name openspeedtest \
  --restart=unless-stopped \
  -p 3000:3000 \
  -p 3001:3001 \
  openspeedtest/latest

If you prefer working with compose, the configuration looks compact:

version: '3.3'
services:
  speedtest:
    container_name: openspeedtest
    image: openspeedtest/latest
    restart: unless-stopped
    ports:
      - '3000:3000'
      - '3001:3001'

After startup, the interface will be available at http://IP_СЕРВЕРА:3000.

If you're installing the service behind your own reverse proxy, be sure to increase the request body size limit client_max_body_size to at least 35 MB. Otherwise, upload tests will start failing with a 413 error.

By the way, if you plan to test speeds above 1 Gbps, the author recommends using a Linux host. On Docker Desktop for macOS or Windows, speed often hits the ceiling due to virtualization and network bridge overhead.

Why keep a local speed test

There are several scenarios where regular web services are useless:

1. Diagnosing Wi-Fi and repeaters. When you install a signal repeater at home or in the office, speed on average drops by half. Testing the link locally from different rooms lets you precisely pick the best spot for an access point without being affected by fluctuations in your external internet connection.
2. Checking the impact of browser extensions. Sometimes tools like iperf show a honest gigabit, but web pages open slowly. Run OpenSpeedTest in your normal profile, then in a private window. The difference in results will show how many milliseconds your installed plugins are eating up.
3. Evaluating channels to a remote office. When remote workers complain about slow access to file storage, a local container on the server will show the real tunnel speed.

Is it worth trying

Speed-Test solves one specific problem without ads, third-party telemetry, or bloated dependencies. If you regularly need to configure local networks, find faulty patch cables, or check the performance of a home NAS, keep this image on standby. It deploys in a minute, consumes minimal resources, and brings massive value.