Comment déployer votre propre test de vitesse avec du JavaScript pur sans services externes

Vous êtes-vous déjà trouvé dans une situation où votre forfait affiche un accès gigabit, les fichiers se téléchargent rapidement, mais vos appels professionnels ou l'accès à votre serveur domestique sont douloureusement lents ? Votre première réaction est d'ouvrir un site de test de vitesse bien connu et d'appuyer sur le grand bouton rond. Le problème, c'est que les tests publics indiquent la vitesse vers les serveurs du fournisseur, et non le débit réel au sein de votre réseau local, de votre environnement de bureau ou de votre cloud personnel.

Je suis tombé sur le dépôt Speed-Test du projet OpenSpeedTest. L'auteur le développe depuis plus de dix ans, depuis 2011. C'est un outil open-source de test de bande passante réseau écrit entièrement en HTML5 pur, CSS et JavaScript vanilla. Pas de React, Vue, de bundles lourds ou de dépendances externes.

Ce qu'il y a sous le capot

Le point fort du code source est son élégance. Toute la logique côté client est compressée dans un script gzippé de moins de 8 Ko. L'interface est entièrement rendue en SVG vectoriel, elle est donc tout aussi nette sur un ancien moniteur et sur un écran de smartphone 4K.

Pour que l'outil fonctionne, le côté client n'a besoin que d'un navigateur supportant XMLHttpRequest (XHR2). Même l'ancien Internet Explorer 10 fera l'affaire. Du côté serveur, il suffit de servir des fichiers statiques via n'importe quel serveur web : Nginx, Apache, Caddy ou Express.

Il n'y a pas de scripts backend cachés ni de binaires complexes, donc la surface d'attaque est minimale. En essence, vous servez au navigateur un ensemble de fichiers statiques, après quoi le client commence à envoyer une série de requêtes POST et GET parallèles d'une taille spécifiée.

Gérer les tests via les paramètres URL

Au lieu de construire des menus de paramètres lourds, l'auteur a implémenté le contrôle via des paramètres GET dans la barre d'adresse. C'est pratique si vous voulez donner à vos collègues un lien prêt à l'emploi avec un comportement préconfiguré.

Voici quelques paramètres utiles :

• Démarrer automatiquement le test dès l'ouverture de la page :

http://192.168.1.5?Run

• Test de stress du réseau. Vous pouvez définir un préréglage ou spécifier la durée du test en secondes. Par exemple, exécuter le trafic pendant 300 secondes dans les deux sens :

http://192.168.1.5?Stress=300

Ou une syntaxe plus courte :

http://192.168.1.5?S=L

• Limiter le nombre de flux HTTP parallèles (par défaut 6, maximum 32) :

http://192.168.1.5?XHR=4

• Exécuter une phase spécifique, par exemple uniquement l'envoi ou la vérification de la latence :

http://192.168.1.5?Test=Upload

Si vous souhaitez collecter des statistiques à partir d'un parc de machines de bureau, dans le fichier index.html vous pouvez décommenter les variables saveData et spécifier l'adresse webhook de votre base de données :

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

Comment l'exécuter vous-même

Le moyen le plus rapide de déployer votre propre test de vitesse est une image Docker prête à l'emploi. Elle est construite sur Alpine léger avec un utilisateur Nginx non-root :

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

Si vous préférez travailler avec compose, la configuration est compacte :

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

Après le démarrage, l'interface sera disponible à l'adresse http://IP_СЕРВЕРА:3000.

Si vous installez le service derrière votre propre proxy inverse, pensez à augmenter la limite de taille du corps de la requête client_max_body_size à au moins 35 Mo. Sinon, les tests d'envoi commenceront à échouer avec une erreur 413.

Au fait, si vous prévoyez de tester des vitesses supérieures à 1 Gbps, l'auteur recommande d'utiliser un hôte Linux. Sur Docker Desktop pour macOS ou Windows, la vitesse atteint souvent le plafond en raison de la virtualisation et des frais généraux du pont réseau.

Pourquoi garder un test de vitesse local

Il y a plusieurs scénarios où les services web réguliers sont inutiles :

1. Diagnostic du Wi-Fi et des répéteurs. Quand vous installez un répéteur de signal à la maison ou au bureau, la vitesse chute en moyenne de moitié. Tester la liaison localement depuis différentes pièces vous permet de choisir précisément le meilleur emplacement pour un point d'accès sans être affecté par les fluctuations de votre connexion internet externe.
2. Vérifier l'impact des extensions de navigateur. Parfois des outils comme iperf montrent un gigabit honnête, mais les pages web s'ouvrent lentement. Exécutez OpenSpeedTest dans votre profil normal, puis dans une fenêtre privée. La différence de résultats vous montrera combien de millisecondes vos plugins installés consomment.
3. Évaluer les canaux vers un bureau distant. Quand les travailleurs à distance se plaignent d'un accès lent au stockage de fichiers, un conteneur local sur le serveur affichera la vitesse réelle du tunnel.

Cela vaut-il la peine d'essayer

Speed-Test résout un problème spécifique sans publicités, télémétrie tierce ou dépendances lourdes. Si vous avez régulièrement besoin de configurer des réseaux locaux, de trouver des câbles patch défectueux ou de vérifier les performances d'un NAS domestique, gardez cette image sous la main. Elle se déploie en une minute, consomme un minimum de ressources et apporte une valeur considérable.