gzip vs. Brotli: Was der Unterschied wirklich wert ist, und warum ein Drittel der öffentlichen Websites gar nichts komprimiert

  • vuetelemetry
  • Leitfäden
  • 7 Min. Lesezeit

Brotli komprimiert Text besser als gzip, mit einem echten, aber kleineren Abstand, als das Marketing nahelegt. Der wichtigere Befund liegt woanders: Von 336 gemessenen öffentlichen Stellen senden 107 der antwortenden ihre Startseite ganz ohne Kompression.

Der Vergleich wird meist als Wahl dargestellt, und für eine neue Installation ist er das. Für die meisten bestehenden Websites nicht, denn die eigentliche Frage ist, ob überhaupt etwas komprimiert wird.

Was wir gemessen haben, und was es kostet

Ein gelb-schwarzer industrieller Backenbrecher von unten in einer Fabrikhalle fotografiert, seine schwere Stahlbacke und sein Antriebsrad beherrschen das Bild.
Ein gelb-schwarzer industrieller Backenbrecher von unten in einer Fabrikhalle fotografiert, seine schwere Stahlbacke und sein Antriebsrad beherrschen das Bild.

Wir haben am 6. September 2026 336 portugiesische öffentliche Stellen gemessen, je eine Anfrage, und dabei nur die Antwort-Header und die übertragene Größe des HTML gelesen. 291 antworteten. 107 davon, 36,8 %, lieferten ihre Startseite ganz ohne Content-Encoding aus.

Die Kosten sind nicht theoretisch. Bei den Websites, die komprimieren, wiegt die mittlere Startseite 29 312 übertragene Bytes. Bei denen, die es nicht tun, liegt der Median bei 109 705 Bytes. Das sind 3,7-mal so viele Daten für dieselbe Art von Seite, und achtzehn der unkomprimierten Websites überschreiten allein mit ihrem HTML 200 kB, die schwerste mit 536 245 Bytes.

Der eigentliche Vergleich

Nun zum eigentlichen Vergleich. gzip wird seit den 1990er-Jahren überall unterstützt und ist der sichere Standard. Brotli, 2016 standardisiert, wird von allen aktuellen Browsern über HTTPS unterstützt und liefert bei Text meist kleinere Ergebnisse, wobei der Gewinn auf HTML, CSS und JavaScript entfällt und nicht auf bereits komprimierte Formate.

  • curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding
  • Keine content-encoding-Zeile: Es wird nichts komprimiert
  • content-encoding: br heißt, Brotli wurde ausgehandelt, gzip heißt Rückfall
  • Über HTTPS testen: Browser bieten Brotli über einfaches HTTP nicht an
  • Kompression auf Texttypen beschränken; Bilder und Videos gewinnen nichts

Ehrlich formuliert gewinnt Brotli bei Text, und der Abstand hängt vom Inhalt und von der gewählten Kompressionsstufe ab. Wer Ihnen einen einzigen universellen Prozentwert nennt, zitiert einen Benchmark, nicht Ihre Website. Messen Sie Ihre eigene: Es braucht eine Anfrage.

Die Stufen zählen mehr als der Algorithmus

Die Stufe ist wichtiger als die Wahl des Algorithmus, und dort liegen die meisten Fehlkonfigurationen. Brotli bietet die Stufen 0 bis 11. Stufe 11 ist so langsam, dass sie bei dynamisch erzeugten Antworten mehr Serverzeit kosten kann, als sie bei der Übertragung spart. Üblich ist eine hohe Stufe für statische Dateien, die einmal beim Build komprimiert werden, und eine mittlere Stufe für alles, was pro Anfrage erzeugt wird.

gzip hat dieselbe Struktur mit den Stufen 1 bis 9 und dieselbe Falle: Die höchste Stufe ist für dynamische Inhalte selten die richtige.

Aushandlung, HTTPS, und was man nicht komprimiert

Die Inhaltsaushandlung entscheidet, welches Verfahren verwendet wird, und das liegt nicht allein bei Ihnen. Der Browser sendet `Accept-Encoding: gzip, deflate, br`, und der Server wählt. Beide zu konfigurieren heißt, dass moderne Clients Brotli bekommen und alles andere auf gzip zurückfällt, deshalb ist es keine Entweder-oder-Entscheidung.

Ein praktisches Detail, das oft verwirrt: Browser bieten Brotli nur über HTTPS an. Eine Website, die über einfaches HTTP getestet wird, scheint Brotli nicht zu unterstützen, obwohl sie es tut.

Bereits komprimierte Formate zu komprimieren ist verschwendete Arbeit. JPEG, PNG, WebP, MP4 und die meisten Schriftformate gewinnen nichts und kosten CPU. Beschränken Sie die Kompression auf Text-MIME-Typen, was in den meisten vernünftigen Konfigurationen der Standard ist und in den anderen das Erste, was man prüfen sollte.

**Bereits komprimierte Formate zu komprimieren ist verschwendete Arbeit.** JPEG, PNG, WebP, MP4 und die meisten Schriftformate gewinnen nichts und kosten CPU. Beschränken Sie die Kompression auf Text-MIME-Typen, was in den meisten vernünftigen Konfigurationen der Standard ist und in den anderen das Erste, was man prüfen sollte.

- vuetelemetry

Prüfen Sie Ihre Seite mit einer Anfrage

Ihre eigene Website zu prüfen, braucht einen Befehl, und es ist derselbe, den wir 336-mal ausgeführt haben:

FAQ

Ist Brotli immer besser als gzip?

Bei Text liefert Brotli bei vergleichbaren Einstellungen meist ein kleineres Ergebnis als gzip, und der Abstand hängt vom Inhalt und der gewählten Stufe ab. Bei bereits komprimierten Formaten wie JPEG oder MP4 ist es nicht besser, dort hilft keines der beiden Verfahren. Beide zu konfigurieren ist die normale Antwort, da der Browser aushandelt, welches er bekommt.

Wie prüfe ich, ob meine Website überhaupt etwas komprimiert?

Senden Sie eine Anfrage mit einem Accept-Encoding-Header und lesen Sie die Antwort: curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding. Kommt keine content-encoding-Zeile zurück, wird nichts komprimiert.

Warum nutzt meine Website kein Brotli, obwohl der Server es unterstützt?

Der häufigste Grund ist, dass Sie über einfaches HTTP getestet haben. Browser kündigen Brotli nur über HTTPS an, deshalb lässt ein HTTP-Test einen korrekt konfigurierten Server so aussehen, als fehle die Unterstützung. Der zweithäufigste Grund ist, dass das Kompressionsmodul aktiviert, aber auf eine Liste von MIME-Typen beschränkt ist, die Ihren Inhaltstyp nicht enthält.

Sollte ich die höchste Kompressionsstufe verwenden?

Für statische Dateien, die einmal beim Build komprimiert werden, ist eine hohe Stufe sinnvoll, weil die Kosten nur einmal anfallen. Für Antworten, die pro Anfrage erzeugt werden, können die höchsten Stufen mehr Serverzeit kosten als die Übertragung, die sie sparen. Üblich ist eine mittlere Stufe für dynamische Inhalte und eine hohe für statische Dateien.

Was kostet fehlende Kompression tatsächlich?

In unserer Messung von 291 antwortenden öffentlichen Stellen am 6. September 2026 wog die mittlere Startseite 29 312 übertragene Bytes mit aktiver Kompression und 109 705 Bytes ohne, ein Faktor von 3,7 bei vergleichbaren Seiten. Achtzehn unkomprimierte Websites überschritten allein mit ihrem HTML 200 kB.

Verwandter Stack