Jede Antwort einer Website kostet zweimal: einmal als Bytes durch ein Netz, das jemand anderes bezahlt, und einmal als Rechenarbeit auf einem Gerät, das daraus wieder eine Seite macht. Komprimierung tauscht ein wenig vom Zweiten gegen sehr viel vom Ersten. Auf einer langsamen Verbindung ist dieser Tausch nahezu geschenkt.

Warum überhaupt komprimieren

Das Netz ist mit Abstand der langsamste Teil des Stacks. Ein aktuelles Notebook parst ein Megabyte HTML in wenigen Millisekunden. Dasselbe Megabyte über eine ausgelastete Mobilverbindung dorthin zu bekommen, dauert Sekunden. Jedes Byte, das vor der Übertragung wegfällt, ist zurückgewonnene Zeit, und zwar genau dort, wo die Verzögerung tatsächlich entsteht.

Die Ersparnis ist dabei nicht einmal linear. Eine frische Verbindung bekommt nicht sofort die volle Bandbreite, sondern tastet sich heran. Die ersten Kilobyte einer Antwort reisen deshalb in einem kleineren Übertragungsfenster als alles, was danach kommt. Eine Seite von 181 KB auf 19 KB zu drücken, kann bedeuten, dass sie in spürbar weniger Round-Trips ankommt, und nicht bloß in einem Zehntel der Übertragungszeit. Auf einer Leitung mit hoher Latenz sind Round-Trips die Währung, auf die es ankommt.

Dazu kommt, woraus das Web tatsächlich besteht. HTML, CSS und JavaScript sind Text, und Text ist außerordentlich wiederholungsreich: dieselben Tags, dieselben Klassennamen, dieselben Schlüsselwörter, dieselben Bezeichner, immer wieder. Genau davon lebt ein Kompressor. Text schrumpft routinemäßig auf ein Viertel seiner Ausgangsgröße oder darunter, und das ist ein größerer Gewinn als fast jede andere einzelne Maßnahme.

Der Nutzen wirkt in drei Richtungen gleichzeitig. Besucher sehen früher etwas, besonders auf mobilen und volumenbegrenzten Verbindungen, wo der Unterschied spürbar statt messbar ist. Wer für den ausgehenden Traffic bezahlt, verschickt einen Bruchteil der Bytes, und Bandbreite wird pro Byte abgerechnet. Und das Ganze bleibt unsichtbar: Niemand bemerkt es, kein Anwendungscode nimmt darauf Rücksicht, und im Design muss es niemanden kümmern.

Für eine Performance-Maßnahme ist das ein ungewöhnliches Profil. Die meisten erkaufen ihren Gewinn mit Wartbarkeit, mit dem Aussehen oder mit Entwicklungszeit. Diese hier verlangt ein Häkchen.

Bleibt die Frage, wie sich beide Seiten auf ein Format einigen.

Die Aushandlung, die niemand sieht

Jede Anfrage eines Browsers trägt eine Zeile wie diese:

Accept-Encoding: gzip, deflate, br, zstd

Damit zählt der Browser auf, welche Formate er entpacken kann. Der Server wählt eines davon aus, komprimiert die Antwort und teilt mit, wofür sie sich entschieden hat:

Content-Encoding: zstd

Entpackt wird, bevor irgendetwas anderes die Bytes zu sehen bekommt. Weder die Seite noch das JavaScript noch der Anwendungscode müssen davon wissen. Bietet ein Client nichts Brauchbares an, geht die Antwort unkomprimiert hinaus und funktioniert trotzdem.

Ein Detail am Rande: Brotli und Zstandard bieten die Browser nur über HTTPS an. Über eine unverschlüsselte Verbindung bleibt Gzip übrig.

Darin liegt die stille Eleganz des Entwurfs. Das Web konnte mehrfach um neue Formate erweitert werden, ohne je einen Client unbrauchbar zu machen, der von diesen Formaten nie gehört hatte. Aus demselben Grund wird auch ein viertes Format irgendwann völlig unspektakulär dazukommen.

Die drei Formate

Im Web spielen heute drei Formate eine Rolle, und zwischen ihnen liegt jeweils rund ein Jahrzehnt.

Format	Jahr	Herkunft	Die Idee	Am stärksten bei
Gzip	1990er	GNU-Projekt	Der Klassiker, überall verfügbar	Verlässlichkeit überall
Brotli	2015	Google	Kennt Web-Code von vornherein	Den kleinsten Dateien
Zstandard	2016	Facebook, heute Meta	Auf Größe und Zeit zugleich ausgelegt	Dem schnellsten Entpacken

Brotlis Vorsprung stammt aus einem eingebauten Wörterbuch: rund 13.000 Zeichenketten, die im Web ständig vorkommen, von HTML-Tags über CSS-Eigenschaften bis zu häufigen englischen Wörtern. Gzip muss diese Muster in jeder einzelnen Datei aufs Neue beschreiben, Brotli kennt sie bereits. Deshalb gewinnt es die Größenspalte weiter unten.

Zstandard verfolgt ein anderes Ziel. Statt der kleinstmöglichen Ausgabe hinterherzulaufen, optimiert es die Abwägung selbst: in der jeweils verfügbaren Zeit die kleinste erreichbare Datei erzeugen und am anderen Ende schnell wieder entpacken.

Was sich komprimieren lässt und was nicht

Aus der Redundanz von Text ergibt sich eine klare Trennlinie. Textformate schrumpfen drastisch: HTML, CSS, JavaScript, JSON, XML, SVG. Bereits komprimierte Formate schrumpfen überhaupt nicht.

Bei JPEG, WebP, AVIF, MP4, woff2-Schriften und ZIP-Archiven ist die Redundanz längst herausgerechnet. Sie noch einmal durch Gzip oder zstd zu schicken, kostet auf beiden Seiten Rechenzeit und bringt praktisch nichts. Gelegentlich werden sie dabei sogar minimal größer, weil die Ausgabe weiterhin einen Header braucht und die Entropiecodierung nichts vorfindet, womit sie arbeiten könnte.

Ein Beispiel aus dem Produktivbetrieb: scale.sc läuft auf smoxy. Das sind keine Laborwerte. Jede Zahl steht für die Bytes, die tatsächlich über die Leitung gehen, mit den Einstellungen von smoxy, ermittelt, indem jeweils genau eine Codierung angefordert wurde.

Inhalt	Unkomprimiert	Gzip	Brotli	Zstandard
Startseite (HTML)	180,9 KB	26,2 KB (86%)	18,6 KB (90%)	19,2 KB (89%)
CSS-Bundle	72,9 KB	17,7 KB (76%)	13,5 KB (82%)	13,9 KB (81%)
JavaScript-Bundle	22,9 KB	10,9 KB (52%)	9,5 KB (59%)	9,8 KB (57%)
SVG-Grafik	829 B	488 B (41%)	445 B (46%)	487 B (41%)
JPEG-Bild	70,1 KB	nicht komprimiert	nicht komprimiert	nicht komprimiert
Entpackgeschwindigkeit (separat gemessen)		1,0x	1,3x	1,7x

Die Prozentwerte sind eingesparte Bytes gegenüber der unkomprimierten Antwort. Die letzte Zeile ist die andere Hälfte der Geschichte und der Grund, warum die ersten fünf die Frage nicht allein entscheiden. Sie stammt aus einer separaten Messung, die weiter unten beschrieben wird, und nicht aus diesen Dateien.

Drei Dinge fallen auf. Das Dokument, das der Browser zuerst braucht, bevor er überhaupt etwas darstellen kann, geht von 181 KB auf unter 19 KB zurück. Die SVG-Grafik, die die meisten gedanklich unter "Bild" ablegen, verliert fast die Hälfte ihres Gewichts, weil eine SVG-Grafik in diesem Sinne gar kein Bild ist. Sie ist Text.

Und das JPEG wird nicht komprimiert. Nicht "komprimiert mit wenig Wirkung": Die Antwort kommt ganz ohne Content-Encoding-Header zurück, egal welches Format angeboten wird. Auf beiden Seiten Rechenzeit aufzuwenden, um ein JPEG um nichts zu bewegen, ist kein lohnender Tausch, also findet er nicht statt.

Entschieden wird das anhand des Content-Type. Und zwar genauer, als ein Blick auf die Dateiendung vermuten ließe: Die SVG-Grafik oben wird als image/svg+xml ausgeliefert, ist also formal ein Bild, und wird trotzdem komprimiert. Nicht das Präfix image/ entscheidet, sondern ob der konkrete Typ als komprimierbar geführt wird.

Bilddaten sind deshalb eine ganz eigene Disziplin. Sie schrumpfen über Formatwahl und Qualitätsstufen statt über die Transportcodierung, und dafür ist die Optimierung zuständig.

Auch die Abstände zwischen den drei Formaten lohnen einen genauen Blick. Zstandard liegt bei den größeren Text-Assets rund drei Prozent hinter Brotli. Gzip liefert bei denselben Dateien 15 bis 41 Prozent mehr Bytes als Brotli, und das ist der Preis eines Formats, das entworfen wurde, bevor das Web so aussah wie heute.

Brotli gewinnt also jede Größenzeile, mit einem Abstand von rund drei Prozent. Zstandard entpackt dafür etwa ein Drittel schneller. Welche der beiden Zahlen schwerer wiegt, behandelt der nächste Abschnitt, und es ist nicht die, die in Vergleichstabellen üblicherweise steht.

Der übersehene Teil: das Entpacken

Die Kompressionsrate ist die Zahl, die alle nennen, und sie ist nur die halbe Geschichte. Jede komprimierte Antwort muss wieder entpackt werden, einmal pro Besucher, auf dessen Gerät, bevor die Seite gerendert werden kann.

Auf einem aktuellen Notebook spielt das keine Rolle. Auf einem Android-Gerät der Mittelklasse in einem ausgelasteten Netz sehr wohl. Das Entpacken liegt auf dem kritischen Pfad, denn ein Browser kann kein HTML parsen, das noch verpackt ist. Es kostet Zeit, es kostet Akku, und anders als das Komprimieren zahlt es der Besucher und nicht die Infrastruktur.

Genau darauf ist Zstandard ausgelegt, und deshalb greift die Aushandlung oben zuerst danach.

Das sauber zu messen, erfordert allerdings Sorgfalt. Eine einzelne Datei von 20 KB ist so schnell entpackt, dass vor allem der Overhead rund um den Aufruf gemessen wird und nicht die Arbeit darin; alle drei Formate sehen dann gleich aus. Schickt man stattdessen 67 MB an echten Seiten aus einem fertigen Build hindurch, wiederholt und im Wechsel, damit keines der Formate von einem ruhigen Moment profitiert, trennen sie sich deutlich: Zstandard entpackt rund 1,3-mal so schnell wie Brotli und etwa 1,7-mal so schnell wie Gzip.

Das sind bewusst Verhältnisse und keine absoluten Werte. Der Durchsatz in Megabyte pro Sekunde hängt vom Prozessor, der Implementierung und den Daten ab, und eine auf einem Server gemessene Zahl sagt über ein Mittelklasse-Smartphone wenig aus. Verlässlich ist die Reihenfolge, und sie war in jedem Durchlauf dieselbe.

Damit fällt die Abwägung eindeutig aus. Für Brotli sprechen rund drei Prozent weniger Bytes. Für Zstandard spricht etwa ein Drittel weniger Aufwand beim Entpacken, bei jeder Antwort, auf jedem Gerät, bezahlt aus dem Akku des Besuchers statt aus der Infrastruktur. Drei Prozent von einer 19-KB-Seite sind 600 Byte.

Wie smoxy damit umgeht

Komprimiert wird am Edge, nicht am Origin. smoxy fordert die Antworten vom Origin unkomprimiert an und komprimiert erst auf dem Weg nach draußen. Am Origin ist dafür nichts einzurichten: kein Gzip-Modul zu justieren, keine Build-Pipeline anzupassen, kein Risiko doppelter Komprimierung.

Das hat eine Folge, die bei Komprimierung am Origin nicht auftritt: Der Origin liefert nur eine einzige Fassung einer Antwort, die unkomprimierte. Der Edge muss daraus jeden Besucher bedienen können, den mit Gzip ebenso wie den mit Zstandard, und zwar aus derselben zwischengespeicherten Seite.

Für jede Antwort wird automatisch das beste Format gewählt, das der Browser des Besuchers unterstützt, in dieser Reihenfolge:

Format	Verfügbarkeit	Browser-Unterstützung
Zstandard (zstd)	Schalter, bei neuen Zonen standardmäßig aktiviert	Aktuelle Chrome-, Edge- und Firefox-Versionen
Brotli (br)	Immer aktiv	Alle aktuellen Browser, auch Safari
Gzip	Immer aktiv	Universeller Fallback

Brotli und Gzip sind immer aktiv und lassen sich nicht deaktivieren. Es gibt also keine Konfiguration, in der eine Seite unkomprimiert beim Besucher landet, weil irgendwo etwas abgeschaltet ist. Zstandard ist der eine Schalter, und ein Browser, der davon noch nie gehört hat, handelt einfach Brotli aus, genau wie vorgesehen.

Das betrifft vor allem Safari, das Zstandard bislang nicht unterstützt. Für Besucher auf iPhone und Mac ändert sich damit nichts, denn sie bekommen weiterhin Brotli, also das kleinste der drei Formate.

Neu angelegte Zonen starten ab sofort mit aktiviertem Zstandard. Das ist der bessere Standard: Wer einen Browser mit zstd-Unterstützung nutzt, bekommt bei vergleichbarer Größe schnelleres Entpacken, für alle anderen ändert sich nichts.

Aktivierung für bestehende Zonen

Bestehende Zonen behalten ihre bisherige Einstellung, es hat sich also für niemanden unbemerkt etwas geändert. Zum Aktivieren genügt der Schalter in der Karte Komprimierung auf der Proxy-Seite der Zone. Die Einstellung gilt zonenweit und greift sofort. Kein Cache-Clear, kein Deployment, keine Änderung am Origin.

Details dazu unter Komprimierung.