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 Online Datenübertragung statt. Ein Großteil der dafür benötigten Ressourcen, wie Bandbreite oder Speicherplatz, werden durch Komprimieren 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 Datenkomprimierungen auf Webseiten laden die Dokumente schneller und sind für den User in kürzerer Zeit nutzbar. Verpackte 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 Seiten beim User nicht laden kann, da er dies nicht unterstützt, werden diese auf herkömmliche Weise (unkomprimiert) übertragen.
Vorteile komprimierter HTML-Webseiten
- Bis zu 80% kleiner, in Einzelfällen mehr
- Verpackte Datei wird schneller zum Benutzer/User übertragen
- Geringere Absprungrate (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 optimiert. 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 einige Teile unumkehrbar entfernt werden. Grundsätzlich werden nur die Abweichungen gespeichert und der Rest beim Aufrufen des Bildes ergänzt. Eine erneute Verpackung 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 verpackte 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 Wörter durch Codes/Zeiger ersetzt (Dienstag => Di, August => 8). Dadurch wird der Inhalt kürzer und für die Online Ü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 kompaktes oder solides Komprimieren genannt) werden die Daten zu so wenig Blöcken wie möglich zusammengefasst. Je ähnlicher die Daten sich sind, desto kleiner können sie am Ende 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 verlustloses Komprimieren der Daten, 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 Informationen) 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 kleineren 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.
