Jedes Byte, das ein Server ausliefert, muss über die Leitung zum Browser reisen, bevor der erste Inhalt sichtbar wird. Textkompression ist der Hebel, der genau diese Transfergröße verkleinert - und damit direkt auf Time to First Byte und Largest Contentful Paint wirkt. Über Jahre lautete die Antwort schlicht Gzip oder Brotli. Seit 2024 ist mit Zstandard (zstd) ein drittes Verfahren als HTTP-Content-Encoding in den großen Browsern angekommen (Can I use). In der HTTP-Archive-Auswertung werden bereits 37 Prozent der mobilen HTML-Dokumente mit Brotli komprimiert, während 11 Prozent gar keine Kompression senden (HTTP Archive Web Almanac). Dieser Artikel ordnet Gzip, Brotli und zstd sauber ein: welches Verfahren für statische Build-Assets die kleinsten Dateien erzeugt, wo zstd bei dynamischem HTML und JSON-APIs punktet, wie die Content-Encoding-Verhandlung korrekt abläuft und wie sich der reale Bytes-Gewinn messen lässt.
Warum Textkompression über LCP und TTFB entscheidet
HTML, CSS und JavaScript sind Textformate mit hoher Redundanz - wiederkehrende Tags, Klassennamen, Schlüsselwörter und Leerraum. Genau diese Redundanz lässt sich stark komprimieren. Eine typische HTML-Antwort schrumpft mit moderner Kompression auf ein Viertel bis ein Fünftel ihrer Größe, JavaScript-Bundles oft noch stärker. Weniger übertragene Bytes bedeuten weniger Roundtrips im TCP-Slow-Start und eine kürzere Zeit bis das Dokument vollständig empfangen ist. Weil der Browser weitere Ressourcen erst entdecken kann, nachdem das HTML angekommen ist, verschiebt eine kleinere HTML-Antwort die gesamte nachgelagerte Ladekette nach vorne.
Der Zusammenhang zur Nutzererfahrung ist gut belegt. Google beschreibt Time to First Byte als eine der Größen, die den Largest Contentful Paint nach oben begrenzen - ist das HTML spät da, kann auch das größte sichtbare Element nicht früh erscheinen (Google web.dev). Und der wirtschaftliche Effekt ist messbar: Eine Verbesserung der mobilen Ladezeit um nur 0,1 Sekunden steigerte die Conversion-Rate im Einzelhandel um bis zu 8,4 Prozent (Deloitte). Kompression ist damit kein Detail für Puristen, sondern ein Baustein, der über Core Web Vitals und Umsatz mitentscheidet.
Kompression wirkt genau an der latenzkritischen Stelle
Gzip, Brotli und Zstandard im Überblick
Die drei relevanten Verfahren unterscheiden sich weniger im Ziel als im Kompromiss zwischen Kompressionsrate und Rechenaufwand. Gzip ist der älteste und universellste Standard: von jedem Browser und jedem Server unterstützt, schnell, mit soliden Raten. Brotli wurde von Google entwickelt und ist als RFC 7932 standardisiert (IETF RFC 7932); auf hoher Stufe erreicht es bei Text die besten Kompressionsraten der drei. Zstandard stammt ursprünglich von Meta, ist als RFC 8878 standardisiert (IETF RFC 8878) und in der HTTP-Welt seit 2024 als Content-Encoding zstd nutzbar. Sein Markenzeichen ist ein sehr breiter Bereich zwischen sehr schneller und sehr starker Kompression, einstellbar über die Stufe.
Ein Blick auf die Rohgeschwindigkeit macht den Charakter von zstd deutlich. Im Benchmark des Zstandard-Projekts komprimiert zstd auf Standardstufe mit rund 510 MB/s, während die vergleichbare zlib-Gzip-Stufe nur etwa 105 MB/s erreicht - also rund 5-mal schneller bei sogar leicht besserer Rate (Zstandard-Projekt-Benchmark). Wichtig für den Servereinsatz: Die Dekompressionsgeschwindigkeit bleibt bei zstd über alle Stufen nahezu konstant hoch (Zstandard-Projekt-Benchmark), sodass eine höhere Kompressionsstufe den Client nicht ausbremst.
Gzip: der universelle Standard
Von jedem Client verstanden, schnell und ressourcenschonend. Für alte Browser, unverschlüsselte Verbindungen und als Rückfallebene bleibt Gzip die verlässliche Basis jeder Kompressionsstrategie.
Brotli: kleinste Textdateien
Auf Maximalstufe erzeugt Brotli für HTML, CSS und JavaScript die kleinsten Dateien der drei Verfahren (IETF RFC 7932). Der Preis ist eine hohe Kompressionszeit, die sich nur bei einmaligem Vorkomprimieren amortisiert.
Zstandard: schnell und flexibel
zstd deckt mit einer einzigen Bibliothek den Bereich von sehr schnell bis sehr stark ab (IETF RFC 8878). Diese Bandbreite macht es besonders attraktiv für dynamische Antworten, die in Echtzeit komprimiert werden.
Die Marktdaten spiegeln diese Rollen wider. Bei JavaScript hat Brotli Gzip inzwischen überholt und liegt bei rund 45 Prozent der mobilen Auslieferungen gegenüber 41 Prozent für Gzip; zstd taucht mit etwa 1 Prozent erst am Anfang seiner Verbreitung auf (HTTP Archive Web Almanac). Für die Praxis heißt das: zstd ergänzt den Stack, es ersetzt Brotli und Gzip nicht. Wer die drei Verfahren rollenrichtig kombiniert, holt das Maximum heraus - ein Kernthema jeder Server-Optimierung.
Statisch komprimieren: Brotli auf Maximalstufe
Statische Build-Assets - das ausgelieferte JavaScript-Bundle, die CSS-Datei, SVG-Icons - werden im Build-Prozess einmal erzeugt und danach millionenfach unverändert ausgeliefert. Das ist der ideale Fall für teure, aber maximale Kompression. Auf Brotli-Stufe 11 entsteht die kleinste Datei; dass die Kompression dabei Sekunden statt Millisekunden dauert, spielt keine Rolle, weil sie nur ein einziges Mal beim Deployment anfällt. Der Webserver liefert anschließend die vorkomprimierte .br-Datei direkt aus, ohne pro Request neu zu rechnen.
Vorkomprimieren statt on-the-fly
.br- und eine .gz-Variante und lassen Sie den Webserver die passende ausliefern. So bekommen Clients die kleinstmögliche Datei, ohne dass der Server bei jedem Abruf CPU-Zeit für die Kompression aufwendet - ein Standardschritt in unserer Frontend-Optimierung.# Vorkomprimierte Dateien direkt ausliefern (ngx_brotli + gzip_static)
brotli_static on; # liefert vorhandene .br-Datei aus
gzip_static on; # Fallback: vorhandene .gz-Datei
# Nur on-the-fly, wo keine Vorkompression existiert (dynamisch)
brotli on;
brotli_comp_level 5; # moderate Stufe fuer Echtzeit
brotli_types text/html text/css application/javascript application/json image/svg+xml;
# Cache-Varianten pro Encoding sauber trennen
add_header Vary Accept-Encoding always;Für statische Assets ist die Wahl damit klar: Brotli 11 als vorkomprimierte Variante, Gzip 9 als Rückfall für Clients ohne Brotli. zstd bringt hier kaum Vorteile, weil die Kompressionszeit ohnehin keine Rolle spielt und Brotli 11 die etwas kleinere Datei liefert. Der Gewinn steckt in der langen Cache-Lebensdauer: Einmal komprimiert, wird die Datei mit Cache-Control: immutable über Monate ausgeliefert - ein Zusammenspiel, das wir im Detail unter Caching-Strategien mit Varnish und Redis beschreiben.
Dynamisch komprimieren: wo zstd glänzt
Ganz anders liegt der Fall bei dynamischen Antworten. Personalisiertes HTML, JSON-Antworten einer API, servergerendert Seiten mit wechselndem Inhalt - all das entsteht pro Request neu und muss in Echtzeit komprimiert werden, während der Nutzer wartet. Hier zählt nicht die letzte Kompressionsstufe, sondern das Verhältnis aus eingesparten Bytes und aufgewendeter CPU-Zeit. Genau in dieser Disziplin spielt zstd seine Stärke aus: Es erreicht auf mittleren Stufen Raten in der Nähe von Brotli, komprimiert dabei aber deutlich schneller.
Der Größenordnungs-Unterschied ist erheblich. Brotli auf Maximalstufe 11 ist für Echtzeit-Kompression zu langsam; zstd auf einer hohen Stufe komprimiert vergleichbare Inhalte rund 4-mal schneller als Brotli 11, bei nur geringfügig größerer Datei (Zstandard-Projekt-Benchmark). Für eine JSON-API, die tausende Antworten pro Sekunde ausliefert, bedeutet das spürbar weniger CPU-Last pro Request - Rechenzeit, die dem Backend und damit dem Time to First Byte zugutekommt.
- Statische Build-Assets vorab mit Brotli 11 komprimieren, Gzip 9 als Rückfall bereitstellen
- Dynamisches HTML und JSON in Echtzeit komprimieren - zstd auf mittlerer bis hoher Stufe oder Brotli 4 bis 6
- Kompressionsstufe an der CPU-Auslastung ausrichten, nicht an der theoretischen Maximalrate
- Bereits komprimierte Formate (JPEG, WebP, AVIF, ZIP, WOFF2) von der Kompression ausnehmen
- Sehr kleine Antworten unter etwa einem Kilobyte ungefiltert lassen - der Overhead lohnt nicht
- Encoding-Auswahl und Kompressionsstufe nach Deployment mit echten Antworten gegenprüfen
Komprimiertes nicht erneut komprimieren
Brotli und Zstandard im direkten Vergleich
Die folgende Gegenüberstellung fasst zusammen, wann welches Verfahren die bessere Wahl ist. Entscheidend ist die Trennung zwischen einmal erzeugten statischen Dateien und pro Request neu berechneten dynamischen Antworten - nicht die Frage, welcher Algorithmus pauschal der beste ist.
| Kriterium | Brotli (Stufe 11) | Zstandard (mittel bis hoch) |
|---|---|---|
| Kompressionsrate bei Text | höchste der drei Verfahren | nahe an Brotli, minimal größer |
| Kompressionsgeschwindigkeit | niedrig, Sekunden pro MB | hoch, rund 4x schneller als Brotli 11 |
| Dekompression | schnell | schnell und stufenunabhängig |
| Idealer Einsatz | statische Build-Assets | dynamisches HTML und JSON |
| Standardisiert als | IETF RFC 7932 | IETF RFC 8878 |
| Browser-Content-Encoding | nahezu flächendeckend | ab Chrome und Edge 123, Firefox 126, Safari 26 |
Die Zeile zur Browserunterstützung ist der Grund, warum zstd eine Ergänzung und kein Ersatz ist. Als HTTP-Content-Encoding wird zstd von Chrome und Edge ab Version 123, von Firefox ab 126 und von Safari ab 26 verstanden (Can I use). Aeltere Clients kennen es nicht und würden eine zstd-Antwort nicht dekomprimieren können - weshalb der Server bei ihnen sauber auf Brotli oder Gzip zurückfallen muss. Ein weiteres Detail: Die Browser senden Accept-Encoding: zstd ausschließlich über HTTPS, nicht über unverschlüsseltes HTTP (MDN Web Docs).
Content-Encoding sauber verhandeln
Welches Verfahren zum Einsatz kommt, entscheidet nicht der Server allein, sondern eine Aushandlung zwischen Client und Server. Der Browser teilt in jedem Request über den Accept-Encoding-Header mit, welche Verfahren er versteht - etwa zstd, br, gzip. Der Server wählt daraus die beste gemeinsame Methode, komprimiert die Antwort entsprechend und signalisiert die tatsächlich verwendete Kodierung im Content-Encoding-Header der Antwort (MDN Web Docs). Versteht der Client keines der bevorzugten Verfahren, fällt die Kette auf Gzip und im äußersten Fall auf unkomprimierte Auslieferung zurück.
# Request des Browsers (moderne Version, ueber HTTPS)
GET /api/produkte HTTP/2
Accept-Encoding: zstd, br, gzip
# Antwort des Servers - zstd gewaehlt
HTTP/2 200 OK
Content-Type: application/json
Content-Encoding: zstd
Vary: Accept-EncodingVary: Accept-Encoding nicht vergessen
Vary: Accept-Encoding senden. Dieser Header weist Caches an, pro Encoding eine eigene Variante vorzuhalten. Fehlt er, drohen defekte Antworten für einen Teil der Besucher - ein Klassiker unter den Konfigurationsfehlern, den wir in der technischen Analyse gezielt prüfen.Die Fallback-Kette richtig aufbauen
Eine robuste Kompressionsstrategie 2026 ist eine gestaffelte Kette, keine Einzelentscheidung. Sie beginnt beim stärksten Verfahren, das der Client versteht, und fällt geordnet zurück, wenn eine Voraussetzung fehlt. So bekommt jeder Besucher die kleinstmögliche Antwort, die sein Browser verarbeiten kann, ohne dass irgendein Client von der Auslieferung ausgeschlossen wird.
- Statische Assets: vorkomprimiertes Brotli 11, sonst vorkomprimiertes Gzip 9
- Dynamische Antworten an moderne Clients über HTTPS: zstd auf mittlerer bis hoher Stufe
- Dynamische Antworten an Clients mit Brotli, aber ohne zstd: Brotli auf Stufe 4 bis 6
- Clients ohne Brotli und zstd sowie unverschlüsselte Verbindungen: Gzip
- Sehr alte oder exotische Clients ohne jede Kompression: unkomprimierte Auslieferung
Der Charme dieser Kette liegt im asymmetrischen Nutzen-Risiko-Verhältnis: Moderne Browser bekommen den vollen Geschwindigkeitsvorteil, ältere verlieren nichts, weil der Fallback verlustfrei greift. Diese Denkweise - modernste Technik nutzen, ohne jemanden auszuschließen - zieht sich durch die gesamte Performance-Arbeit, vom Protokoll bis zur Ressourcenpriorisierung. Wie sich ein ähnliches Prinzip beim Verbindungsaufbau auszahlt, zeigt der Beitrag zu HTTP/3 und QUIC.
Den realen Bytes-Gewinn messen
Kompression ist eine Optimierung, die man nicht schätzen, sondern messen sollte. Der wichtigste Wert ist die tatsächlich übertragene Größe pro Antwort - in den Entwicklerwerkzeugen des Browsers als transferierte Größe gegenüber der dekodierten Größe sichtbar. Das Verhältnis der beiden zeigt unmittelbar, wie stark eine Antwort komprimiert wurde und ob überhaupt komprimiert wird. Der Content-Encoding-Header verrät zusätzlich, welches Verfahren der Server tatsächlich gewählt hat.
Für eine belastbare Bewertung reicht der Einzelblick nicht. Man vergleicht die Verfahren an denselben repräsentativen Dokumenten - der größten HTML-Antwort, dem Haupt-JavaScript-Bundle, den umfangreichsten JSON-Antworten der API. Erst dieser Vergleich zeigt, ob der Wechsel von Gzip auf Brotli oder die Einführung von zstd für dynamische Antworten den erwarteten Gewinn bringt und wie er sich auf CPU-Last und Time to First Byte auswirkt. In der Praxis lohnt sich die Umstellung dort am stärksten, wo große Textantworten auf viele Nutzer treffen (Projekterfahrung).
Nicht die theoretische Maximalrate entscheidet, sondern die kleinste Antwort, die der jeweilige Client verlustfrei verarbeiten kann - gemessen an echten Dokumenten, nicht an synthetischen Testdateien.
Der optimale Kompressions-Stack 2026
Der beste Kompressions-Stack 2026 ist kein Entweder-oder, sondern eine bewusste Arbeitsteilung. Brotli auf Maximalstufe liefert die kleinsten statischen Dateien und gehört an den Build-Prozess. zstd komprimiert dynamisches HTML und JSON schnell und ressourcenschonend und entlastet damit den Server unter Last. Gzip bleibt die universelle Rückfallebene, die niemanden außen vor lässt. Über allem steht eine korrekte Aushandlung mit sauberem Vary-Header, damit Caches und CDNs die Varianten nicht vermischen.
Kompression ist dabei ein Baustein, kein Allheilmittel. Sie verkleinert die Transfergröße, ändert aber nichts an einer langsamen Datenbank, einem überladenen Frontend oder einem aufgeblähten DOM. Ihr voller Wert entsteht erst im Zusammenspiel mit schnellem Backend, sinnvollem Caching und schlankem Markup - etwa der Reduktion der DOM-Größe und einem gut genutzten Back-Forward-Cache. In unseren Performance-Projekten richten wir den Kompressions-Stack als Teil der Server-Optimierung ein: Brotli für Assets, effizientes zstd oder Gzip für dynamische Antworten - ohne die Serverlast hochzutreiben und mit belegtem Bytes-Gewinn.
Quellen und Studien