Verlustfreie Kompression: Definition, Algorithmen, Web

Was ist verlustfreie Kompression?

Verlustfreie Kompression (Lossless Compression) verkleinert eine Datei, ohne Informationen zu verwerfen: Beim Entpacken erhältst du exakt die ursprünglichen Bytes zurück. Sie kodiert wiederkehrende Muster kompakter, daher schrumpfen Text, Code, JSON und HTML stark, während bereits komprimierte Daten kaum kleiner werden.

Das Gegenstück ist die verlustbehaftete Kompression, die Details dauerhaft entfernt, die Auge oder Ohr kaum vermissen (JPEG, MP3, die meisten Videos). Verlustfrei brauchst du überall, wo jedes Bit zählt: Quellcode, ausführbare Dateien, Datenbanken, Archive sowie das HTML, CSS, JavaScript und JSON, das dein Server ausliefert.

So funktioniert verlustfreie Kompression

Verlustfreie Algorithmen finden Redundanz und entfernen sie. Zwei Techniken leisten den Großteil der Arbeit:

• Wörterbuchkodierung (LZ77-Familie): Eine wiederholte Zeichenfolge wird durch einen kurzen Verweis auf eine frühere Kopie ersetzt. gzip, Zstandard und LZ4 basieren darauf.
• Entropiekodierung (Huffman, arithmetische Kodierung): Häufige Symbole bekommen kürzere Codes als seltene. Die meisten Kompressoren nutzen sie als letzten Schritt.

Brotli verbindet diese Ideen mit Kontextmodellierung und einem eingebauten Wörterbuch. Laut MDN kann Text bis zu 60 % Redundanz enthalten, deshalb lässt er sich so gut komprimieren.

Gängige verlustfreie Algorithmen

Verlustfrei oder verlustbehaftet

Verlustfrei liefert das exakte Original zurück. Verlustbehaftet liefert eine Annäherung und erreicht meist kleinere Größen. Manche Formate, etwa WebP, unterstützen beide Modi.

Verlustfreie Kompression im Web

HTTP-Kompression ist verlustfrei. Der Browser nennt in Accept-Encoding, was er unterstützt, der Server wählt eines, komprimiert den Body und kennzeichnet ihn in Content-Encoding. Der Header Vary: Accept-Encoding sorgt dafür, dass Caches und CDNs jede Variante getrennt speichern.

GET / HTTP/1.1
Accept-Encoding: br, gzip

HTTP/1.1 200 OK
Content-Encoding: br
Vary: Accept-Encoding
Content-Type: text/html

Diese Kodierungen begegnen dir in der Praxis (siehe MDN-Leitfaden zur Kompression):

Liefere Brotli, wo der Client es unterstützt, und falle auf gzip zurück. Laut MDN kann Kompression manche Dokumente um bis zu 70 % verkleinern, was die Übertragungszeit senkt und Ladewerte wie LCP verbessern kann (siehe Core Web Vitals). Eine Anleitung für die Server-Seite: gzip auf NGINX aktivieren.

Welchen Kompressor du nutzt

• HTML, CSS, JavaScript, JSON über HTTP: Brotli, mit gzip als Fallback. Statische Dateien komprimierst du einmal beim Build auf hoher Stufe. Dynamische Antworten brauchen eine schnellere, niedrigere Stufe, damit die CPU-Zeit die Latenz nicht erhöht.
• Echtzeit-Streams und Daten im Speicher: LZ4 oder Snappy, die Rate gegen Tempo tauschen.
• Langzeitarchive: xz oder Zstandard auf hoher Stufe, wo die Rate wichtiger ist als die Geschwindigkeit.
• Logs und viele ähnliche Payloads: Zstandard, optional mit gemeinsamem Wörterbuch.

Häufige Fehler

• Bereits komprimierte Dateien erneut komprimieren. JPEG, MP4, ZIP und ähnliche Formate werden nicht kleiner, der Zusatzdurchlauf kostet CPU und kann die Datei sogar vergrößern.
• Bilder mit einem Textalgorithmus komprimieren. Liefere Bilder stattdessen in einem Bildformat aus. Siehe Bildgröße.
• Vary: Accept-Encoding vergessen. Ohne ihn kann ein Cache eine komprimierte Antwort an einen Client liefern, der sie nicht lesen kann.
• Auf jeder Anfrage die höchste Stufe nutzen. Die letzten Prozent Größe kosten viel CPU. Spare sie dir für Dateien auf, die du nur einmal komprimierst.
• Annehmen, dass Kompression aktiv ist. Eine Proxy-, CDN- oder Origin-Einstellung kann sie ohne sichtbaren Fehler abschalten. Prüfe die Response-Header.

Kompression mit LoadFocus prüfen

Ein falsch konfigurierter Server kann monatelang unkomprimiertes JSON ausliefern, ohne dass es jemand merkt. LoadFocus API-Monitoring kann neben Statuscode, Inhalt und Antwortzeit auch Response-Header prüfen, sodass ein Check fehlschlägt, wenn Content-Encoding fehlt, und zerlegt die Antwortzeit in Wartezeit, DNS, TCP-Verbindung, erstes Byte (TTFB) und Download. Kostenlose Checks laufen alle 5 Minuten. Ein Lasttest aus 25 Regionen liefert Antwortzeit-Perzentile, Latenz und Durchsatz unter Last und zeigt, ob die CPU-Kosten der Kompression zur Spitzenzeit schaden.

Häufige Fragen: verlustfreie Kompression

Was ist der beste verlustfreie Kompressor?

Das hängt davon ab, was du eintauschst. xz erreicht eine hohe Rate, ist aber langsam, Zstandard balanciert Tempo und Rate, LZ4 ist am schnellsten, und gzip ist am kompatibelsten. Für Web-Antworten: Brotli mit gzip als Fallback.

Warum wird meine Datei nicht kleiner?

Wahrscheinlich ist keine Redundanz mehr übrig. JPEG, MP4, verschlüsselte Daten und bereits komprimierte Archive wirken auf einen Kompressor fast zufällig.

Sollte ich JSON komprimieren?

Ja. JSON wiederholt Schlüsselnamen stark und lässt sich daher meist gut komprimieren. Aktiviere gzip oder Brotli für deine API-Antworten und prüfe es an den Response-Headern.

Ist PNG verlustfrei?

Ja. PNG und GIF sind verlustfrei, JPEG ist verlustbehaftet, und WebP kann beides. Nimm PNG für Screenshots und Logos, JPEG oder WebP für Fotos.

Ist Brotli besser als gzip?

Für Text über HTTP meist ja: Laut README ist es ähnlich schnell wie Deflate, aber dichter. Die Unterstützung ist breit, also liefere Brotli und behalte gzip als Fallback.

Sollte ich vor dem Verschlüsseln komprimieren?

Wenn du Dateien selbst verschlüsselst, ja, denn verschlüsselte Ausgabe wirkt zufällig und lässt sich nicht komprimieren. HTTP-Kompression wird auf die Antwort angewendet, bevor TLS sie verschlüsselt.