Minifier du JavaScript

Renommer, supprimer, et ce qu'il ne faut jamais toucher

Trois choses se produisent, par ordre croissant de ce qu'elles font gagner et de ce qu'elles vous coûtent. Les espaces et les commentaires disparaissent, ce qui est gratuit. Le code mort disparaît — une branche qui ne peut jamais s'exécuter, une variable affectée mais jamais lue. Et les noms locaux sont raccourcis : un calculateMonthlyTotal soigneusement nommé devient une seule lettre. C'est là que se trouve l'essentiel du gain, et c'est aussi ce qui rend le résultat illisible — ce qui convient pour la mise en production et ne sert à rien pour le débogage.

Ce qui ne peut pas être renommé, c'est tout ce que le monde extérieur désigne par son nom, et c'est en se trompant là-dessus que les minifieurs cassent du code. Les fonctions exportées, les propriétés d'objet accédées sous forme de chaînes, tout ce qui passe par window et les noms utilisés dans eval doivent rester intacts, car quelque chose ailleurs les recherche sous le nom que vous avez écrit. Les propriétés en particulier ne sont pas touchées par défaut : renommer user.emailAddress casserait tout dès que cet objet serait sérialisé en JSON ou lu par du code minifié séparément.

Gardez une source map ou l'original. Une fois les noms disparus, la pile d'appels d'une erreur chez un vrai utilisateur indique une erreur dans la fonction t au caractère 48 213, ce qui ne vous apprend strictement rien. Une source map restaure les noms et numéros de ligne d'origine dans le débogueur et dans les rapports d'erreurs, et en générer une ne coûte rien, car elle est livrée dans un fichier séparé qui ne se charge que lorsque quelqu'un ouvre les outils de développement.

Les commentaires de licence sont conservés par défaut, et c'est une position juridique plutôt qu'une préférence. Une grande partie du code open source est publiée sous licence permissive à une seule condition : que sa mention de copyright l'accompagne — les licences MIT et BSD le disent toutes deux explicitement. Retirer ces commentaires d'un bundle contenant du code tiers vous place en infraction avec la licence qui vous permettait de l'utiliser. Ils pèsent quelques centaines d'octets.

Si vous cherchez autre chose

Cette étape a sa place dans un build plutôt que dans un onglet de navigateur, et les bundlers modernes s'en chargent d'office. esbuild --minify ainsi que Rollup ou Vite minifient au build, génèrent automatiquement les source maps et — bien plus important — pratiquent le tree shaking, en éliminant les exports de vos dépendances que vous n'importez jamais. Sur une vraie application, cela fait gagner bien plus que la minification d'un fichier fini ne le pourra jamais.

Avant d'optimiser, mesurez. Un analyseur de bundle révélera généralement qu'une seule grosse dépendance représente l'essentiel du fichier — une bibliothèque de dates, un jeu d'icônes, une bibliothèque de graphiques importée en entier pour un seul graphique. La remplacer ou la charger à la demande vaut mieux que n'importe quelle minification, et le code splitting, pour qu'une page ne charge que ce dont elle a besoin, vaut mieux que les deux.