So deployst du deinen eigenen Speedtest mit purem JavaScript ohne externe Dienste

Ist dir schon mal aufgefallen, dass dein Tarif Gigabit-Internet verspricht, Dateien schnell herunterladen, aber dein Arbeit-calls oder der Zugriff auf deinen Heimserver schmerzhaft langsam ist? Deine erste Reaktion ist, eine bekannte Speedtest-Seite zu öffnen und den großen runden Knopf zu drücken. Das Problem ist, dass öffentliche Tests die Geschwindigkeit zu den Servern des Anbieters zeigen, nicht den tatsächlichen Durchsatz in deinem lokalen Netzwerk, Büro-Umgebung oder persönlichen Cloud.

Ich bin auf das Speed-Test Repository vom OpenSpeedTest-Projekt gestoßen. Der Autor entwickelt es seit über zehn Jahren, seit 2011. Es ist ein Open-Source-Netzwerk-Bandbreite-Test-Tool, das vollständig in purem HTML5, CSS und Vanilla JavaScript geschrieben wurde. Kein React, Vue, schwere Bundles oder externe Abhängigkeiten.

Was steckt unter der Haube

Das Haupt-Highlight des Quellcodes ist seine Eleganz. Die gesamte clientseitige Logik ist in ein gzip-komprimiertes Skript unter 8 KB gepackt. Die Benutzeroberfläche wird vollständig in Vektor-SVG gerendert, sodass sie auf einem alten Monitor und auf einem 4K-Smartphone-Display gleichermaßen scharf aussieht.

Damit das Tool funktioniert, braucht die Client-Seite nur einen Browser, der XMLHttpRequest (XHR2) unterstützt. Sogar der alte Internet Explorer 10 reicht aus. Auf der Serverseite reicht es aus, statische Dateien über einen beliebigen Webserver bereitzustellen: Nginx, Apache, Caddy oder Express.

Es gibt keine versteckten Backend-Skripte oder komplexen Binärdateien, sodass die Angriffsfläche minimal ist. Im Wesentlichen servierst du dem Browser eine Reihe von statischen Dateien, woraufhin der Client beginnt, eine Reihe von parallelen POST- und GET-Anfragen einer bestimmten Größe zu senden.

Tests über URL-Parameter verwalten

Anstatt umständliche Einstellungsmenüs zu bauen, hat der Autor die Steuerung über GET-Parameter in der Adressleiste implementiert. Das ist praktisch, wenn du Kollegen einen fertigen Link mit vorkonfiguriertem Verhalten geben möchtest.

Hier sind einige nützliche Parameter:

• Test automatisch starten, sobald die Seite geöffnet wird:

http://192.168.1.5?Run

• Stresstest für das Netzwerk. Du kannst eine Voreinstellung setzen oder die Testdauer in Sekunden angeben. Zum Beispiel: Verkehr 300 Sekunden lang in beide Richtungen laufen lassen:

http://192.168.1.5?Stress=300

Oder eine kürzere Syntax:

http://192.168.1.5?S=L

• Die Anzahl der parallelen HTTP-Streams begrenzen (Standard ist 6, Maximum ist 32):

http://192.168.1.5?XHR=4

• Eine bestimmte Phase ausführen, zum Beispiel nur Upload oder Latenzprüfung:

http://192.168.1.5?Test=Upload

Wenn du Statistiken von einer Flotte von Büromaschinen sammeln möchtest, kannst du in der index.html-Datei die saveData-Variablen einkommentieren und deine Datenbank-Webhook-Adresse angeben:

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

So führst du es selbst aus

Der schnellste Weg, deinen eigenen Speedtest zu deployen, ist ein fertiges Docker-Image. Es basiert auf leichtgewichtigem Alpine mit einem Non-root Nginx-Benutzer:

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

Wenn du lieber mit Compose arbeitest, sieht die Konfiguration kompakt aus:

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

Nach dem Start ist die Benutzeroberfläche unter http://IP_СЕРВЕРА:3000 verfügbar.

Wenn du den Dienst hinter deinem eigenen Reverse Proxy installierst, erhöhe unbedingt das Request-Body-Größenlimit client_max_body_size auf mindestens 35 MB. Andernfalls werden Upload-Tests mit einem 413-Fehler fehlschlagen.

Übrigens, wenn du Geschwindigkeiten über 1 Gbps testen möchtest, empfiehlt der Autor die Verwendung eines Linux-Hosts. Bei Docker Desktop für macOS oder Windows stößt die Geschwindigkeit oft an die Grenzen aufgrund von Virtualisierung und Netzwerk-Bridge-Overhead.

Warum einen lokalen Speedtest behalten

Es gibt mehrere Szenarien, in denen reguläre Webdienste nutzlos sind:

1. Diagnose von Wi-Fi und Repeatern. Wenn du einen Signal-Repeater zu Hause oder im Büro installierst, sinkt die Geschwindigkeit durchschnittlich um die Hälfte. Das lokale Testen der Verbindung von verschiedenen Räumen aus ermöglicht es dir, den besten Standort für einen Access Point präzise auszuwählen, ohne von Schwankungen deiner externen Internetverbindung beeinflusst zu werden.
2. Überprüfung der Auswirkung von Browser-Erweiterungen. Manchmal zeigen Tools wie iperf eine ehrliche Gigabit-Verbindung, aber Webseiten öffnen sich langsam. Führe OpenSpeedTest in deinem normalen Profil aus, dann in einem privaten Fenster. Der Unterschied in den Ergebnissen zeigt, wie viele Millisekunden deine installierten Plugins verbrauchen.
3. Bewertung der Kanäle zu einem Remote-Büro. Wenn sich Remote-Mitarbeiter über langsamen Zugriff auf Dateispeicher beschweren, zeigt ein lokaler Container auf dem Server die echte Tunnelgeschwindigkeit.

Lohnt es sich, es zu versuchen

Speed-Test löst ein bestimmtes Problem ohne Werbung, Drittanbieter-Telemetrie oder aufgeblähte Abhängigkeiten. Wenn du regelmäßig lokale Netzwerke konfigurieren, fehlerhafte Patchkabel finden oder die Leistung eines Home-NAS überprüfen musst, halte dieses Image bereit. Es wird in einer Minute deployed, verbraucht minimale Ressourcen und bringt enormen Mehrwert.