Gzip contre minify

J'ai eu une discussion assez animée l'autre jour sur la réduction de Javascript et CSS par rapport à quelqu'un qui préfère utiliser Gzip.

J'appellerai 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 plus doit être compressé.

Je n'ai aucune méthode de test, mais je crois que le Gzip de ce code:

.a1 {
    background-color:#FFFFFF;
    padding: 40px 40px 40px 40px;
}

Sera toujours plus gros que le Gzip de ce code:

.a1{body:background-color:#FFF;padding:40px}

Y a-t-il quelqu'un qui puisse prouver que c'est vrai ou faux.
Et s'il vous plaît, ne venez pas dire "C'est juste parce que c'est ce que j'ai toujours utilisé".

Je demande ici une preuve scientifique.

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 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 original:

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

Fichier minifié:

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

Fichier d'origine 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é gzippé 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 mieux est de les minimiser et de les gzip.

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. L'optimiseur CSS 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 la façon dont vous travaillez. Vous devrez conserver le fichier CSS d'origine pour pouvoir apporter des modifications plus tard. Si cela ne vous dérange pas de le réduire après chaque changement, allez-y.

(Remarque: il existe d'autres solutions, telles que l'exécuter via un minificateur "à la demande" lors de la diffusion du fichier et le mettre en cache dans le système de fichiers.)

Faites attention lorsque vous testez ceci: ces deux extraits de code CSS sont trivialement petits, ils ne bénéficient donc pas de la compression GZIP - l'ajout du petit en-tête et du pied de page de GZIP (environ 20 octets de surcharge) perdra à lui seul 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 simplement gzip

La réponse à la question initiale est, oui, minify + gzip gagnera beaucoup plus de compression que le simple gzip. Ceci 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 effet, 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 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 blancs exacts, les commentaires, les noms de variables longs, etc., afin qu'ils puissent être parfaitement reproduits plus tard. 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 préserver.

• La minification supprime les espaces inutilement, ne laissant des espaces que lorsque cela est nécessaire pour des raisons syntaxiques.
• La minification supprime les commentaires.
• La minification de code peut remplacer les noms d'identifiant 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.

Vous avez raison.

Ce n'est pas la même chose de minifier que de gzipping (ils seraient appelés de la même manière si c'était le cas). Par exemple, ce n'est pas la même chose de gzip ceci:

var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;

Que minifier 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 FIRST puis Gzip, plutôt que de simplement minifier ou gzipping, bien que selon le code, la minification ou le gzipping vous donneront parfois de meilleurs résultats que 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 est la compression et gzip gagnera haut la main. Bien sûr, vous pouvez d'abord minifier puis gzip après.

Mais si nous parlons de gzip vs minify sur un petit morceau de texte ne dépassant pas 100 octets de long, une comparaison "objective" n'est pas fiable, voire inutile - à moins que nous ne sortions un texte de base pour établir un moyen standard de benchmarking, comme un Lorem de type Ipsum mais écrit en Javascript ou CSS.

Alors laissez-moi vous proposer de comparer les dernières versions de jQuery et MooTools (les versions non compressées) en utilisant mon code Fat-Free Minify (PHP) (simplement en supprimant les espaces et les commentaires, pas de raccourcissement des variables, pas de codage 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 quiconque saute le pistolet, ce n'est pas une bataille de bibliothèques JS.

Comme vous pouvez le voir, la minification + gzipping vous offre une meilleure compression sur les gros fichiers . La réduction du code a ses avantages, mais le facteur principal est la quantité d'espaces blancs 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 blancs dans la documentation en ligne). La force de la compression Gzip réside dans la quantité de répétition dans le 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?

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 sous Linux.

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

Donc, vous avez raison, l'espace blanc compte même pour les fichiers gzippés, mais comme on peut le voir à partir de ce petit test, pour de 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 volumineux, gzipping vous donnera des fichiers plus petits.

Je n'ai vu personne mentionner Mangling alors je publie mes résultats à ce sujet.

Voici quelques chiffres que j'ai trouvés 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 mutilation: 929kb

uglify({
    mangle: true
})

Minifié et mutilé: 617kb

Maintenant, si je prends ces fichiers et que je les gzip, j'obtiendrai 239kb et 190kb respectivement.

Il existe une méthode très simple pour tester ceci: créer un fichier composé uniquement d'espaces blancs et un autre fichier qui est vraiment vide. Puis Gzip les deux et comparez leurs tailles. Le fichier avec l'espace blanc sera bien sûr plus gros.

Bien sûr, une compression avec perte "humaine" qui préserve la mise en page ou d'autres éléments importants et supprime tout indésirable inutile (espaces blancs, commentaires, éléments redondants, etc.) sera meilleure qu'une compression gZip sans perte.

Par exemple, des éléments tels que des marques ou des noms de fonctions auront probablement une certaine longueur pour décrire la signification. Le remplacer par des noms d'un seul caractère économisera beaucoup d'espace et n'est pas possible avec une compression sans perte.

À propos, pour CSS, il existe des outils comme le compresseur CSS qui feront le travail avec perte pour vous.

Cependant, vous obtiendrez les meilleurs résultats en combinant «l'optimisation avec perte» et la compression sans perte.

bien sûr, vous pouvez tester - écrivez votre dans un fichier et 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 entre chaque élément de la source).

donc, cela dépend de la façon dont votre source est. par exemple, beaucoup d'espaces continus (ex,> 1000) peuvent être compressés avec la même taille que quelques espaces (ex, <10).

voici les résultats lors du gziping des deux fichiers

bytes  File
45     min.txt
73     min.gz

72     normal.txt
81     normal.gz

Vous avez raison, minify + gzip entraîne moins d'octets. Aucune preuve scientifique cependant.

Pourquoi n'avez-vous aucune méthode de test?

Réduisez votre code dans un fichier et laissez-le "non minimisé" 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 contiendra la quantité exacte de données transférées, comparez-les et vous en aurez une preuve "empirique".