SpeedTest by OpenSpeedTest: a self-hosted HTML5 speed test that is just static files

What OpenSpeedTest solves, and who ends up deploying it

Public speed tests measure the path between your browser and a server the operator chose. That is useful for checking an ISP, and useless for checking the link between two rooms in the same building, a branch office and a data centre, or a Wi-Fi access point and the wired core. OpenSpeedTest exists for those cases. The project describes itself as a Free and Open-Source HTML5 Network Performance Estimation Tool written in Vanilla Javascript, started in 2011 and moved to the OpenSpeedTest.com domain in 2013.

The intended user is not an end consumer. It is the person who can put files on a web server: a network engineer standing up a test endpoint inside a VLAN, a sysadmin who wants a page on the intranet, or a support team that needs a URL to hand to a user during a call. Because the client is a web page, the person being tested installs nothing. The README states that no client-side software or plugin is required and that the test runs in any browser that is IE10 or newer.

That last point is the real differentiator. A native speed test client, or a test that depends on a modern JavaScript runtime, narrows which devices can participate. A page that works from IE10 upward can be opened on an old kiosk machine, a set-top box browser, or a locked-down corporate desktop where nothing can be installed.

How the test moves bytes: static files, XHR and SVG

The repository layout is unusually small: .gitignore, License.md, README.md, assets/, downloading, hosted.html, index.html and upload. That matches the description. The client uses built-in Web APIs only, XMLHttpRequest, HTML, CSS, JS and SVG, with no third-party frameworks or libraries. The README puts the speed test script file size under 8kB gzip.

The mechanism follows from that file list. The browser loads index.html and the assets, then uses XHR to pull data from the downloading path and push data to the upload path. Those are directories of static content served by your web server, not an application with a database behind it. Speed is derived from how long those transfers take. The README does not document the exact sampling interval, the number of concurrent XHR streams, or how the final figure is smoothed, so treat the displayed number as an estimate, which is how the project itself describes it.

Because the server side is static, the requirements are all web server settings rather than runtime dependencies. The README lists them: the server must accept GET, POST, HEAD and OPTIONS with a 200 OK response; it must accept POST to static files with a 200 OK response; client_max_body_size must be 35 Megabytes or more; the timeout must be greater than 60 seconds; access logs should be disabled to increase server performance; and Time to First Byte should be improved. The README also warns that behind a reverse proxy you should increase the post-body content length to 35 megabytes.

The UI is drawn in SVG, which is why the same page scales across display sizes and resolutions without a separate layout per device. HTTP2 and HTTP3 are supported, but the README recommends HTTP1.1 for maximum performance, which is a counterintuitive instruction and worth reading twice before you configure a server.

Installing it: static files on NGINX, then a first speed test

The README does not give a step-by-step install for the static files, but it does state the server requirements and points to a companion repository for the web server configuration. The project recommends following its Nginx configuration, published at github.com/openspeedtest/Nginx-Configuration. The essential settings from the README are the body size, the timeout and the response codes. Those are configuration keys, not commands, so the concrete step is to confirm them on your server and compare against the values the README gives: client_max_body_size of 35 Megabytes or more, and a timeout greater than 60 seconds.

If your server is still at a smaller body limit, uploads will fail long before the test finishes, and the failure will look like a slow upload rather than a rejected request. The README warns specifically about the reverse proxy case, where you must increase the post-body content length to 35 megabytes. The proxy has its own body limit, separate from the web server behind it, and it is the one people forget.

Once the files are served, open the page in a browser and press start. The README describes the result as a network performance estimation, not a certified measurement. For a LAN test, put the server on one side of the link you care about and open the page from a device on the other side. For a WAN test, place the endpoint where your users actually are, not in a data centre on a different continent, or you will measure the internet instead of your network.

If you would rather not configure a web server at all, the project publishes OpenSpeedTest-Server as a packaged application for Windows, Mac, Linux, Android, iOS and Docker, plus listings on the Microsoft Store, Mac App Store, App Store, Google Play, Snap Store, Docker Hub and a Helm chart. Those links are the install path the README promotes for people who do not want to run NGINX themselves.

Where the static approach breaks down

The first limitation is the POST requirement. The README is explicit that the server must accept POST to static files and return 200 OK. Plenty of hardened web servers, CDNs and object storage front ends are configured to reject POST to static paths, and some managed platforms do not expose a body size setting at all. If you cannot change those settings, the upload half of the test will not work, and the download half alone gives you an incomplete picture.

The second is that this is an estimation tool by its own description. There is no mention in the README of calibration, of server-side timestamping, or of a documented margin of error. Two clients on the same link can produce different numbers depending on CPU, browser and how many XHR streams the browser allows. For capacity planning, a browser-based estimate is a starting point, not a contract number.

The third is the HTTP1.1 recommendation. If your infrastructure has moved to HTTP2 or HTTP3 and you cannot easily serve the test over HTTP1.1, the README suggests you may not get maximum performance. Whether that matters at your link speed is something only your own measurements will show, and the README does not quantify the gap.

The fourth is operational. Static files mean there is no server-side result store, no user accounts and no history. The README does not document any result logging, so if you need to compare a test from last week with one from today, you are capturing the number yourself. That is the price of having nothing to maintain.

OpenSpeedTest against a hosted test like Ookla or Fast

The obvious alternative is a hosted service such as Ookla Speedtest or Fast, which people search for constantly. The difference in approach is where the server sits. A hosted service gives you a professionally operated endpoint and a consistent methodology, and you can compare your result against millions of others. You also cannot see inside it, you cannot test a private link that has no route to the public internet, and you cannot choose the path being measured.

OpenSpeedTest inverts every one of those properties. You own the endpoint, so you can place it on the far side of the exact segment you care about, including an isolated LAN with no internet access. You also own the configuration, which means a misconfigured body limit or a proxy in the path becomes your problem, and the numbers are only as good as the server you put them on.

There is a middle option the README itself points to: OpenSpeedTest-Server, the packaged build for Windows, Mac, Linux, Android, iOS and Docker. That removes the web server configuration work while keeping the test inside your own network, which is probably the right starting point for a team that wants the self-hosted model without the NGINX tuning.

Maintenance, licence and what you are actually committing to

The maintenance story is short because the artifact is short. The repository is not archived, and the last push was on 2026-04-22. The client is static HTML, CSS, JS and SVG, so there is no runtime to patch, no dependency tree to audit and no package manager involved. The README leans on this directly, arguing that because OpenSpeedTest contains only STATIC files, you do not need to worry about security updates or hidden exploits that may compromise secure environments. That claim is about the client files, and it is fair as far as it goes: a static page has a small attack surface. It does not mean the web server hosting it needs no patching, and it does not cover the packaged OpenSpeedTest-Server builds, which are separate artifacts.

The licence is MIT, stated in License.md. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the general shape of the licence, not legal advice, and if you are embedding the files in a product you should read License.md and the trademark position on the OpenSpeedTest name yourself. The name is presented as a trademark in the project title, which is a separate question from the code licence.

Upgrade cost is close to zero for the static deployment: replace the files. The README does not document a versioning scheme for the static package or a changelog, and no recent releases were retrieved, so plan on pulling the current files rather than tracking version numbers. The packaged server is the part with a real upgrade cycle, and the README promotes version 2.1 of OpenSpeedTest-Server.

Editorial conclusion

Adopt it if you want a browser speed test inside your own network, served from static files you control, or if you need to check a link from a phone, a TV or an old browser without installing anything. Do not adopt it if you need a hosted public benchmark, per-user reporting, or a test that works when only HTTP GET is allowed: the README requires POST to static files, a body limit of 35 MB or more and a timeout above 60 seconds. Verify those three settings on your web server, and check the reverse proxy body limit before you trust the numbers.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. openspeedtest/Speed-Test on GitHub
4. Project website
5. README