Gzip vs minify
L'autre jour, j'ai eu une discussion un peu animée sur la réduction de Javascript et CSS par rapport à quelqu'un qui préfère utiliser Gzip.
Je vais appeler cette personne X.
X a dit que Gzip minimise déjà le code, car il zippe vos fichiers.
Je ne suis pas d'accord. Zip est une méthode sans perte de réduction de la taille des fichiers. Sans perte signifie que l'original doit être parfaitement restauré, ce qui signifie que les informations doivent être stockées pour pouvoir restaurer les espaces, les caractères inutiles, le code commenté et tout le reste. Cela prend plus de place, car il faut en compresser davantage.
Je n'ai aucune méthode de test, mais je pense que le Gzip de ce code:
.a1 {
background-color:#FFFFFF;
padding: 40px 40px 40px 40px;
}
Sera toujours plus grand que le Gzip de ce code:
.a1{body:background-color:#FFF;padding:40px}
Y a-t-il quelqu'un qui peut prouver ce bien ou ce mal?.
Et je vous en prie, ne venez pas dire "C'est vrai parce que c'est ce que j'ai toujours utilisé".
Je demande des preuves scientifiques ici.
Très simple à tester. J'ai pris vos js, je les ai mis dans différents fichiers et j'ai exécuté gzip -9 dessus. Voici le résultat. Cela a été fait sur une machine WinXP exécutant Cygwin et gzip 1.3.12.
-rwx------ 1 xxxxxxxx mkgroup-l-d 88 Apr 30 09:17 expanded.js.gz
-rwx------ 1 xxxxxxxx mkgroup-l-d 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-l-d 73134 Apr 13 11:41 common.js
fichier réduit:
-rwxr-xr-x 1 xxxxxxxx mkgroup-l-d 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-l-d 12402 Apr 13 11:41 common.js.gz
Fichier minifié compressé avec l'option -9 (même version que ci-dessus):
-rwxr-xr-x 1 xxxxxxxx mkgroup-l-d 5608 Apr 30 10:39 common-min.js.gz
Comme vous pouvez le voir, il existe une nette différence entre les différentes méthodes. Le meilleur pari est de les réduire et de les compresser.
Voici les résultats d'un test que j'ai fait il y a quelque temps, en utilisant un fichier CSS "réel" de mon site Web. 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 d'opter pour Gzipping en premier, car cela fait évidemment la plus grande différence. Quant à la minification, cela dépend de la façon dont vous travaillez. Vous devez conserver le fichier CSS d'origine afin d'effectuer des modifications plus loin sur la ligne. Si cela ne vous dérange pas de le minimiser après chaque changement, allez-y.
(Remarque: il existe d'autres solutions, telles que son exécution via un minifieur "à la demande" lors de la diffusion du fichier et sa mise en cache dans le système de fichiers.)
Faites attention lorsque vous testez ceci: ces deux extraits de CSS sont trivialement petits, donc ils ne bénéficient pas de la compression GZIP - l'ajout du petit en-tête de GZIP seul perdra les gains réalisés. En réalité, vous n'auriez pas un fichier CSS aussi petit et vous vous soucieriez de le compresser.
minify + gzip compresse plus que juste gzip
La réponse à la question d'origine est, oui, minify + gzip gagnera une compression plus importante que juste gzip. Cela est vrai pour tout exemple non trivial (c'est-à-dire tout code JS ou CSS utile de plus de quelques centaines d'octets).
Pour des exemples de cela en vigueur, récupérez le code source Jquery qui est disponible minifié et non compressé, compressez-les tous les deux avec gzip et jetez un œil.
Il convient de noter que Javascript bénéficie beaucoup plus de la minification que le 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 exacts, les commentaires, les noms de variables longs, etc., afin qu'ils puissent être parfaitement reproduits ultérieurement. D'un autre côté, la minification est avec perte. Si vous réduisez votre code, vous supprimez une grande partie de ces informations de votre code, laissant moins que GZIP a besoin de conserver.
- La minification supprime inutilement les espaces blancs, ne laissant des espaces que lorsque cela est nécessaire pour des raisons syntaxiques.
- La minification supprime les commentaires.
- La minification du code peut remplacer les noms d'identifiants par des noms plus courts là où il n'y aurait pas d'effets secondaires.
- La minification du code peut apporter des `` optimisations de compilateur '' triviales au code qui ne sont possibles qu'en analysant réellement 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 pour minimiser que gzipping (ils seraient appelés de la même façon si c'était le cas). Par exemple, ce n'est pas la même chose pour gzip ceci:
var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;
Que minify pour finir avec quelque chose comme:
var a = null;
Bien sûr, je dirais que la meilleure approche dans la plupart des cas est de minimiser d'abord puis Gzip, que de simplement minifier ou gzipper, bien que selon le code, parfois, simplement minifier ou gzipping vous donnera de meilleurs résultats que de faire les deux.
Il existe un seuil auquel l'encodage gzip est avantageux. La règle générale est la suivante: plus le fichier est volumineux, meilleure sera la compression et gzip gagnera haut la main. Bien sûr, vous pouvez tout d'abord réduire puis gzip.
Mais si nous parlons de gzip vs minify sur un petit morceau de texte ne dépassant pas 100 octets, une comparaison "objective" n'est pas fiable, voire inutile - à moins que nous ne sortions avec 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 comparer les dernières versions de jQuery et MooTools (les versions non compressées) en utilisant mon Fat-Free Minify (PHP) code (simplement en supprimant les espaces blancs et les commentaires, pas de raccourcissement des variables, non encodage baseX)
Voici les résultats de minify vs gzip (à une compression conservatrice 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 quelqu'un ne saute le pistolet, ce n'est pas une bataille de bibliothèques JS.
Comme vous pouvez le voir, la minification + gzipping vous donne une meilleure compression sur les gros fichiers . La réduction du code a ses avantages, mais le principal facteur est la quantité d'espaces et de commentaires présents dans le code d'origine. Dans ce cas, jQuery en a plus, donc il donne une meilleure minification (beaucoup plus d'espaces dans la documentation en ligne). La force de la compression Gzip réside dans la répétition du contenu. Il ne s'agit donc 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?
Je n'ai vu personne mentionner Mangling, donc je publie mes résultats là-dessus.
Voici quelques chiffres que j'ai trouvé en utilisant UflifyJS pour la minification et Gzip. J'avais environ 20 fichiers que j'ai concaténés ensemble à environ 2,5 Mo avec des commentaires et tout.
Fichiers Concat 2,5 Mo
uglify({
mangle: false
})
Minifié sans mutiler: 929kb
uglify({
mangle: true
})
Minifié et mutilé: 617kb
Maintenant, si je prends ces fichiers et les gzip, j'obtiendrai respectivement 239kb et 190kb.
C'est facile à tester: il suffit de mettre le texte de votre css dans des fichiers texte et de compresser les fichiers à l'aide d'un archiveur comme gzip sur linux.
Je viens de le faire, et il arrive que pour le premier css, la taille soit de 184 octets et pour le second de 162 octets.
Donc, vous avez raison, l'espace blanc compte même pour les fichiers compressés, mais comme on peut le voir dans ce petit test, pour les très petits fichiers, 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 gros, gzipping vous donnera des fichiers plus petits.
Il existe une méthode très simple pour tester ceci: créez un fichier composé uniquement d'espaces et d'un autre fichier vraiment vide. Ensuite, Gzip les deux et comparez leurs tailles. Le fichier contenant les espaces sera bien entendu plus volumineux.
Bien sûr, une compression avec perte "humaine" qui préserve la mise en page ou d'autres éléments importants et supprime les fichiers inutiles (espaces blancs, commentaires, choses redondantes, etc.) sera meilleure qu'une compression gZip sans perte.
Par exemple, des éléments tels que des marques ou des noms de fonction seront très probablement d'une certaine longueur pour décrire la signification. Remplacer cela par des noms d'un caractère permettra d'économiser beaucoup d'espace et n'est pas possible avec une compression sans perte.
Soit dit en passant, pour CSS, il existe des outils comme Compresseur CSS qui feront 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 le gzip avec zlib . Vous pouvez également essayer avec le programme utilitaire "gzip".
revenons à 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 (quelle est la différence de chaque élément dans la source).
cela dépend donc de la source de votre source. par exemple, de nombreux espaces continus (ex,> 1000) peuvent être compressés de la même taille que quelques espaces (ex, <10).
ce sont les résultats lors du gzip des deux fichiers
bytes File
45 min.txt
73 min.gz
72 normal.txt
81 normal.gz