[WP] Gzip vs. Brotli: Unterschiede der beiden Komprimierungsalgorithmen

Um Websites – auch solche mit dem CMS WordPress – schneller zu machen, lohnt es sich, auf dem Server die Datenkomprimierung einzurichten. Dann laden die zwischen Webserver und Browser übertragenen Daten schneller, und die ganze Website wird flotter. Das ist einer der Punkte, an die Website-Betreiber am häufigsten denken. Gzip-Komprimierung ist weit verbreitet, und auf vielen Webservern wird zunehmend von gzip auf Brotli umgestellt – Tendenz steigend.

1️⃣ Was ist Komprimierung?

Website URL: Beim Aufruf beginnt ein Austausch zwischen Browser und Server. Dabei teilt der Browser dem Server mit, ob er die Komprimierung von Inhalten (Compression) entpacken kann und welche Komprimierungsalgorithmen er nutzt. So kann der Browser die Daten korrekt entpacken, wenn der Server sie komprimiert sendet. Mit Server und Browser, die Komprimierungsalgorithmen unterstützen, lädt deine Website daher noch schneller.

Verbindet sich ein Browser mit einem Server, sendet er Header wie gzip- oder Brotli-Komprimierung. Die mit einem der beiden komprimierten Daten werden an den Browser geliefert und laden schneller als unkomprimierte Daten.

Content-encoding: gzip
Content-encoding: br

Komprimiert werden vor allem Textdateien:
· HTML
· CSS
· JavaScript

2️⃣ Was ist Gzip-Komprimierung?

Die gängigen Komprimierungsalgorithmen bei Webhostern sind Gzip und Brotli. Gzip erschien 1992 als Beta, Version 1.0 folgte 1993. Grundsätzlich ist Gzip eines der Standardverfahren, um Daten bei der Übertragung im Internet zu komprimieren. Es basiert auf DEFLATE, einem frühen Komprimierungsalgorithmus, und hat seinen Namen vom älteren Unix-Dateikomprimierungsprogramm gzip.

DEFLATE kombiniert den Algorithmus LZ77 (Lempel-Ziv 1977) mit der Huffman-Kodierung. LZ77 sucht wiederholte Daten, findet übereinstimmende Zeichenfolgen und ersetzt sie durch Codes. Die Huffman-Kodierung vergibt anhand der Häufigkeit jedes Zeichens die kürzesten Bitcodes.

Gzip komprimiert Daten mit DEFLATE und nutzt in HTTP-Anfragen und -Antworten den Header ‘Accept-Encoding: gzip’, damit nur komprimiert wird, wenn der Client Gzip unterstützt. Diese Komprimierung beschleunigt das Laden der Website.

3️⃣ Was ist Brotli-Komprimierung?

Brotli wurde 2013 von den Google-Mitarbeitern Jyrki Alakuijala und Zoltán Szabadka entwickelt.

Gzip war ursprünglich zum Komprimieren von Dateien gedacht, wurde aber für den Einsatz im Web angepasst. Brotli dagegen wurde  für das Web entwickelt. Mit Brotli kann der Webserver Inhalte deshalb komprimieren, bevor er sie an den Browser schickt. Weil sie vor dem Streaming an den Browser komprimiert werden, ist das ein besseres und moderneres Verfahren.

Brotli nutzt dieselben zwei Kerntechniken wie die GZIP-Komprimierung: LZ77 und die Huffman-Kodierung.

4️⃣ Gzip-Komprimierung vs. Brotli-Komprimierung

Gzip komprimiert (& entpackt) Daten mit dem DEFLATE-Verfahren, Brotli mit einem eigenen Format, das LZ77 und die Huffman-Kodierung um Kontextmodellierung ergänzt.

• Gzip komprimiert schneller als Brotli.
• Brotli wurde speziell für das Web entwickelt.
• Brotli bietet auf jeder Komprimierungsstufe eine bessere Kompressionsrate (also kleinere komprimierte Dateien).
• Gegenüber Gzip komprimiert Brotli diese drei Dateitypen besser: HTML um 21%, CSS um 17% und JavaScript um 14%.

Immer mehr Webserver bevorzugen Brotli gegenüber Gzip. Da Brotli darauf ausgelegt ist, Streams sofort zu komprimieren, soll das Entpacken im Frontend insgesamt bis zu 64% schneller sein als bei Gzip.

RFC 1952 aus dem Mai 1996 beschreibt, dass das Gzip-Format das Komprimierungsverfahren DEFLATE nutzt und einen CRC-Wert enthält, mit dem sich beschädigte Daten erkennen lassen. Am Ende der komprimierten Daten werden der CRC-32-Wert und die Größe der Originaldaten gespeichert.

RFC 7932 aus dem Juli 2016 hält fest, dass Brotli den Algorithmus LZ77 mit der Huffman-Kodierung kombiniert. Zusätzlich wählt es die Huffman-Codes anhand der zwei vorangehenden Bytes der unkomprimierten Daten als Kontext und kann statt wiederholter Zeichenfolgen auch auf Wörter in einem statischen Wörterbuch mit 122.784 Bytes verweisen.

Die beiden Formate erscheinen im Antwort-Header als [Content-Encoding: gzip] und [Content-Encoding: br]. Der Wert [br] wurde in RFC 7932 als HTTP-Content-Coding registriert.

5️⃣ Gzip- und Brotli-Komprimierung gemessen: Server mit Nginx + Apache

Auf einem WordPress-Server, der Nginx und Apache zusammen nutzt, wurden die Antworten für denselben Beitrag, die Standard-Block-CSS-Datei von WordPress und die jQuery-Datei verglichen – nur der Anfrage-Header wurde geändert. Anfragen mit nur gzip in [Accept-Encoding], mit nur br und ganz ohne den Header wurden vom selben Server aus mit curl gesendet.

for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done

== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833

Das HTML eines Beitrags wurde bei der gzip-Anfrage auf 21.390 Bytes und bei der br-Anfrage auf 20.190 Bytes komprimiert; die Anfrage ohne Header erhielt die unkomprimierten 90.833 Bytes. Die br-Antwort war 1.200 Bytes (5,6%) kleiner als die gzip-Antwort.

for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done

== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553

Bei der gzip-Anfrage wurde die CSS-Datei auf 19.655 Bytes und die jQuery-Datei auf 30.633 Bytes komprimiert. Mit nur br oder ohne Header kamen die Originale mit 140.829 Bytes und 87.553 Bytes unverändert zurück, ohne [Content-Encoding]-Header.

nginx -V 2>&1 | grep -c brotli

0

httpd -M 2>/dev/null | grep -E 'brotli|deflate'

 deflate_module (shared)
 brotli_module (shared)

Statische Dateien wie CSS und JS liefert und komprimiert Nginx direkt; da das Nginx in diesem Setup kein Brotli-Modul hat, komprimiert es nur mit gzip.

Beim HTML beantwortet WordPress die Anfrage, die Nginx an Apache weitergibt, und Apache komprimiert die Antwort. Apache hat sowohl das Brotli-Modul als auch das Modul [mod_deflate], das für die Gzip-Komprimierung zuständig ist.

for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done

== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633

Nur weil der Server ein Brotli-Modul hat, bekommt der Browser noch keine mit Brotli komprimierten Antworten. Bei einer Anfrage mit [gzip, deflate, br, zstd] – demselben Wert, den Edge 155 sendet – komprimierte auch Apache das HTML mit gzip, und alle drei Dateien kamen mit gzip zurück.

Auch wenn br vor gzip stand oder wie in [br;q=1.0, gzip;q=0.5] als bevorzugt markiert war, kam das HTML mit gzip zurück. Beim Öffnen desselben Beitrags und der beiden Dateien in Edge wurde ebenfalls alles mit gzip übertragen.

Die Zeit bis zum ersten Byte ist der Median der curl-Werte [time_starttransfer], jeweils 40-mal in gemischter Reihenfolge gemessen; jede Anfrage baute eine neue Verbindung auf, daher ist die TLS-Verbindungszeit enthalten. Beim HTML brauchte die unkomprimierte Antwort 22,7 ms, gzip 26,3 ms, br 26,5 ms und die Anfrage wie vom Browser 25,0 ms. CSS und JS lagen mit und ohne Komprimierung bei 18–21 ms.

Die Komprimierungsgeschwindigkeit von Gzip und Brotli wurde nicht selbst gemessen, sondern anhand öffentlicher Quellen verglichen. RFC 7932 hält fest, dass Brotli mit einer deutlich höheren Kompressionsrate komprimiert als das Programm gzip und viel schneller entpackt als aktuelle LZMA-Implementierungen. Google erklärt im Brotli-Repository, dass Brotli ähnlich schnell wie deflate ist, aber dichter komprimiert.

2015 testete Cloudflare beide Verfahren mit 10.655 HTML-, CSS- und JavaScript-Dateien. Brotli lieferte auf der höchsten Qualitätsstufe im Schnitt um den Faktor 1,19 kleinere Ergebnisse als zlib auf der höchsten Stufe, komprimierte aber mit 0,5 MB pro Sekunde deutlich langsamer als zlib auf Stufe 9 mit 41,9 MB. Brotli auf Stufe 4 hatte eine ähnliche Kompressionsrate wie zlib auf Stufe 8 und war im Gesamtschnitt etwas schneller, bei Dateien unter 64 KB aber um den Faktor 1,48 langsamer.

Hier ging es um die Optimierung einer Website durch die Komprimierung von Dateien wie HTML, CSS und JavaScript. Für eine schnellere Website gehören Dateikomprimierung und Bildoptimierung zu den wesentlichen Elementen.

🔢 FAQ & empfohlene Inhalte

ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt^{(bei Aktionsrabatten sinkt er ↓)}, steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.