Brotli vs. Gzip: Welchen sollte Ihr Server verwenden?
Beide schrumpfen Ihren Text, bevor er auf den Draht trifft, und beide sind im Grunde freie Geschwindigkeit. Der ehrliche Vergleich - der härter komprimiert, was schneller ist, und warum die Antwort hängt davon ab, ob die Datei zwischenspeicherbar ist.
Die kurze Antwort, damit Sie aufhören können zu lesen, wenn das alles ist, was Sie brauchen: bieten beide, und lassen Sie den Browser wählen. Dient statischen Dateien Brotli-komprimiert in einer hohen Einstellung und Cache das Ergebnis; bieten dynamische Antworten mit Gzip oder Low-Level-Brotli. Jeder Browser in den letzten zehn Jahren veröffentlicht unterstützt beide, so gibt es keine Kompatibilität Grund zu wählen.
Die längere Antwort ist interessanter, denn "Brotli ist neuer, also verwenden Sie Brotli" ist genau die Art von Ratschlägen, die einen beschäftigten API-Server 20% langsamer macht.
Was Kompression macht
Text ist wild repetitiv. HTML, CSS, JavaScript und JSON wiederholen die gleichen Tags, Klassennamen, Keywords und Whitespace-Muster tausende Male in einer Datei. Sowohl Gzip als auch Brotli finden diese Wiederholungen und kodieren sie kompakt, so dass eine 200 KB-Datei als 40-etwas KB reist und der Browser sie bei der Ankunft neu baut. Weniger Daten auf dem Draht bedeuten schnellere Lasten, und der Effekt ist genau dort am größten, wo es am wichtigsten ist – mobile Verbindungen.
Kompression hilft nur Text. JPEG, PNG, WebP, MP4 und WOFF2 sind bereits komprimiert – Gzip über sie läuft, brennt CPU für einen Bruchteil von einem Prozent, und kann die Datei gelegentlich größer machen. Komprimieren Sie Text; optimieren Sie Medien separat.
Der Vergleich
| Gzip | Brotli | |
|---|---|---|
| Freigegeben | 1992 | 2015 |
| Kompressionsstufen | 1–9 | 0–11 |
| Typische Texteinsparungen | ~70% | ~75–80% |
| Eingebautes Wörterbuch | Nein | Ja — häufige Web-Strings |
| Geschwindigkeit bei maximaler Einstellung | Schnell | Viel langsamer |
| Geschwindigkeit bei niedrigen Einstellungen | Schnell | Vergleichbar |
| Browser-Unterstützung | Allgemein | Stellvertretender Minister für allgemeine Angelegenheiten (seit ~2016) |
| Funktioniert über einfache HTTP | Nein | HTTPS nur in der Praxis |
Brotli's Kante stammt zum Teil aus einem besseren Algorithmus und zum Teil aus etwas Klugem: er schifft mit einem eingebauten Wörterbuch von etwa 13.000 gängigen Web-Strings — Dinge wie </div>, function, charset=utf-8. Diese kosten fast nichts zu kodieren, weil beide Seiten sie bereits haben. Deshalb ist Brotlis Vorteil am größten auf kleinen Dateien, wo Gzip noch nicht die Chance hatte, ein eigenes Wörterbuch aus dem Inhalt aufzubauen.
Warum die neuere nicht immer die richtige ist
Hier ist der Teil, der Ihre Konfiguration entscheidet. Brotli auf Ebene 11 ist dramatisch langsamer zu komprimieren als Gzip — oft eine Größenordnung oder mehr. Die Dekompression ist so oder so schnell, es ist die Kompressionsseite, die kostet.
Ob das zählt, hängt ganz davon ab, wie oft die komprimierte Ausgabe verwendet wird.
Für eine statische, zwischenspeicherbare Datei — Ihr CSS-Bundle, Ihre App JavaScript, eine fontfreie HTML-Seite, die sich selten ändert — Sie komprimieren einmal und dienen der gleichen komprimierten Kopie Tausende oder Millionen Mal. Die langsame Komprimierung geschieht einmalig, bei Bau oder auf erste Anfrage, und kein Besucher wartet je darauf. Verwenden Sie Brotli 11. Es gibt keinen Nachteil.
Für eine Antwort, die pro Anfrage generiert wird — ein personalisiertes Dashboard, ein API-Endpunkt, eine Seite mit den Suchergebnissen — keine Wiederverwendung. Jede Reaktion wird frisch komprimiert, und Brotli 11 würde jedem einzelnen messbare Latenz und CPU hinzufügen. Hier wollen Sie Gzip auf mittlerem Niveau, oder Brotli auf 4 oder 5, was ungefähr Gzip-Geschwindigkeit ist, während noch etwas besser komprimiert.
Der klassische Fehler ist es, Brotli auf seinem Standard-Maximum auf einem dynamischen App-Server zu aktivieren und sich dann zu fragen, warum die Reaktionszeiten unter Last schlechter wurden. 11 für Zwischenspeicher, 4–5 für On-the-fly.
Überprüfen, was Sie tatsächlich dienen
Konfiguration und Realität treiben überraschend oft auseinander – ein Proxy stript den Header, eine Regel passt nur zu einigen Inhaltstypen, jemand schaltete ihn während eines Vorfalls im Jahr 2023 aus. Ein Befehl sagt Ihnen die Wahrheit:
curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/app.css | grep -i content-encodingWenn nichts zurückkommt, versenden Sie unkomprimierten Text. Versuchen Sie es gegen Ihr HTML, Ihr Haupt-Stylesheet und Ihr größtes JavaScript-Bundle – es ist üblich, dass eines der drei verpasst wurde.
Wo zstd passt
Ein dritter Name taucht in diesem Gespräch auf: zstd, oder Zstandard. Chrome und Firefox beide unterstützen es als Content-Kodierung jetzt, und es lohnt sich zu wissen, was es ist, weil die Rahmung ist anders als Brotli.
Brotli's Pitch ist "kleiner als Gzip". Zstds Pitch ist "viel schneller als Brotli bei ähnlichen Verhältnissen". Bei den Low-to-Middle-Einstellungen, die Sie für dynamische Reaktionen verwenden würden, komprimiert zstd wesentlich schneller als jeder andere für ungefähr die gleiche Ausgabegröße, was es interessant macht, genau dort, wo Brotli 11 ist, schlechte Idee — per-Request-Inhalte erzeugt auf der Flucht.
Für statische zwischenspeicherbare Dateien gewinnt Brotli 11 immer noch in der Regel an Größe, und da Kompressionszeit dort keine Rolle spielt, bleibt es die richtige Wahl. So ändert sich die Form der Antwort nicht wirklich; zstd ist eine bessere Option für die dynamische Hälfte als Gzip ist, auf Clients, die es unterstützen.
Die Unterstützung ist gut, aber nicht universell, und Safari ist langsamer zu adoptieren, als die anderen. Das ist in Ordnung – Content-Verhandlung bedeutet, dass Sie es anbieten und Kunden, die es nicht verstehen, einfach erhalten Brotli oder Gzip statt. Es ist additiv, keine Migration.
Du musst dich eigentlich nicht entscheiden
Browser werben, was sie auf jeder Anfrage über die unterstützen Accept-Encoding header. Ein CDN liest das und dient der besten Option, mit der der Client umgehen kann — Brotli, wo verfügbar, Gzip als Fallback — und zwischenspeichert beide Varianten getrennt, durch Kodierung geschlüsselt. Sie aktivieren es einmal und das Richtige passiert pro Besucher, für immer.
Das ist wirklich die Antwort auf die Frage im Titel. "Brotli vs Gzip" Frames es als eine Entscheidung, und es ist nicht seit Jahren eine. Die Entscheidung, die es wert ist, ist die Kompression Höhe, und das hängt davon ab, ob die Sache, die Sie komprimieren wiederverwendet werden.
Schnelle Antworten
Ist Brotli besser als Gzip?
Brotli komprimiert Text etwa 15 bis 20 Prozent kleiner als Gzip, so dass für Dateien, die Sie einmal komprimieren und dienen viele Male ist es deutlich besser. Für Antworten, die auf jeder Anfrage frisch generiert werden, ist Brotli in seiner höchsten Einstellung weit langsamer als Gzip und wird Latenz unter Last hinzufügen. Die richtige Antwort ist, beides anzubieten und die Komprimierungsebene dadurch zu variieren, ob der Inhalt zwischengespeichert werden kann.
Welchen Brotli Kompressionsgrad sollte ich verwenden?
Verwenden Sie Level 11 für statische zwischenspeicherbare Assets wie CSS und JavaScript Bundles, wo die langsame Komprimierung einmal passiert und das Ergebnis wiederverwendet wird. Verwenden Sie Level 4 oder 5 für dynamische pro-Request-Antworten, die etwa Gzip Geschwindigkeit ist, während noch etwas besser komprimieren. Level 11 auf dynamische Inhalte ist die häufigste Fehlkonfiguration und es erhöht messbar Reaktionszeiten.
Unterstützen alle Browser Brotli?
Ja, jeder aktuelle Browser hat Brotli seit etwa 2016 unterstützt, einschließlich Chrome, Firefox, Safari und Edge. Browser werben Unterstützung in der Accept-Encoding Request Header, so dass ein Server oder CDN kann Brotli zu Clients, die es akzeptieren und fallen zurück zu Gzip für alles, was nicht. Es gibt keinen Grund zur Kompatibilität, es zu vermeiden.
Soll ich Bilder mit Gzip oder Brotli komprimieren?
Nein. JPEG-, PNG-, WebP-, AVIF-, MP4- und WOFF2-Dateien sind bereits komprimiert, so dass Gzip oder Brotli über sie laufen, CPU für eine vernachlässigbare Speicherung verbraucht und die Datei gelegentlich etwas größer macht. Komprimieren Sie Textformate wie HTML, CSS, JavaScript, JSON und SVG und verarbeiten Sie Bilder separat durch Formatkonvertierung und Größenänderung.
Bieten Sie beide Kodierungen an. Komprimieren Sie zwischenspeicherbare statische Dateien hart mit Brotli 11 und lassen Sie sie wiederverwendet werden; komprimieren Sie pro-Anfrage Antworten leicht mit Gzip oder Brotli 4–5. Komprimieren Sie niemals Bilder oder Videos. Führen Sie dann einen Curl-Befehl aus, um zu bestätigen, was Sie konfiguriert haben, was Sie tatsächlich dienen.
Sehen Sie, wie NordicCDN dies für Ihre Website tut:
Mads hat seit seinem 16. Lebensjahr in der IT gearbeitet — hauptsächlich als Hosting. Er beteiligte sich früh an einer SaaS-Firma und half, sie bis zur Übernahme durch Visma weiterzuentwickeln, hat Data-Center-Netzwerke aufgebaut und betrieben und diente als CTO eines dänischen Rechenzentrums. Er hat NordicCDN gestartet, um eine schnelle, sichere Infrastruktur einfach zu bedienen.
