# BlueMind 5.7 Téléchargement inutile des source maps par les service workers **URL:** \ **Category:** Uncategorized\ **Created:** [November 3, 2026, 2:26pm UTC](https://forum.bluemind.net/t/bluemind-5-7-telechargement-inutile-des-source-maps-par-les-service-workers/5085 "2026-11-03T14:26:14Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![didier.paulin](https://forum.bluemind.net/letter_avatar_proxy/v4/letter/d/e480ec/32.png) [@didier.paulin](https://forum.bluemind.net/u/didier.paulin)\ **Post date:** [November 3, 2026, 2:26pm UTC](https://forum.bluemind.net/t/bluemind-5-7-telechargement-inutile-des-source-maps-par-les-service-workers/5085/1 "2026-11-03T14:26:14Z")
Bonjour, En préparant notre migration vers BlueMind 5.7 (5.7.3268) pour environ 1 600 utilisateurs, j’ai constaté des ralentissements ponctuels du webmail, particulièrement sur les connexions lentes. Après analyse, il apparaît que les service workers téléchargent systématiquement les fichiers source maps (.map), qui servent uniquement au débogage et ne semblent pas nécessaires au fonctionnement du webmail (à confirmer, mais c’est ce que montrent mes tests). Constats - Sur 5 semaines : 5 Go de fichiers .map transférés sur 7 Go de trafic webmail, soit 72 % du volume total. - Les requêtes proviennent principalement de /webapp/service-worker.js, mais également de /cal/sw.js et /task/sw.js. - Ces téléchargements se produisent à la première connexion, après une mise à jour de BlueMind ou après un vidage du cache. - En dehors de ces téléchargements, les performances sont excellentes : médiane de 1 ms et 99 % des requêtes traitées en moins de 70 ms. À l’échelle de nos 1 600 postes, une mise à jour pourrait donc générer environ 160 Go de transferts inutiles. Origine du problème Dans le bundle net.bluemind.webmodule.server, le fichier /webapp/resource-list.json est généré par AssetUtils.getAssetsList(). Le filtre actuel n’exclut pas les fichiers .map : ``` private static Boolean assetsFilter(String path) { return !(path.startsWith(".") || path.endsWith(".devmode.js") || path.endsWith(".nocache.js") || path.startsWith("WEB-INF")); } ``` La liste des ressources est également utilisée par le template templates/sw.ftl.js pour les applications /cal, /task et /contact. Sur notre installation, nous avons relevé environ 115 fichiers .map, représentant 190 Mo. Contournement appliqué En attendant une éventuelle correction, nous avons bloqué les requêtes vers les fichiers .map sur notre reverse proxy Apache, en excluant les points d’entrée API : ``` RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(GET|HEAD)$ RewriteCond %{REQUEST_URI} !^/(api|dav|mapi|ews|EWS|Microsoft-Server-ActiveSync|autodiscover|Autodiscover|OAB|eventbus|bm-openid)(/|$) [NC] RewriteRule "\.map$" - [R=404,NC,L] ``` Avant cette modification, j’ai vérifié le fonctionnement des service workers dans le code source : - Pas d’utilisation de cache.addAll. - Les téléchargements ne bloquent pas l’événement install. - Les erreurs de téléchargement sont gérées individuellement avec un try/catch. Le retour HTTP 404 semble donc être correctement toléré, sans impact fonctionnel constaté à ce stade. Correction proposée Une correction simple serait d’exclure les fichiers .map dans AssetUtils.assetsFilter() en ajoutant : ``` || path.endsWith(".map") ``` Une autre possibilité serait de ne plus inclure les source maps dans les paquets de production. Est-ce un comportement connu de votre côté ? Serait-il possible de prévoir une correction dans une prochaine version ? À l’échelle d’un déploiement de plusieurs milliers d’utilisateurs, cela permettrait de réduire significativement le trafic réseau et d’améliorer les premières connexions, notamment sur les liens à faible débit. Je peux fournir des extraits de logs ou des informations complémentaires si nécessaire. Merci pour votre retour. Signé : un nouvel utilisateur qui cherche déjà la petite bête… promis, c’est pour la bonne cause ! 😉