Maison  >  Article  >  interface Web  >  L'impact de l'écriture HTML sur le taux de compression gzip

L'impact de l'écriture HTML sur le taux de compression gzip

高洛峰
高洛峰original
2017-03-27 14:50:161535parcourir

Il y a quelques jours, j'ai vu Xiao Du partager un article dans le groupe, "L'impact de l'écriture HTML sur le taux de compression gzip", j'ai donc également analysé ce point.
Je ne sais pas si vous avez lu cet article. L'auteur est de Weibo Lazy Exchange Meeting Permettez-moi de décrire brièvement son contenu ici.

L'algorithme Gzip est principalement composé des algorithmes Haferman et LZ77.
S'il y a deux éléments de contenu dans le fichier qui sont identiques, alors tant que nous connaissons l'emplacement et la taille du contenu précédent, et grâce à un identifiant de compression spécifique,
nous pouvons déterminer le contenu de la pièce suivante. Nous pouvons donc remplacer ce dernier élément de contenu par une paire d'informations telles que la longueur de la position.

Exemple


<html><head>
    <title></title>
    <meta charset="utf-8" /></head><body>
    <form action="">
        <input class="J_Textarea" type="text" name="name123" id="id1"/>
        <input class="J_Textarea" type="password" name="name223" id="id2"/>
        <input class="J_Textarea" type="radio" name="name323" id="id3"/>
        <input class="J_Textarea" type="checkbox" name="name423" id="id4"/>
    </form></body></html>

Après compression avec gzip, la taille affichée dans les outils de développement de Chrome est de 563 B.

Après avoir mélangé l'ordre des attributs de la balise d'entrée :


<html><head>
    <title></title>
    <meta charset="utf-8" /></head><body>
    <form action="">
        <input class="J_Textarea" type="text" name="name123" id="id1"/>
        <input name="name123" class="J_Textarea" type="password" id="id2"/>
        <input type="radio" id="id3" name="name323" class="J_Textarea"/>
        <input id="id4" type="checkbox" class="J_Textarea" name="name423"/>
    </form></body></html>

compression gzip, la taille que vous voyez est 578B.

Le contenu de l'article est à peu près comme ceci. Ensuite, j'y ai réfléchi de manière décisive, CSS aurait-il des effets similaires ?
Écrivez d'abord les attributs dans le fichier CSS dans l'ordre :


@charset "utf-8"; 
.f1{font-size:10px; line-height: 22px; color:red;}.f2{font-size:14px; line-height: 26px; color:green;}

La taille vue par gzip est de 463B
Une fois les attributs désordonnés :


@charset "utf-8"; 
.f1{font-size:10px; line-height: 22px; color:red;}.f2{font-size:14px; color:green; line-height: 26px;}

La taille après gzip est de 464B

De là, nous pouvons conclure que non seulement le HTML, mais aussi le CSS ont des effets similaires.
Certaines personnes pourraient se demander : que se passera-t-il s'il y a d'autres classes entre les rangées ?


@charset "utf-8"; 
.f1{font-size:10px; color:red; line-height: 22px;}.f9{background: red;}.f2{font-size:14px; color:green; line-height: 26px;}

taille : 482B


@charset "utf-8"; 
.f1{font-size:10px; line-height: 22px; color:red;}.f9{background: red;}.f2{font-size:14px; color:green; line-height: 26px;}

taille : 480B

C'est le résultat C'est différent de la conclusion ci-dessus.
On constate que la continuité entre les lignes peut également avoir un impact sur le taux de compression.
En d’autres termes, plus le taux de similarité du code est élevé, plus le taux de compression est élevé.
Que ce soit en termes de taux de compression ou de propreté et de beauté du code, nous devons écrire le code dans l'ordre, ce qui convient à l'équipe et à la compression.

La différence de valeurs taille/contenu dans le réseau des outils de développement Chrome :
En plus de rechercher cet aspect, j'ai découvert la colonne Réseau/Taille dans les outils de développement Chrome Un peu difficile à comprendre.
J'ai du mal avec sa taille et son contenu depuis longtemps. Je ne comprends pas ce qu'ils veulent dire. Parfois, la taille est supérieure à la valeur du contenu, et parfois, la taille est inférieure à la valeur du contenu.
Après les conseils de CJ et mes propres expériences, les résultats suivants ont été obtenus.

La valeur de taille fait référence à la taille du contenu de transmission réseau, qui inclut la taille gzip des en-têtes de requête/réponse et la taille gzip du contenu du fichier.
La valeur Contenu fait référence à la taille gzip décompressée du corps du contenu principal, qui correspond à la taille du fichier d'échange.

Si vous voyez que la taille est plus grande que la valeur du contenu, cela signifie que ses en-têtes sont beaucoup plus grands que la décompression gzip du corps, et vice versa.
Vous constaterez peut-être que la valeur de taille obtenue lors du premier accès à la page est bien inférieure à la valeur de taille après l'actualisation. En effet, le cache de la page est activé, il n'est donc pas nécessaire de la recharger depuis le réseau.
Personnellement, je pense que la valeur FireBug est plus intuitive que la valeur Chrome. La taille sur FireBug est la valeur gzip. Il semble que la taille de gzip ne soit pas trouvée dans Chrome.
À moins qu'il n'y ait un champ Content-Length dans les informations d'en-tête de retour côté serveur, vous pouvez également voir la taille du gzip à partir de ce champ. Mais ce champ n'est généralement pas affiché.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn