Brotli vs. Zstandard (Zstd): Kompressionsverfahren im Praxisvergleich

, function() oder häufige englische Wörter bereits vor der eigentlichen Kompression bekannt sind und nicht erst aus dem zu komprimierenden Dokument selbst gelernt werden müssen.

Zstandard verfolgt einen ähnlichen algorithmischen Grundansatz aus Entropiekodierung und Wörterbuchsuche, wurde aber von Grund auf auf Geschwindigkeit und eine sehr breite Skala an Kompressionsstufen (1 bis 22) hin optimiert. Zstd bringt kein festes, webspezifisches Standardwörterbuch mit, unterstützt aber das Training eigener, projektspezifischer Wörterbücher, was insbesondere bei vielen kleinen, strukturell ähnlichen Antworten wie JSON-API-Responses einen echten Vorteil bringen kann, den ein generisches Wörterbuch nicht bietet.

3. Kompressionsrate im Vergleich: HTML, CSS, JavaScript und JSON

Bei hohen Kompressionsstufen liefert Brotli für klassische Webinhalte wie HTML- und CSS-Dateien in den meisten Benchmarks eine minimal bessere Kompressionsrate als Zstd auf vergleichbarem Geschwindigkeitsniveau, was vor allem auf das eingebaute Webwörterbuch zurückzuführen ist. Bei Brotli-Qualitätsstufe 11, der höchsten verfügbaren Stufe, lassen sich für typische HTML-Dokumente Kompressionsraten erzielen, die Gzip auf höchster Stufe um 15 bis 20 Prozent unterbieten, während Zstd auf seiner höchsten Stufe 22 in etwa gleichauf mit Brotli liegt, teils sogar knapp dahinter.

Der Unterschied wird bei sehr großen, hochgradig repetitiven Dateien kleiner, weil beide Verfahren dann genug eigenen Kontext im Dokument selbst finden, um unabhängig vom mitgelieferten Wörterbuch gute Ergebnisse zu erzielen. Bei kleinen Antworten, etwa kurzen API-Responses unter zehn Kilobyte, kann ein mit Zstd trainiertes, projektspezifisches Wörterbuch Brotli in der Kompressionsrate sogar übertreffen, weil es exakt auf das tatsächliche Antwortformat zugeschnitten ist und nicht auf generische Webinhalte.

4. Encoding- und Decoding-Geschwindigkeit im Vergleich

Der deutlichste Unterschied zwischen beiden Verfahren zeigt sich nicht in der Kompressionsrate, sondern in der Geschwindigkeit. Brotli auf Qualitätsstufe 11 ist rechenintensiv und für die dynamische Kompression bei jedem Request ungeeignet, weil die Kompressionszeit für größere Dateien mehrere hundert Millisekunden betragen kann. Zstd erreicht selbst auf hohen Kompressionsstufen deutlich kürzere Kodierzeiten und bietet mit seinen niedrigeren Stufen einen Bereich, in dem sich brauchbare Kompressionsraten mit einem Bruchteil der CPU-Kosten von Brotli erzielen lassen.

Bei der Dekompression, die im Browser stattfindet und für die gefühlte Ladezeit relevant ist, liegt Zstd konstruktionsbedingt vorn, weil Geschwindigkeit beim Dekomprimieren von Anfang an ein Kernziel des Formats war. Für statische Assets, die einmalig beim Build vorkomprimiert und danach nur noch ausgeliefert werden, spielt die Encoding-Geschwindigkeit praktisch keine Rolle, weshalb sich in diesem Fall die höchste Brotli-Qualitätsstufe fast immer lohnt. Für dynamisch generierte Inhalte, die bei jedem Request neu komprimiert werden müssen, ist Zstd mit einer mittleren Kompressionsstufe häufig die praktikablere Wahl.

5. Aktueller Browser-Support-Stand für Zstd Content-Encoding

Brotli wird seit Jahren von allen relevanten Browsern über HTTPS-Verbindungen unterstützt und kann in produktiven Setups bedenkenlos eingesetzt werden, ohne dass ein Fallback-Mechanismus mehr als eine Formsache wäre. Bei Zstandard als HTTP-Content-Encoding sieht die Lage differenzierter aus: Chromium-basierte Browser wie Chrome und Edge unterstützen das zstd-Content-Encoding seit Version 123, Firefox zog mit Version 126 nach, sodass der Support bei den beiden meistgenutzten Browser-Engines inzwischen als produktionsreif gelten kann.

Safari hinkt bei der nativen Unterstützung von Zstd als Content-Encoding nach wie vor hinterher, weshalb sich der Rollout in der Praxis nicht pauschal aktivieren lässt, sondern über die vom Client gesendete Accept-Encoding-Kopfzeile ausgehandelt werden muss. Ein Server, der Zstd anbietet, muss deshalb weiterhin zwingend auch Brotli und Gzip als Fallback vorhalten, damit Clients ohne Zstd-Unterstützung nicht mit einer nicht dekodierbaren Antwort scheitern. Dieser Zustand dürfte sich in den kommenden Versionen weiter verbessern, ist aber aktuell ein wichtiger Grund, warum ein reiner Zstd-Betrieb ohne Brotli-Fallback noch nicht empfehlenswert ist.

6. Nginx-Konfiguration für Brotli

Brotli ist nicht Teil des Nginx-Kerns und muss über das dynamische Modul ngx_brotli nachgerüstet werden, entweder durch eigenes Kompilieren mit dem entsprechenden Modul-Flag oder über ein vorgefertigtes Nginx-Image, das das Modul bereits mitbringt. Für statische Assets, die bereits beim Build als .br-Datei vorkomprimiert wurden, aktiviert brotli_static die direkte Auslieferung der vorkomprimierten Datei, ohne dass der Server zur Laufzeit selbst komprimieren muss, was CPU-Last spart und die Antwortzeit verkürzt.

Für dynamisch generierte Inhalte, bei denen keine vorkomprimierte Datei existiert, übernimmt die dynamische Brotli-Kompression im laufenden Betrieb, allerdings mit einer niedrigeren Qualitätsstufe als beim Build, um die CPU-Last auf dem Server in Grenzen zu halten. Die folgende Konfiguration zeigt beide Fälle kombiniert, mit vorkomprimierten statischen Dateien und einer moderaten Kompressionsstufe für dynamische Antworten.

http {
    # Vorkomprimierte .br Dateien direkt ausliefern, wenn vorhanden
    brotli_static on;

    # Dynamische Kompression für nicht vorkomprimierte Antworten
    brotli on;
    brotli_comp_level 5;
    brotli_min_length 512;
    brotli_types
        text/plain
        text/css
        text/xml
        application/json
        application/javascript
        application/xml+rss
        image/svg+xml;
}

7. Nginx-Konfiguration für Zstd und parallele Unterstützung beider Verfahren

Zstandard-Unterstützung in Nginx erfordert ebenfalls ein zusätzliches Modul, etwa ngx_http_zstd_module, das analog zu ngx_brotli sowohl statische Auslieferung vorkomprimierter .zst-Dateien als auch dynamische Kompression zur Laufzeit anbietet. Damit Clients je nach Fähigkeit das jeweils passende Verfahren erhalten, wertet Nginx die vom Client gesendete Accept-Encoding-Kopfzeile aus und wählt automatisch das beste unterstützte Format in der Reihenfolge Zstd, dann Brotli, dann Gzip, sofern alle drei Module gleichzeitig aktiv sind.

Wichtig ist dabei, dass für jedes unterstützte Format sowohl eine vorkomprimierte Variante als auch ein dynamischer Fallback konfiguriert werden, damit kein Client leer ausgeht. Bei statischen Assets bedeutet das im Build-Prozess, dass für jede Datei sowohl eine .br- als auch eine .zst-Variante erzeugt wird, was den Build zwar etwas verlängert, aber zur Laufzeit keinerlei zusätzliche CPU-Kosten verursacht, weil Nginx nur noch die passende Datei ausliefert.

http {
    # Zstd vorkomprimierte Dateien und dynamische Kompression
    zstd_static on;
    zstd on;
    zstd_comp_level 12;
    zstd_min_length 512;
    zstd_types
        text/plain
        text/css
        application/json
        application/javascript
        image/svg+xml;

    # Reihenfolge der Aushandlung: zstd vor brotli vor gzip
    # wird über die Accept-Encoding Kopfzeile des Clients bestimmt
}

8. Wann sich der Wechsel oder die parallele Unterstützung lohnt

Für die meisten Webshops und Content-Seiten ist ein vollständiger Wechsel von Brotli zu Zstd derzeit nicht sinnvoll, weil Brotli bei statischen Assets weiterhin die bessere Kompressionsrate liefert und von allen relevanten Browsern zuverlässig unterstützt wird. Sinnvoll ist stattdessen ein paralleler Betrieb: Brotli auf höchster Qualitätsstufe für vorkomprimierte statische Assets wie CSS- und JavaScript-Bundles, und Zstd für Fälle, in denen Geschwindigkeit bei der Kompression tatsächlich zählt, etwa bei dynamisch generierten API-Antworten mit hohem Anfragevolumen.

Besonders lohnend wird Zstd, sobald Server unter hoher CPU-Last stehen und dynamische Inhalte bei jedem Request neu komprimiert werden müssen, weil die geringeren Kodierzeiten hier direkt die Serverkapazität schonen. Für ein Projekt mit überwiegend statischen, gut cachebaren Assets bleibt Brotli mit vorkomprimierten Dateien die einfachere und effizientere Lösung, während eine parallele Zstd-Unterstützung vor allem dort Sinn ergibt, wo Clients sie bereits nutzen können und die Serverlast tatsächlich ein Thema ist.

9. Entscheidungshilfe im direkten Vergleich

Die folgende Tabelle fasst die zentralen Unterschiede zwischen Brotli und Zstd zusammen, um im konkreten Projekt schneller abschätzen zu können, welches Verfahren für welchen Anwendungsfall die bessere Wahl ist.

10. Zusammenfassung

11. FAQ: Brotli vs. Zstd: Das Wichtigste auf einen Blick