Performances de map.army — Guide de vitesse et latence

map.army est une application basée sur un navigateur qui communique avec des services backend hébergés en Europe. Cette page explique ce qui affecte sa réactivité et comment atténuer les ralentissements.

Latence géographique

Le backend de l’application (services web MSS / MilX et la couche de stockage des partages) fonctionne depuis des centres de données européens. Chaque action de l’interface qui touche le backend — ouverture d’un nœud de la galerie de symboles, placement d’un symbole nécessitant un rendu côté serveur, enregistrement d’un partage, chargement d’un partage — implique un aller-retour dont la limite inférieure est la vitesse de la lumière vers l’Europe et retour.

Temps d’aller-retour minimal approximatif par région :

Région de l’utilisateurAller-retour minimal
Europe centrale / occidentale< 50 ms — perçu instantané
Europe de l’Est / Royaume-Uni50 – 100 ms — encore réactif
Côte Est des États-Unis~120 ms — pause perceptible sur les actions rapides
Côte Ouest des États-Unis~180 ms — délai visible sur chaque action liée au serveur
Brésil / Afrique~250 ms — lag significatif
Asie de l’Est / Océanie300 ms+ — chaque action liée au serveur montre un retard

Les chiffres ci-dessus sont des limites physiques inférieures ; la latence réelle sur les FAI grand public est généralement 1,5 à 3 fois plus élevée.

Astuce: Les VPN n’aident pas. Le routage via un VPN augmente presque toujours le temps d’aller-retour en ajoutant des sauts supplémentaires. Pour les utilisateurs éloignés de l’Europe, la seule vraie solution est un déploiement backend plus proche de l’utilisateur — voir l’entrée FAQ sur le déploiement en réseau fermé.
  • Chrome, Edge, Firefox et Brave offrent les meilleures performances — leurs moteurs JavaScript et leurs implémentations WebGL sont bien optimisés pour le rendu intensif que map.army effectue.
  • Safari fonctionne mais tend à être 10 à 20 % plus lent sur la galerie de symboles ; Safari sur iPadOS convient pour une utilisation occasionnelle.
  • Les appareils mobiles subissent la surcharge du moteur JS due à leurs CPU contraints ; les collections de calques complexes (des centaines de symboles, plusieurs calques d’images) peuvent sembler lentes même sur des téléphones haut de gamme.
  • Le GPU dédié est utile pour la vue 3D ; les graphiques intégrés fonctionnent mais limitent le détail du terrain.

Atténuations liées à la taille des calques

Si l’édition semble lente :

  • Masquez les calques que vous n’êtes pas en train de modifier. La bascule de visibilité dans le gestionnaire de calques réduit le travail de redessin.
  • Divisez les grandes opérations en plusieurs fichiers .milxlyz — un par phase / par unité / par secteur. N’ouvrez que le fichier dont vous avez besoin. Voir Calques → Exporter les calques — Travailler avec de très grandes collections de calques MilX.
  • Fermez la galerie de symboles lorsque vous ne placez pas activement de symboles — elle consomme son propre budget de redessin.
  • Supprimez les calques d’images que vous avez déjà utilisés pour le traçage — ils restent coûteux à rendre même lorsque les calques MilX sont superposés.

Disponibilité du service hébergé

Pour la disponibilité du service, la politique d’annonce de maintenance planifiée et les recommandations pour les utilisateurs qui dépendent d’un accès ininterrompu, voir l’entrée FAQ sur la surveillance et les fenêtres de maintenance.