Vier von fünf Bytes Deiner Startseite müssen gar nicht durch das Netz. Ein typisches Bündel aus HTML, CSS und JavaScript schrumpft mit Brotli-Kompression auf rund ein Fünftel seiner Größe – aus 100 Kilobyte Text werden gut 20. Das Beste daran: Der Server erledigt das im Moment der Auslieferung, einmal eingerichtet, für jede Anfrage automatisch. Kompression ist damit einer der wenigen Nachhaltigkeitshebel, die sofort wirken, ohne dass Du eine einzige Zeile Deiner Inhalte anfassen musst.
Die zwei Erfolgskriterien von Guideline 4.3 (meine Übersetzung des Originals):
Serverseitige Kompression: Reduziere die Dateigröße vor dem Hochladen von Bildern, Audio und Video durch effiziente Formate und passende Qualitätseinstellungen. Verzichte auf zusätzliche Kompression, wenn die Datei für den Upload bereits angemessen dimensioniert ist.
Medienkompression: Komprimiere Mediendateien wie Bilder, Video und Audio bereits vor dem Hochladen an einen beliebigen Ort, um Speicher- und Übertragungsbedarf zu senken.
Meine Einordnung
Kompression greift an zwei Stellen. Die eine ist die Auslieferung: Textbasierte Dateien – HTML, CSS, JavaScript, SVG, JSON – lassen sich beim Versand durch den Server stark verkleinern. Genau das macht Brotli, und es tut es typischerweise 15 bis 20 Prozent gründlicher als das ältere gzip. Auf datensm.art läuft diese Kompression über einen mod_deflate-Block in der .htaccess, der zstd, Brotli und gzip anbietet – der Browser nimmt, was er versteht.
Die andere Stelle ist das Format selbst, und hier zahlt sich Vorarbeit aus. Ein Bild als WebP ist typischerweise rund 30 Prozent kleiner als ein vergleichbares JPEG, ohne sichtbaren Qualitätsverlust. Bei Schriften spielt WOFF2 dieselbe Rolle: Es ist etwa 30 Prozent kompakter als das ältere WOFF – und braucht keine zusätzliche Serverkompression, weil das Format bereits komprimiert ist. Meine Podcast-Folgen wiederum liefere ich als MP3 aus: verlustbehaftet, aber für gesprochene Sprache in einer Größenordnung, die kein unkomprimiertes Audioformat erreicht.
Wobei ich hier ehrlich sein muss: Der aktuelle W3C-Entwurf formuliert beide Kriterien reichlich medienlastig. Der Name „Serverseitige Kompression" und das mitgelieferte mod_deflate-Beispiel zeigen aber klar, worum es eigentlich geht – um die Kompression der Serverantwort im Moment der Auslieferung. Wer beide Wege kennt, das einmalige Vorab-Komprimieren von Medien und das laufende Komprimieren von Text bei jeder Anfrage, verschenkt keine Bytes.
Und die Größenordnung lohnt den Aufwand: 1 MB weniger pro Seitenaufruf spart bei einer Million Aufrufen rund 400 kg CO₂. In dieser Liga spielt Kompression, sobald eine Seite oft genug abgerufen wird.
Wo ich weiter gehe
Hier setzt mein Vorbehalt an. Kompression verkleinert die Übertragung – nicht die Arbeit danach. Ein auf 800 Kilobyte gepacktes JavaScript-Bündel von 3 Megabyte muss auf dem Gerät des Besuchers trotzdem wieder entpackt, geparst und ausgeführt werden. Der Prozessor sieht die volle Größe, nicht die komprimierte.
Dazu