Minifier JavaScript en Ligne
Optimise la taille de ton bundle JavaScript. Minifie ou formate instantanément.
Pourquoi l'utiliser
Un JavaScript plus léger, des applis plus rapides
Réduction de 40 à 60%
Supprime les espaces, commentaires et raccourcit les variables sans modifier la fonctionnalité.
Privé
Le JS est traité dans ton navigateur. Jamais envoyé à un serveur.
Bidirectionnel
Minifie pour la production ou formate du JS minifié pour le lire et le déboguer.
Instantané
Résultats en millisecondes. Aucun traitement serveur.
Comment ça marche
Trois étapes, sans complications
Colle ou charge ton JavaScript
Colle du code JS directement ou glisse un fichier .js. Aucune limite de taille.
Choisis : minifier ou formater
Minifie pour la production (réduit les variables, supprime les espaces) ou formate du JS minifié pour le lire.
Copie ou télécharge le résultat
Le JavaScript optimisé apparaît instantanément. Copie dans le presse-papiers ou télécharge en fichier.
FAQ
Des questions ?
La minification JavaScript supprime les espaces, commentaires et sauts de ligne, raccourcit les noms de variables et fonctions locales (renommage/mangling) et dans certains cas élimine le code mort. Le résultat est fonctionnellement identique mais nettement plus petit, réduisant le temps de téléchargement et le temps d'analyse du moteur JS.
UglifyJS (2010) a été le premier minifieur JavaScript largement adopté, introduisant la compression et le mangling (renommage de variables). Terser est le successeur moderne d'UglifyJS, compatible avec ES2015+ et les modules ES. Minify est le terme générique pour la réduction de taille. Terser est aujourd'hui le standard de facto, utilisé en interne par webpack, Vite, Rollup et esbuild.
En général de 40 à 60% de la taille d'origine pour du JavaScript bien commenté et formaté. Un fichier de 200 Ko peut être réduit à 80 à 120 Ko avec la minification seule. Combiné avec la compression gzip/Brotli, les économies totales peuvent dépasser 80%. Le renommage de variables apporte une réduction supplémentaire de 10 à 20% au-delà de la simple suppression des espaces.
Le JavaScript minifié peut être formaté pour récupérer une structure lisible, mais les noms de variables et fonctions renommés ne peuvent pas être récupérés : calculateMonthlyPayment a peut-être été réduit à a ou b. Sans les source maps d'origine, le code formaté est fonctionnel mais difficile à comprendre. Les source maps font correspondre le code minifié au code d'origine et sont essentiels pour le débogage en production.
Les source maps sont des fichiers .js.map qui créent une correspondance entre le code minifié/transpilé et le code source d'origine. Quand une erreur se produit en production, le navigateur utilise la source map pour afficher la trace de pile avec les noms et numéros de ligne d'origine plutôt que la version minifiée. Ils sont générés automatiquement par webpack (devtool: source-map), Vite (build.sourcemap: true) ou Terser (--source-map).
Histoire de la minification JavaScript et optimisation des bundles
La minification JavaScript a commencé avec JSMin, créé par Douglas Crockford en 2001. Crockford a observé que le JavaScript envoyé au client contenait d'énormes quantités d'espaces et de commentaires consommant de la bande passante inutilement. JSMin a été le premier compresseur systématique : il supprimait les commentaires et les espaces tout en préservant la sémantique du langage. Peu après, YUI Compressor (Yahoo, 2007) a introduit le renommage basique de variables, posant les bases de la minification moderne.
Le tree-shaking est une technique connexe mais distincte : tandis que la minification réduit le code existant, le tree-shaking élimine le code qui n'est jamais exécuté (code mort) en analysant le graphe d'imports des modules ES. Rollup a popularisé le tree-shaking en 2015 ; webpack l'a adopté à partir de la version 2. Le code splitting complète ces techniques en divisant le bundle en morceaux chargés à la demande (dynamic import()), réduisant le JavaScript initial que le navigateur doit analyser et exécuter.
L'outil Lighthouse de Google inclut une analyse de la couverture JavaScript (onglet Coverage dans Chrome DevTools) qui identifie quel pourcentage du JS téléchargé est réellement exécuté au chargement initial. Des études de HTTP Archive montrent que la page web médiane charge plus de 400 Ko de JavaScript compressé (plus d'1 Mo non compressé), ce qui en fait la ressource la plus néfaste pour le Time to Interactive (TTI). L'adoption des ESM natifs dans les navigateurs modernes et le pattern de module importmaps représente la prochaine évolution dans la livraison efficace de JavaScript.