Meilleur compresseur JavaScript [fermé]

171

Quel est le meilleur compresseur JavaScript disponible? Je recherche un outil qui:

  • est facile à utiliser
  • a un taux de compression élevé
  • Produire des résultats finaux fiables (ne gâche pas le code)
javascript  compression 
— Ron Harlev
source
14
Quelqu'un connaît la situation en 2011?
— Dan
4
Nous sommes maintenant en 2012, et je pense que UglifyJS et Closure sont les gagnants, j'utilise UglifyJS et cela bat généralement le pantalon de tout le reste.
— mkoistinen
J'utilise htmlcompressor.com/compressor.html pour mon application multi-page jQuery Mobile. Il prend un fichier HTML avec des balises <script> et compresse le HTML, le JavaScript et le CSS. Fonctionne comme un charme.
— Anders
Nous sommes en 2017 - Quelle est la dernière en date?
— Abhinav Singi
Nous sommes en 2020. Avec une configuration «sûre» par défaut, UglifyJS gagne marginalement car elle est plus «sûre». Pour les utilisations avancées de puissance, Closure Compiler se remet le cul d'UglifyJS. Closure Compiler avec ADVANCDED_OPTIMIZATIONS peut faire toutes sortes d'astuces qui vous aident à optimiser votre flux de travail et votre code en même temps. Voir stackoverflow.com/a/50355530/5601591 pour des exemples de génialité de Closure Compiler (AVERTISSEMENT: je n'ai pas pu trouver un article de blog approprié ailleurs, j'ai donc dû vous référer à un article que j'ai écrit).
— Jack Giffin

Réponses:

149

J'ai récemment publié UglifyJS , un compresseur JavaScript qui est écrit en JavaScript (fonctionne sur la plate-forme NodeJS Node.js , mais il peut être facilement modifié pour fonctionner sur n'importe quel moteur JavaScript, car il n'a pas besoin de composants Node.jsinternes). C'est beaucoup plus rapide que YUI Compressor et Google Closure , il compresse mieux que YUI sur tous les scripts sur lesquels je l'ai testé, et c'est plus sûr que Closure (sait gérer "eval" ou "with").

Outre la suppression des espaces, UglifyJS effectue également les opérations suivantes:

  • change les noms des variables locales (généralement en caractères uniques)
  • joint des déclarations var consécutives
  • évite d'insérer des crochets, des parenthèses et des points-virgules inutiles
  • optimise les IF (supprime "else" quand il détecte que ce n'est pas nécessaire, transforme les IF en opérateurs &&, || ou? /: lorsque cela est possible, etc.).
  • se transforme foo["bar"]en foo.barautant que possible
  • supprime les guillemets des clés dans les littéraux d'objet, si possible
  • résout des expressions simples lorsque cela conduit à un code plus petit (1 + 3 * 4 ==> 13)

PS: Oh, ça peut aussi «embellir». ;-)

— mishoo
source
17
Nous utilisons uglify dans une application de classe entreprise. Cela fait du bon travail.
— gyorgyabraham
Pourriez-vous comparer à jsmin sur le nœud?
— Gringo Suave
récemment Uglify a abandonné les appels d'API
— Gadelkareem
@mishoo Hé, j'adore votre Uglify JS2. Mon réseau ne fonctionne pas bien ces jours-ci ... J'aimerais l'utiliser sous Windows. Une solution? : o)
— Hydroper
@mishoo Je montre le lien git mais je n'ai pas l'idée de l'utiliser
— Sachin Sarola
124

Revisiter cette question quelques années plus tard, UglifyJS , semble être la meilleure option pour le moment.

Comme indiqué ci-dessous, il fonctionne sur la plate-forme NodeJS, mais peut être facilement modifié pour fonctionner sur n'importe quel moteur JavaScript.

--- Ancienne réponse ci-dessous ---

Google a publié Closure Compiler qui semble générer les plus petits fichiers à ce jour, comme on le voit ici et ici

Avant cela, les différentes options étaient les suivantes

Fondamentalement, Packer fait un meilleur travail lors de la compression initiale, mais si vous allez gzipper les fichiers avant de les envoyer sur le câble (ce que vous devriez faire), YUI Compressor obtient la plus petite taille finale.

Les tests ont été effectués sur du code jQuery btw.

  • Bibliothèque jQuery d'origine 62 885 octets, 19 758 octets après gzip
  • jQuery minifié avec JSMin 36 391 octets, 11 541 octets après gzip
  • jQuery minifié avec Packer 21 557 octets, 11 119 octets après gzip
  • jQuery minifié avec le compresseur YUI 31 822 octets, 10 818 octets après gzip

@ daniel james mentionne dans le commentaire compressorrater qui montre Packer en tête du graphique dans la meilleure compression, donc je suppose que ymmv

— Tapoter
source
Packer a une option pour 'encoder base62' off - et pour jQuery, il compresse plus petit que yui après gzip. Ceci est dû au fait que jquery utilise «eval» et «with» qui empêche les compresseurs «sûrs» de faire certaines compressions, mais Packer les ignore. Pas sûr en général, mais jQuery est testé pour Packer.
— Daniel James
Essayez également compressorrater.thruhere.net si vous ne me croyez pas.
— Daniel James
9
N'oubliez pas l'inconvénient du packer: le temps de décompression.
— Nosredna
1
attention, la fermeture de Google peut parfois être le pire compresseur (sortie encore plus grande que l'original) - il convertit les caractères non-ascii dans les chaînes en \uxxxxlittéraux par défaut .. utilisez par exemple --charset UTF-8(si vous êtes sûr que vous en informez le navigateur d'une manière ou d'une autre)
— mykhal
La sortie ClosureCompiler ne fonctionne pas pour moi. jscompress.com fonctionne
— codenamezero
43

YUI Compressor est la voie à suivre. Il a un excellent taux de compression, est bien testé et est utilisé parmi de nombreux sites de premier plan et, bien, personnellement recommandé par moi.

Je l'ai utilisé pour mes projets sans une seule erreur JavaScript ou un hoquet. Et il a une belle documentation.

Je n'ai jamais utilisé ses capacités de compression CSS, mais elles existent également. La compression CSS fonctionne aussi bien.

Remarque: bien que / packer / de Dean Edwards atteigne un meilleur taux de compression que YUI Compressor, j'ai rencontré quelques erreurs JavaScript lors de son utilisation.

— les kamens
source
5
Packer a l'air bien en termes de taille de fichier, mais il s'avère que le temps passé à déballer l'emporte normalement sur le gain de temps de transfert d'un fichier plus petit à travers les tubes. La plupart des benchmarks de navigateur réels que j'ai vus l'ont plus lent que les fichiers bruts non compressés servis avec gzip en termes de temps d'exécution dans le navigateur.
— Colonel Sponsz
— Colonel Sponsz
Voici une version en ligne du compresseur au cas où vous ne voudriez pas faire fonctionner Java: refresh-sf.com/yui
— Bryan Legend
Les scripts compressés à l'aide de packer n'ont pas besoin d'être décompressés sauf si vous cochez l'option d'encodage Base62 (ce que vous ne devriez pas faire car c'est un gzip profane - je suis sûr que la plupart des serveurs modernes prennent en charge gzip). Il ne sert à rien de gzipper un fichier encodé en base62 car il n'y a plus de redondance à exploiter. La dernière version de packer (la version finale) n'introduit pas de bogues, n'a pas de surcharge de décompression (tant que vous n'encodez pas en base62), et réalise toujours le plus de compression. Il existe également une version en ligne de commande de packer. Il suffit de l' installer à l' aide NPM comme suit: npm install packer. (= D
— Aadit M Shah
8

J'utilise ShrinkSafe du projet Dojo - c'est exceptionnel car il utilise en fait un interpréteur JavaScript ( Rhino ) pour trouver des symboles dans le code et comprendre leur portée, etc., ce qui permet de garantir que le code fonctionnera lorsqu'il sortira le autre extrémité, par opposition à de nombreux outils de compression qui utilisent regex pour faire de même (ce qui n'est pas aussi fiable).

En fait, j'ai une tâche MSBuild dans un projet de déploiement Web dans ma solution Visual Studio actuelle qui exécute un script qui à son tour exécute tous les fichiers JS de la solution via ShrinkSafe avant le déploiement et cela fonctionne très bien.

EDIT: Au fait, «meilleur» est ouvert au débat, puisque les critères de «meilleur» varieront en fonction des besoins du projet. Personnellement, je pense que ShrinkSafe est un bon équilibre; pour certaines personnes qui pensent que la plus petite taille == mieux, ce sera insuffisant.

EDIT: Il est à noter que le compresseur YUI utilise également Rhino.

— Jason Bunting
source
4

Si vous utilisez Packer, allez simplement loin dans l'option 'shrink variables' et gzip le code résultant. L'option base62 n'est valable que si votre serveur ne peut pas envoyer de fichiers gzippés. Packer avec 'shrink vars' réalise une meilleure compression du YUI, mais peut introduire des bogues si vous avez sauté un point-virgule quelque part.

base62 est fondamentalement le gzip d'un pauvre homme, c'est pourquoi gzipping de code base62-ed vous donne des fichiers plus gros que gzipping de code shrink-var-ed.

— jcoglan
source
1

Voici un script de compresseur YUI ( Byuic ) qui trouve tous les js et css dans un chemin et les compresse / (éventuellement) les obscurcit. Agréable à intégrer dans un processus de construction.

— Jimg
source
1

KJScompress

http://opensource.seznam.cz/KJScompress/index.html

Kjscompress / csskompress est un ensemble de deux applications (kjscompress et csscompress) pour supprimer les espaces et les commentaires non significatifs des fichiers contenant JavaScript et CSS. Les deux sont des applications de ligne de commande pour le système d'exploitation GNU / Linux.

— MicTech
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.