Heim > Artikel > Web-Frontend > Der Einfluss des HTML-Schreibens auf die GZIP-Komprimierungsrate
Der Einfluss des HTML-Schreibens auf die GZIP-Komprimierungsrate
- 高洛峰Original
- 2017-03-27 14:50:161540Durchsuche
Vor ein paar Tagen habe ich gesehen, wie Xiao Du in der Gruppe einen Artikel mit dem Titel „Der Einfluss des HTML-Schreibens auf die GZIP-Komprimierungsrate“ geteilt hat, also habe ich auch diesen Punkt analysiert.
Ich weiß nicht, ob Sie diesen Artikel gelesen haben. Der Autor ist von Weibo Lazy Exchange Meeting.
Der Gzip-Algorithmus besteht hauptsächlich aus den Haferman- und LZ77-Algorithmen.
Wenn die Datei zwei identische Inhalte enthält, können wir
den Inhalt bestimmen, solange wir den Speicherort und die Größe des vorherigen Inhalts kennen und eine bestimmte Komprimierungskennung verwenden des nächsten Stückes. Daher können wir den letztgenannten Inhalt durch ein Informationspaar wie die Positionslänge ersetzen.
Beispiel
<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>Nach der Komprimierung mit gzip beträgt die in den Entwicklertools von Chrome angezeigte Größe 563 B.
Nachdem Sie die Reihenfolge der Attribute des Eingabe-Tags geändert haben:
<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>gzip-Komprimierung, sehen Sie eine Größe von 578B.
Der Inhalt des Artikels sieht ungefähr so aus. Dann habe ich ernsthaft darüber nachgedacht, ob CSS ähnliche Auswirkungen haben würde.
Schreiben Sie zuerst die Attribute in der folgenden Reihenfolge in die CSS-Datei:
@charset "utf-8";
.f1{font-size:10px; line-height: 22px; color:red;}.f2{font-size:14px; line-height: 26px; color:green;}Die von gzip angezeigte Größe beträgt 463B
Nachdem die Attribute ungeordnet sind:
@charset "utf-8";
.f1{font-size:10px; line-height: 22px; color:red;}.f2{font-size:14px; color:green; line-height: 26px;}Die Größe nach gzip beträgt 464B
Daraus können wir schließen, dass nicht nur HTML, sondern auch CSS ähnliche Auswirkungen hat.
Manche Leute fragen sich vielleicht: Was passiert, wenn sich zwischen den Zeilen andere Klassen befinden?
@charset "utf-8";
.f1{font-size:10px; color:red; line-height: 22px;}.f9{background: red;}.f2{font-size:14px; color:green; line-height: 26px;}Größe: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;}Größe:480B
Das ist Das Ergebnis unterscheidet sich von der obigen Schlussfolgerung.
Es ist ersichtlich, dass die Kontinuität zwischen Zeilen auch einen Einfluss auf die Komprimierungsrate haben kann.
Mit anderen Worten: Je höher die Codeähnlichkeitsrate, desto höher die Komprimierungsrate.
Ob es um die Komprimierungsrate oder die Sauberkeit und Schönheit des Codes geht, wir sollten den Code in der richtigen Reihenfolge schreiben, was das Team und die Komprimierung erleichtert.
Der Unterschied in den Größen-/Inhaltswerten im Netzwerk der Chrome-Entwicklertools:
Zusätzlich zur Recherche zu diesem Aspekt habe ich die Spalte „Netzwerk/Größe“ in den Chrome-Entwicklertools entdeckt Etwas schwer zu verstehen.
Ich habe lange Zeit mit seiner Größe und seinem Inhalt zu kämpfen. Ich weiß nicht, was sie bedeuten. Manchmal ist die Größe größer als der Inhaltswert und manchmal ist die Größe kleiner als der Inhaltswert.
Nach der Anleitung von CJ und meinen eigenen Experimenten wurden die folgenden Ergebnisse erzielt.
Der Größenwert bezieht sich auf die Größe des Netzwerkübertragungsinhalts, einschließlich der GZIP-Größe der Anforderungs-/Antwort-Header und der GZIP-Größe des Dateiinhalts.
Der Inhaltswert bezieht sich auf die gzip-dekomprimierte Größe des Hauptinhaltskörpers, was der Größe der Auslagerungsdatei entspricht.
Wenn Sie sehen, dass die Größe größer als der Inhaltswert ist, bedeutet dies, dass die Header viel größer sind als die gzip-Dekomprimierung des Körpers und umgekehrt.
Möglicherweise stellen Sie fest, dass der beim ersten Zugriff auf die Seite erhaltene Größenwert viel kleiner ist als der Größenwert nach der Aktualisierung. Das liegt daran, dass auf der Seite der Cache aktiviert ist und sie daher nicht erneut aus dem Netzwerk geladen werden muss.
Ich persönlich finde, dass der FireBug-Wert intuitiver ist als der Chrome-Wert. Die Größe bei FireBug ist der gzip-Wert. Es scheint, dass die Größe von gzip in Chrome nicht gefunden wird.
Sofern in den Return-Header-Informationen auf der Serverseite kein Feld „Content-Length“ vorhanden ist, können Sie in diesem Feld auch die GZIP-Größe sehen. Dieses Feld wird jedoch normalerweise nicht ausgegeben.
Das obige ist der detaillierte Inhalt vonDer Einfluss des HTML-Schreibens auf die GZIP-Komprimierungsrate. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!