Komprimieren

Kurz: Daten so umkodieren, dass sie weniger Speicherplatz belegen.

Genauer: Verlustfreie Kompression (z. B. bei ZIP) rekonstruiert beim Dekomprimieren exakt die Originaldaten — genutzt für Programme, Dokumente, Archive. Verlustbehaftete Kompression (z. B. bei MPEG oder JPEG) opfert für noch kleinere Dateigrößen einen Teil der Information, was bei Bild/Video/Audio oft kaum wahrnehmbar ist.

Im Detail

Verlustfreie Kompressionsalgorithmen (z. B. DEFLATE, das Basisverfahren hinter ZIP und PNG) nutzen aus, dass echte Daten selten wirklich zufällig sind — sie enthalten Wiederholungen und Muster, die sich kürzer kodieren lassen. Ein einfaches Grundprinzip: kommt eine Zeichenfolge mehrfach vor, wird sie beim zweiten Mal nur noch als Verweis auf das erste Vorkommen gespeichert, statt erneut ausgeschrieben zu werden. Text und Quellcode komprimieren deshalb meist sehr gut (viele Wiederholungen), bereits komprimierte Daten (JPEG-Bilder, gezippte Archive) dagegen kaum noch, weil dort kaum noch Redundanz übrig ist.

Verlustbehaftete Kompression (z. B. bei JPEG, MP3, MPEG) geht einen anderen Weg: statt nur Redundanz zu entfernen, wird gezielt Information verworfen, die für den Menschen kaum wahrnehmbar ist (z. B. Frequenzen außerhalb des menschlichen Hörbereichs bei Audio, feine Farbnuancen bei Bildern). Dadurch sind deutlich höhere Kompressionsraten möglich als bei verlustfreien Verfahren, aber eben nicht mehr rückgängig zu machen.

Verbreitete Algorithmen im Vergleich

Neben DEFLATE (ZIP, gzip, PNG) gibt es mehrere modernere verlustfreie Algorithmen mit unterschiedlichen Kompromissen zwischen Kompressionsgeschwindigkeit und -verhältnis: LZMA (genutzt von 7-Zip) erreicht meist deutlich bessere Kompressionsraten als DEFLATE, braucht dafür aber mehr Rechenzeit und Arbeitsspeicher — gut geeignet, wenn Archive einmal erstellt und oft heruntergeladen werden, weniger gut für Echtzeitkompression. Brotli (von Google entwickelt, speziell für Web-Assets optimiert) und Zstandard (von Facebook/Meta) sind neuere Algorithmen, die versuchen, das Beste aus beiden Welten zu verbinden — sehr gute Kompression bei gleichzeitig hoher Geschwindigkeit, weshalb sie zunehmend gzip in Webservern ablösen (z. B. Content-Encoding: br bei HTTP-Antworten).

Kompression in der Webentwicklung

Server komprimieren Textinhalte (HTML, CSS, JavaScript, JSON-API-Antworten) praktisch immer vor der Übertragung, da Text sich sehr gut komprimieren lässt (oft 70-80% kleiner) — der Browser dekomprimiert transparent im Hintergrund, ohne dass die Anwendung das merkt. Next.js/Vercel aktivieren das standardmäßig über den Accept-Encoding-Header, den der Browser mitschickt, um zu signalisieren, welche Kompressionsverfahren er versteht. Bereits binär komprimierte Formate wie JPEG-Bilder oder Video profitieren dagegen kaum von zusätzlicher Transport-Kompression, da dort kaum noch Redundanz übrig ist — ein zweites Komprimieren verschwendet nur Rechenzeit ohne nennenswerten Größengewinn.

Siehe auch: Dekomprimieren, ZIP, Archive