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: Nutze serverseitige Einstellungen und Werkzeuge, um häufig verwendete Dateitypen zu komprimieren, wo dies angemessen ist. Stelle sicher, dass die Kompression den Energieverbrauch senkt, Ladezeiten minimiert, Bandbreite spart und die Gesamtperformance verbessert. Wende keine zusätzliche Kompression auf Dateien an, die bereits angemessen dimensioniert sind.
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.
Bis vor Kurzem passten bei dieser Guideline Überschrift und Inhalt nicht zusammen. Das erste Kriterium hieß „Serverseitige Kompression“ und beschrieb dann die Vorab-Komprimierung von Medien, also genau das, was das zweite Kriterium ohnehin abdeckt. Das W3C hat das inzwischen korrigiert. Jetzt steht dort, was der Name verspricht: serverseitige Einstellungen und Werkzeuge, häufig verwendete Dateitypen, Ladezeit, Bandbreite, Energieverbrauch. Damit decken die beiden Kriterien endlich zwei verschiedene Dinge ab – das einmalige Komprimieren von Medien vor dem Hochladen und das laufende Komprimieren der Serverantwort bei jeder Anfrage. Wer beide Wege kennt, 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 kommt ein zweiter Punkt, den das neue Kriterium ausdrücklich benennt: Komprimiere nichts, was bereits komprimiert ist. WOFF2, WebP, AVIF, MP3, MP4 und die meisten PDFs bringen ihre Kompression mit. Sie noch einmal durch gzip oder Brotli zu schicken, kostet Rechenzeit auf dem Server und bringt im besten Fall ein paar Promille, im schlechteren wird die Datei sogar geringfügig größer. Ein sauber konfigurierter Filter zählt deshalb die Dateitypen auf, die er komprimiert, statt pauschal alles zu erfassen.
Kompression ist nämlich selbst nicht kostenlos. Brotli auf der höchsten Stufe rechnet deutlich länger als auf einer mittleren, und diese Rechenzeit fällt bei jeder einzelnen Anfrage neu an, solange der Server das Ergebnis nicht zwischenspeichert. Der elegantere Weg für statische Dateien ist deshalb, sie einmal beim Build zu komprimieren und die fertigen Varianten auszuliefern. Dann fällt der teure Teil einmal an statt millionenfach. Das ist derselbe Gedanke, der auch hinter der statischen Seitenerzeugung steht: einmal rechnen statt bei jedem Aufruf.
Damit ergibt sich eine Reihenfolge, die ich für die eigentliche Erkenntnis dieser Guideline halte: erst weglassen, dann optimieren, dann komprimieren. Kompression steht am Ende, nicht am Anfang. Sie räumt auf, was übrig geblieben ist. Und sie ist deshalb so beliebt, weil sie als Einzige nichts von einem verlangt außer einer Konfigurationszeile.
Dein erster Schritt heute
Bevor Du irgendetwas einrichtest, prüfe, ob Deine Kompression überhaupt greift. Das dauert eine halbe Minute.
content-encoding. Steht dort br oder zstd, läuft es. Steht dort gzip, ist noch Luft nach oben. Steht dort gar nichts, hast Du Deinen größten Hebel gefunden. Prüfe die Zeile anschließend auch bei einer CSS- und einer JavaScript-Datei, denn nicht selten ist die Kompression nur für HTML aktiv.Wenn das steht, geh die Liste der komprimierten Dateitypen durch und streiche alles heraus, was ohnehin schon komprimiert ankommt. Das kostet fünf Minuten und spart bei jeder Anfrage ein wenig Rechenzeit, die niemandem gefehlt hätte.
Kompression ist der billigste Hebel im Web, aber sie verkleinert nur, was Du ohnehin sendest. Das erste Kilobyte spart man nicht durch besseres Packen, sondern durch die Entscheidung, es nicht zu senden.
Quelle: W3C-Fassung von Guideline 4.3