Gzip versus Minify

Très simple à tester. J’ai pris vos js, les ai mis dans des fichiers différents et lancé gzip -9 sur eux. Voici le résultat. Cela a été fait sur une machine WinXP exécutant Cygwin et gzip 1.3.12.

 -rwx------ 1 xxxxxxxx mkgroup-ld 88 Apr 30 09:17 expanded.js.gz -rwx------ 1 xxxxxxxx mkgroup-ld 81 Apr 30 09:18 minified.js.gz 

Voici un autre test utilisant un exemple JS du monde réel. Le fichier source est “common.js” La taille du fichier d’origine est de 73134 octets. Minifié, il est venu à 26232 octets.

Fichier d’origine:

 -rwxrwxrwx 1 xxxxxxxx mkgroup-ld 73134 Apr 13 11:41 common.js 

Fichier réduit:

 -rwxr-xr-x 1 xxxxxxxx mkgroup-ld 26232 Apr 30 10:39 common-min.js 

Fichier original compressé avec l’option -9 (même version que ci-dessus):

 -rwxrwxrwx 1 xxxxxxxx mkgroup-ld 12402 Apr 13 11:41 common.js.gz 

Fichier gzippé avec l’option -9 (même version que ci-dessus):

 -rwxr-xr-x 1 xxxxxxxx mkgroup-ld 5608 Apr 30 10:39 common-min.js.gz 

Comme vous pouvez le voir, il existe une différence nette entre les différentes méthodes. Le meilleur pari est de les minifier et de les gipper.

Voici les résultats d’un test que j’ai fait il y a longtemps, en utilisant un fichier CSS “réel” de mon site. CSS Optimiser est utilisé pour la minification. L’application d’archivage Linux standard fournie avec Ubuntu a été utilisée pour Gzipping.

Original: 28 781 octets
Minifié: 22 242 octets
Gzippé: 6 969 octets
Min + Gzip: 5 990 octets

Mon opinion personnelle est de commencer par Gzipping, car cela fait évidemment la plus grande différence. Quant à la minification, cela dépend de votre façon de travailler. Vous devez conserver le fichier CSS original pour pouvoir effectuer des modifications plus tard. Si cela ne vous dérange pas de le réduire après chaque changement, alors allez-y.

(Remarque: il existe d’autres solutions, telles que l’exécution d’un minificateur “à la demande” lors de la diffusion du fichier et de sa mise en cache dans le système de fichiers.)

Faites attention lorsque vous testez ceci: ces deux fragments de CSS sont sortingvialement petits, de sorte qu’ils ne bénéficient pas de la compression GZIP – l’ajout du petit entête de GZIP à lui seul fera perdre les gains réalisés. En réalité, vous ne devriez pas avoir un fichier CSS aussi petit et vous soucier de le compresser.

minify + gzip compresse plus que juste gzip

La réponse à la question initiale est que, oui, minify + gzip va gagner beaucoup plus de compression que juste gzip. Cela est vrai pour tout exemple non sortingvial (c.-à-d. Tout code JS ou CSS utile de plus de quelques centaines d’octets).

Pour des exemples de cela, récupérez le code source Jquery disponible, minifié et décompressé, compressez-les avec gzip et jetez un coup d’oeil.

Il est intéressant de noter que le Javascript profite beaucoup plus de la minification que du CSS bien optimisé, mais il y a toujours un avantage.

Raisonnement:

La compression GZIP est sans perte. Cela signifie qu’il doit stocker tout le texte, y compris les espaces, les commentaires, les noms de variables longues, etc., afin qu’ils puissent être reproduits parfaitement ultérieurement. Par contre, la minification est une perte. Si vous réduisez votre code, vous supprimez une grande partie de ces informations de votre code, laissant moins de place à GZIP.

• La minification rejette inutilement les espaces, ne laissant des espaces que lorsque cela est nécessaire pour des raisons syntaxiques.
• Minification supprime les commentaires.
• La minification du code peut remplacer les noms d’identificateurs avec des noms plus courts, pour lesquels il n’y aurait pas d’effets secondaires.
• La minification du code peut rendre les «optimisations du compilateur» sortingviales au code qui ne sont possibles qu’en analysant le code
• La minification CSS peut éliminer les règles redondantes ou combiner des règles qui ont le même sélecteur.

Tu as raison.

Ce n’est pas la même chose que de mincir (ils seraient appelés si c’était le cas). Par exemple, ce n’est pas la même chose pour gzip ceci:

 var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null; 

Puis minify pour finir avec quelque chose comme:

 var a = null; 

Bien sûr, je dirais que dans la plupart des cas, la meilleure approche consiste à minimiser FIRST puis Gzip, que de simplement minifier ou compresser, bien que, selon le code, il suffit parfois de minifier ou de compresser pour obtenir les deux.

Il y a un seuil pour lequel l’encodage gzip est avantageux. La règle générale est la suivante: plus le fichier est volumineux, plus la compression et le gzip seront importants. Bien sûr, vous pouvez minifier d’abord puis gzip après.

Mais si nous parlons de gzip et de minify sur un petit morceau de texte ne dépassant pas 100 octets, une comparaison “objective” n’est pas fiable, même inutile – à moins de disposer d’un texte de base pour établir un moyen standard de benchmarking, comme un type Lorem Ipsum mais écrit en Javascript ou CSS.

Alors permettez-moi de proposer de tester les dernières versions de jQuery et MooTools (les versions non compressées) en utilisant mon code PHP ( Fat-Free Minify) (en supprimant les espaces et les commentaires, sans raccourcir les variables, sans encoder en baseX)

Voici les résultats de minify vs gzip (à compression de niveau 5) vs minify + gzip:

 MooTools-Core ------------- Baseline 102,991 bytes Minified 79,414 (77.1% of original) Gzipped 27,406 (26.6%) Minified+Gzipped 22,446 (21.8%) jQuery ------ Baseline 170,095 Minified 99,735 (58.6% of original) Gzipped 46,501 (27.3%) Minified+Gzipped 27,938 (16.4%) 

Avant que quiconque ne saute à l’arme, ce n’est pas une bataille de bibliothèques JS.

Comme vous pouvez le voir, minify + gzipping vous offre une meilleure compression sur les gros fichiers . La réduction du code a ses avantages, mais le facteur majeur est la quantité d’espaces blancs et de commentaires dans le code d’origine. Dans ce cas, jQuery en a plus et donne une meilleure minification (beaucoup plus d’espaces blancs dans la documentation en ligne). La force de la compression de Gzip réside dans la quantité de répétitions dans le contenu. Donc, il ne s’agit pas de minify vs gzip. Ils font les choses différemment. Et vous obtenez le meilleur des deux mondes en utilisant les deux.

Pourquoi ne pas utiliser les deux?

Il est facile à tester: il suffit de mettre le texte de votre css dans des fichiers texte et de compresser les fichiers en utilisant un archiveur comme gzip sous linux.

Je viens de le faire, et il arrive que pour le premier css, la taille est de 184 octets et pour le second de 162 octets.

Donc, vous avez raison, l’espace blanc est important même pour les fichiers compressés, mais comme on peut le voir sur ce petit test, la taille du fichier compressé peut être supérieure à la taille du fichier d’origine.

Ceci est simplement dû à la très petite taille de votre exemple. Pour les fichiers plus volumineux, gzipping vous permettra d’obtenir de plus petits fichiers.

Je n’ai vu personne mentionner Mangling alors je publie mes résultats là-dessus.

Voici quelques chiffres que j’ai utilisés avec UflifyJS pour la minification et Gzip. J’ai eu environ 20 fichiers que j’ai concaténés ensemble à environ 2,5 Mo avec des commentaires et tout.

Fichiers Concat 2.5MB

 uglify({ mangle: false }) 

Minifié sans se tortiller: 929kb

 uglify({ mangle: true }) 

Minifié et mutilé: 617kb

Maintenant, si je prends ces fichiers et les gziper, je recevrai respectivement 239kb et 190kb.

Il existe une méthode très simple pour tester ceci: Créez un fichier composé uniquement d’espaces blancs et d’un autre fichier vraiment vide. Ensuite, Gzip les deux et comparez leurs tailles. Le fichier contenant les espaces sera bien entendu plus gros.

Bien entendu, une compression “humaine” avec pertes, qui préserve la mise en page ou d’autres éléments importants et supprime les données inutiles (espaces blancs, commentaires, éléments redondants, etc.) sera meilleure qu’une compression sans perte de gZip.

Par exemple, des choses comme des marques ou des noms de fonction seront probablement d’une certaine longueur pour décrire la signification. Remplacer ceci par des noms d’un caractère permettra d’économiser beaucoup d’espace et n’est pas possible avec la compression sans perte.

Au fait, pour CSS, il existe des outils tels que le compresseur CSS qui fera le travail avec perte pour vous.

Cependant, vous obtiendrez les meilleurs résultats en combinant “optimisation avec perte” et compression sans perte.

bien sûr, vous pouvez tester – écrivez votre fichier dans un fichier et gzipez-le avec zlib . Vous pouvez également essayer avec le programme utilitaire “gzip”.

retour à votre question – il n’y a pas de relation définie entre la longueur de la source et le résultat compressé. le point clé est «l’entropie» (la différence entre chaque élément dans la source).

donc, cela dépend de votre source. Par exemple, beaucoup d’espaces continus (ex> 1000) peuvent être compressés avec la même taille que quelques espaces (ex, <10).

ce sont les résultats lors de la gziping des deux fichiers

 bytes File 45 min.txt 73 min.gz 72 normal.txt 81 normal.gz 

Vous avez raison, minify + gzip donne moins d’octets. Aucune preuve scientifique cependant.

Comment se fait-il que vous n’ayez aucune méthode de test?

Réduisez votre code dans un fichier et laissez-le “non certifié” sur un autre. Téléchargez sur un serveur Web capable de gziper la sortie (mod_deflate pour Apache, par exemple), installez l’extension Firebug pour Firefox, effacez votre cache et accédez aux deux fichiers. L’onglet “NET” de Firebug contient la quantité exacte de données transférées, comparez-les et vous avez une preuve “empirique”.