Question

L’autre jour, j’ai eu une discussion quelque peu animée à propos de la minification de Javascript et du CSS par rapport à quelqu'un qui préfère utiliser Gzip.

Je vais appeler cette personne X.

X a dit que Gzip réduisait déjà le code, car il compressait vos fichiers.

Je ne suis pas d'accord. Zip est une méthode sans perte permettant de réduire la taille du fichier. Sans perte signifie que l'original doit être restauré à la perfection, 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 pas de méthode de test, mais je crois que le code 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}

Quelqu'un peut-il prouver que c'est vrai ou faux?
Et s'il vous plait, ne venez pas dire & "C'est vrai parce que c'est ce que j'ai toujours utilisé &".

Je demande une preuve scientifique ici.

Était-ce utile?

La solution

Très simple à tester. J'ai pris vos js, les ai mis dans différents fichiers et j'ai lancé gzip -9. 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 & Quot; common.js & Quot; La taille du fichier d'origine est 73134 octets. Minified, il est passé à 26232 octets.

Fichier d'origine:

-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 constater, il existe une différence nette entre les différentes méthodes. Le meilleur pari est à la fois de minify et de gzip.

Autres conseils

Voici les résultats d'un test que j'ai effectué il y a un certain temps, en utilisant une & "vraie vie &"; Fichier CSS de mon site. L'optimiseur CSS est utilisé pour la minimisation. L'application d'archivage Linux standard fournie avec Ubuntu a été utilisée pour Gzipping.

Original: 28 781 octets

Minified: 22 242 octets

Gzipped: 6 969 octets

Min + Gzip: 5 990 octets

Mon opinion personnelle est d’aborder Gzipping en premier, car cela fait évidemment toute la différence. Quant à la minification, cela dépend de la façon dont vous travaillez. Vous devez conserver le fichier CSS d'origine pour pouvoir effectuer des modifications plus tard dans la ligne. Si cela ne vous dérange pas de la minimiser après chaque changement, allez-y.

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

Faites attention en testant ceci: ces deux extraits de CSS sont trivialement petits, ils ne bénéficient donc pas de la compression GZIP - l'ajout du petit en-tête de GZIP perdra à lui seul les gains réalisés. En réalité, vous n’auriez pas un fichier CSS aussi petit et ne voudriez pas le compresser.

minify + gzip ne comprime pas que gzip

La réponse à la question initiale est, oui, minify + gzip générera beaucoup plus de compression que simplement 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 concrets, récupérez le code source de Jquery , disponible en format réduit et non compressé, puis compressé. les deux avec gzip et jetez un oeil.

Il est intéressant de noter que Javascript profite beaucoup plus de la minification que de 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 variable longs, etc., afin qu'ils puissent être parfaitement reproduits ultérieurement. Par contre, la minification est une perte. Si vous réduisez votre code, vous supprimez une grande partie de ces informations et laissez moins que GZIP doit conserver.

  • La minification supprime inutilement les espaces, 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 sans aucun effet secondaire.
  • La minification de code peut rendre triviales des "optimisations du compilateur" 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 ayant le même sélecteur.

Vous avez raison.

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

var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;

Than minify pour arriver à quelque chose comme:

var a = null;

Bien sûr, je dirais que la meilleure approche consiste dans la plupart des cas à réduire au minimum FIRST puis Gzip, au-delà du simple fait de minimiser ou de gzipper, bien que, selon le code, il suffit parfois de minimiser ou de gzipper pour obtenir de meilleurs résultats que de faire les deux.

Il existe un seuil pour lequel le codage gzip est avantageux. La règle générale est la suivante: plus le fichier est gros, meilleure sera la compression et gzip gagnera haut la main. Bien sûr, vous pouvez commencer par minifier puis par gzip après.

Mais si nous parlons de gzip par rapport à minify sur un petit texte ne dépassant pas 100 octets de long, un & "objectif &"; la comparaison est peu fiable, voire inutile - à moins que nous ne fournissions un texte de base pour établir un moyen standard d'analyse comparative, du type Lorem Ipsum mais écrit en Javascript ou en CSS.

Alors, permettez-moi de vous proposer de comparer les dernières versions de jQuery et de MooTools (les versions non compressées) à l'aide de Code Fat-Free Minify (PHP) (élimine simplement les espaces et les commentaires, pas de raccourcissement des variables, pas de codage baseX)

Voici les résultats de minify par rapport à gzip (avec une compression conservative de niveau 5) par rapport à 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 fusil, ce n'est pas une bataille de bibliothèques JS.

Comme vous pouvez le constater, la réduction de la taille + gzipping vous permet de mieux compresser les fichiers volumineux . Réduire le code a ses avantages, mais le facteur principal est combien d'espaces et de commentaires sont présents dans le code d'origine. Dans ce cas, jQuery 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. Donc, il ne s'agit pas de minify ou de 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 en utilisant un archiveur comme gzip sous linux.

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

Donc, vous avez raison, l'espace blanc est important même pour les fichiers compressés, mais comme le montre ce petit test, pour de très petits fichiers, la taille du fichier compressé peut être supérieure à celle du fichier d'origine.

Cela est dû à la très petite taille de votre exemple. Pour les fichiers plus volumineux, gzipping vous permettra d'obtenir 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 créé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 de concaténation 2,5 Mo

uglify({
    mangle: false
})

Minified sans mutilations: 929kb

uglify({
    mangle: true
})

Minified et mutilé: 617ko

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

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

Bien sûr & "Humain &"; Une compression avec perte qui préserve la mise en page ou d'autres éléments importants et supprime les fichiers inutiles (espaces, commentaires, éléments redondants, etc.) sera préférable à une compression gZip sans perte.

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

Soit dit en passant, il existe des outils tels que Compresseur CSS ça va faire le travail avec pertes pour vous.

Cependant, vous obtiendrez de 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 gzip-le avec zlib . Vous pouvez également essayer avec le & Quot; gzip & Quot; programme utilitaire.

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" (chaque élément de la source est différent).

alors, cela dépend de la façon dont votre source est. par exemple, de nombreux espaces continus (ex, > 1000) peuvent être compressés avec 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

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?

Minimisez votre code dans un fichier et laissez-le " non minié " sur un autre. Chargez sur un serveur Web capable de gérer la sortie (mod_deflate pour Apache, par exemple), installez l'extension Firebug pour firefox, effacez le cache et accédez aux deux fichiers. & "; NET &" De Firebug Onglet contient la quantité exacte de données transférées, comparez-les et vous avez & "; empirique &"; preuve.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top