PageRangers.com
PageRangers Hilfebereich

Was ist eine HTTP-Komprimierung?

Bei einer Datenkomprimierung (Datenkompression) handelt es sich um das "Packen" textbasierter Dateien (z.B. HTML-Dateien). Die HTML-Dateien liegen beim Server unkomprimiert und werden auf Anfrage vom Client (Browser) komprimiert, übermittelt und dort wieder dekomprimiert. Bei dem Prozess werden redundante Daten (sich wiederholende Daten wie html-Tags) entfernt und die digitalen Daten ohne Verlust auf ein Minimum reduziert. Bei der Dekomprimierung werden die redundanten Informationen wieder ersetzt und der Browser kann die vollständige Datei anzeigen. 

Ein Beispiel zur Veranschaulichung der Komprimierung:

Ursprünglicher Text: Mein Hut, der hat drei Ecken, drei Ecken hat mein Hut.
Kodierter Text: Mein Hut, der hat drei Ecken, -2 -2 -5 -9 -9.

Hier wurden die Wörter „drei“, „Ecken“, „hat“, „mein“ und „Hut“ kodiert. Die Zahlen geben an, an welcher Stelle die Wörter schon vorkamen (-2 = zwei Stellen zurück). Durch dieses Verfahren können Texte auf die nötigsten Informationen reduziert werden. 

 

Nutzen einer HTML-Kompression

Die Datenkomprimierung findet heutzutage bei jeglicher digitaler Datenübertragung statt. Ein Großteil der dafür benötigten Ressourcen, wie Bandbreite oder Speicherplatz, werden durch die Kompression gespart. Der Betreiber einer komprimierten Webseite spart durch das Verfahren viele Ressourcen ein, da nur ein geringer Teil der sonst benötigten Bandbreite genutzt wird. Durchschnittlich werden Webseiten mit HTML-Dateien auf ¼ der Originalgröße reduziert. Denn je höher der textbasierte Inhalt ist, desto höher ist die mögliche Einsparung bei der Komprimierung.

Reine HTML-Texte können auf 10-20% der Originalgröße reduziert werden.

Durch die Daten-Komprimierungen auf Webseiten laden die Dokumente schneller und sind für den User in kürzerer Zeit nutzbar. Komprimierte HTML-Seiten werden mit weniger Bytes übertragen. Dies spart Ressourcen und Geld für den Seitenbetreiber und sorgt für verkürzte Ladezeiten. Die Benutzerfreundlichkeit wird dadurch gesteigert und dies sorgt für eine geringere Absprungrate (Bounce Rate) beim Nutzer, da User Seiten mit langen Ladezeiten eher verlassen. Falls ein Browser komprimierte Daten beim User nicht laden kann, da er dies nicht unterstützt, werden die Daten auf herkömmliche Weise (unkomprimiert) übertragen.

Vorteile komprimierter HTML-Webseiten

  • Bis zu 80% kleiner, in Einzelfällen mehr
  • Komprimierte Datei wird schneller zum Benutzer/User übertragen
  • Geringere Absprungsrate (Bounce Rate), keine langen Ladezeiten
  • Spart Geld für den Seitenbetreiber, kleinere Seitengröße = geringere Kosten für den verbrauchten Traffic
  • Der Server kann so mehr User/Surfer verkraften
  • Für Suchmaschinen (z.B. Google) ist die Dauer der Ladezeit ein Rankingfaktor 

Macht eine komprimierte Bild-Übertragung Sinn?

Datentypen, wie Bilder, Audio- oder Video-Dateien, sind bereits durch den Entstehungsprozess komprimiert. Bei dem Grafikformat PNG werden beispielsweise die relevanten Farben gespeichert und die weniger relevanten Farbwerte werden aus Erfahrungswerten vorhergesagt. Diese Komprimierung wird "verlustbehaftete Komprimierung" genannt, da Informationen unumkehrbar entfernt werden. Grundsätzlich werden nur die Abweichungen gespeichert und der Rest beim Aufrufen des Bildes ergänzt. Eine erneute Kompression ist daher bei solchen Daten nutzlos. Die Größe eines Ordners von komprimierten Bildern unterscheidet sich nur minimal von einem Ordner mit unkomprimierten Bildern. Daher wird das Kompressionsverfahren bei Bildern üblicherweise nicht benutzt.

 

Verfahren der HTTP-Komprimierung

Wenn man mit einem Browser eine Webseite aufrufen möchte, schickt der Browser dem Server verschiedene Vorschläge, die er als Antwort vom Server verstehen kann. Sie sind im Header der Anfrage des Browsers (Clients) gelistet und werden vom Webserver interpretiert.

Accept: Welche Art von Datentypen kann der Client (Browser) verarbeiten, z. B. html
Accept-Charset: Welche Zeichensätze kann der Client (Browser) anzeigen, z. B. utf-8
Accept-Language: Welche Sprachen akzeptiert der Client (Browser), z. B. en-US

Wenn man im http-Request festlegen möchte, dass man möglichst komprimierte Antworten erhalten möchte, legt man im http-Request folgendes fest:

Accept-Encoding: Hier steht, was man dekomprimieren kann, z. B. Accept-Encoding: gzip,
deflate

Die erfolgte http-Antwort (http-Response) vom Webserver ist im http-Response-Header einsehbar und gibt an, mit welchen Angaben er mit dem Client übereinstimmt:

Content-Encoding: Hier steht, welche Komprimierung der Server gewählt hat, z. B. Content-Encoding: gzip

Wenn alle Anforderungen vom Browser mit den Anforderungen vom Webserver übereinstimmen, wird der Status-Code 200 ausgegeben, der besagt, dass die Webseite erfolgreich geladen werden konnte.
 

Die häufigsten Komprimierungsarten

Viele Komprimierungsverfahren basieren auf dem Ziv-Lempel- (ZIP-) Verfahren. Bei dem lexikonbasierten Verfahren werden Daten durch Codes/Zeiger ersetzt (Dienstag => Di, August => 8). Dadurch wird der Text kürzer und für die Übertragung werden weniger Bytes benötigt. Die heute verwendeten Algorithmen (z.B. die Entropiekodierung) basieren auf dem ZIP-Verfahren von 1977. Bei dieser Codierung wird zunächst die Häufigkeit der auftretenden Bit-Muster ermittelt. Die Huffmankodierung und die Arithmetische Kodierung bauen auf dieser Kodierung auf und unterscheiden sich nur in der Bit-Vergabe.

Bei der progressiven Kompression (auch kompakte oder solide Kompression genannt) werden die Daten zu so wenig Blöcken wie möglich zusammengefasst. Je ähnlicher die Daten sich sind, desto kleiner können sie komprimiert werden. Dadurch erhält man die kleinstmögliche Kompression. Packprogramme wie RAR oder 7-ZIP beherrschen dieses Verfahren (Windows ZIP jedoch nicht). Jedoch muss man beachten, dass alle Daten beschädigt sind, wenn das Archiv einen Defekt bekommt.

Bei dem Deflate-Verfahren wurde der Lempel-Ziv-Storer-Szymanski-Algorithmus und die Huffmankodierung kombiniert. Der Deflate-Algorithmus wurde von Phil Katz entwickelt und garantiert eine verlustlose Datenkompression, weshalb die Methode sehr beliebt ist. Zunächst werden alle doppelten Zeichenketten gesucht und mit kürzeren Symbolen ersetzt. Je häufiger eine Zeichenkette auftaucht, desto kürzer ist das Symbol (Entropiekodierung nach Huffman). Je größer das Datenfenster (die Menge der Daten) ist, desto größer ist die Wahrscheinlichkeit eine ersetzbare Zeichenfolge (Kette) zu finden. Dementsprechend braucht der Algorithmus dann länger für die Komprimierung. Wenn bei der Komprimierung eine schnelle Ausführungsgeschwindigkeit bevorzugt wird, leidet die Datenreduktion darunter.
Der Deflate-Algorithmus wurde von Phil Katz für das ZIP-Dateiformat (engl.: Reißverschluss) entwickelt. Das Format erkennt man an der Endung .zip. Es dient zur platzsparenden Archivierung und als Containerdatei, in der mehrere Dateien zu einer komprimierten Ordner-Datei zusammengefasst wurden. Der Datencontainer kann mit einem Passwort geschützt werden und Speicher-Pfade mitspeichern. Die beinhalteten Daten innerhalb des Containers werden einzeln komprimiert. Zwar wird die ZIP-Datei so nicht auf die kleinstmögliche Dateigröße komprimiert, jedoch sind sie so flexibel und können nach Belieben gelöscht und bearbeitet werden, ohne dass man alles neu komprimieren muss.