Brotli vs Gzip: Webserver-Komprimierung optimieren

Wer heute eine Website betreibt, kommt an der Webserver-Komprimierung nicht vorbei. Jedes Kilobyte, das eingespart wird, bedeutet schnellere Ladezeiten, bessere Core Web Vitals und letztlich zufriedenere Nutzer. Die beiden wichtigsten Komprimierungsverfahren im Web sind Gzip und Brotli – doch welches ist besser, und wie konfiguriert man beide optimal? In diesem Artikel vergleichen wir beide Algorithmen, zeigen konkrete Nginx-Konfigurationen und geben dir klare Empfehlungen für die Praxis.

Was ist Gzip?

Gzip ist der Veteran unter den Komprimierungsalgorithmen im Web. Seit den 1990er-Jahren im Einsatz, basiert es auf dem DEFLATE-Algorithmus und wird von praktisch jedem Browser und Webserver unterstützt. Gzip komprimiert textbasierte Inhalte wie HTML, CSS und JavaScript zuverlässig und ist nach wie vor der De-facto-Standard.

Die Komprimierungsstufen reichen von 1 (schnell, wenig Komprimierung) bis 9 (langsam, maximale Komprimierung). In der Praxis bietet Stufe 5 oder 6 den besten Kompromiss zwischen CPU-Last und Dateigröße.

Was ist Brotli?

Brotli wurde 2015 von Google entwickelt und ist speziell für die HTTP-Komprimierung optimiert. Der Algorithmus nutzt ein integriertes Wörterbuch mit häufigen Web-Inhalten (HTML-Tags, CSS-Eigenschaften, JavaScript-Schlüsselwörter), was ihm einen deutlichen Vorteil bei der Komprimierung von Webtechnologien verschafft.

Brotli bietet Komprimierungsstufen von 0 bis 11, wobei die höheren Stufen signifikant bessere Ergebnisse liefern als Gzip – allerdings auch mehr Rechenzeit benötigen. Brotli setzt HTTPS voraus und wird von allen modernen Browsern unterstützt.

Brotli vs Gzip: Der direkte Vergleich

Eigenschaft	Gzip	Brotli
Komprimierungsrate	Gut (ca. 70–80 %)	Sehr gut (ca. 80–90 %)
Geschwindigkeit (Komprimierung)	Schnell	Langsamer bei hohen Stufen
Geschwindigkeit (Dekomprimierung)	Schnell	Vergleichbar schnell
Browser-Support	99 %+	~97 % (alle modernen Browser)
HTTPS erforderlich	Nein	Ja
Komprimierungsstufen	1–9	0–11

In der Praxis liefert Brotli bei Stufe 4–6 bereits bessere Ergebnisse als Gzip bei Stufe 9 – und das bei vergleichbarer CPU-Auslastung. Bei statischen Assets, die vorab komprimiert werden, lohnt sich sogar Brotli-Stufe 11.

Reale Einsparungen

Typische Komprimierungsergebnisse für eine 100 KB große JavaScript-Datei:

• Unkomprimiert: 100 KB
• Gzip (Stufe 6): ~28 KB
• Brotli (Stufe 6): ~23 KB
• Brotli (Stufe 11): ~20 KB

Das bedeutet: Brotli spart gegenüber Gzip im Schnitt 15–25 % zusätzlich ein – bei textlastigen Inhalten manchmal sogar mehr.

Nginx mit Gzip konfigurieren

Die Gzip-Komprimierung ist in Nginx standardmäßig verfügbar und schnell eingerichtet. Öffne deine Nginx-Konfiguration:

sudo nano /etc/nginx/nginx.conf

Füge im http-Block folgende Direktiven ein:

http {
    # Gzip aktivieren
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_min_length 256;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;

    # MIME-Types für Komprimierung
    gzip_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        application/rss+xml
        image/svg+xml
        font/woff2;
}

Teste die Konfiguration und lade Nginx neu:

sudo nginx -t
sudo systemctl reload nginx

Wichtige Gzip-Parameter erklärt

• gzip_comp_level 6 – Optimaler Kompromiss zwischen Komprimierung und CPU-Last
• gzip_min_length 256 – Dateien unter 256 Bytes werden nicht komprimiert (Overhead wäre größer als der Nutzen)
• gzip_vary on – Setzt den Vary: Accept-Encoding-Header, wichtig für Caches und CDNs
• gzip_proxied any – Komprimiert auch Antworten, die über einen Proxy kommen

Nginx mit Brotli konfigurieren

Brotli ist kein Standard-Modul von Nginx und muss als dynamisches Modul nachinstalliert werden. Auf Ubuntu/Debian geht das so:

sudo apt update
sudo apt install libnginx-mod-brotli

Falls das Paket nicht verfügbar ist, kannst du das Modul auch manuell kompilieren:

git clone https://github.com/google/ngx_brotli.git
cd ngx_brotli
git submodule update --init

Nach der Installation aktivierst du Brotli in der Nginx-Konfiguration:

http {
    # Brotli dynamische Komprimierung
    brotli on;
    brotli_comp_level 6;
    brotli_min_length 256;
    brotli_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        application/rss+xml
        image/svg+xml
        font/woff2;

    # Brotli statische Komprimierung (vorab komprimierte .br-Dateien)
    brotli_static on;
}

Statische Brotli-Komprimierung nutzen

Für maximale Performance solltest du statische Assets vorab komprimieren. So vermeidest du die CPU-Last zur Laufzeit und kannst die höchste Komprimierungsstufe verwenden:

# Einzelne Datei komprimieren
brotli -q 11 -o style.css.br style.css

# Alle CSS- und JS-Dateien im Verzeichnis komprimieren
find /var/www/html -type f \( -name "*.css" -o -name "*.js" -o -name "*.html" -o -name "*.svg" \) \
  -exec brotli -q 11 -f -k {} \;

Mit brotli_static on; prüft Nginx automatisch, ob eine .br-Version der angeforderten Datei existiert, und liefert diese aus – ganz ohne dynamische Komprimierung.

Die optimale Konfiguration: Brotli und Gzip kombinieren

Die beste Strategie ist ein Fallback-Ansatz: Brotli als bevorzugte Komprimierung, Gzip als Fallback für ältere Clients. So stellst du sicher, dass kein Besucher unkomprimierte Inhalte erhält:

http {
    # Brotli (bevorzugt)
    brotli on;
    brotli_comp_level 6;
    brotli_static on;
    brotli_min_length 256;
    brotli_types text/plain text/css text/javascript application/javascript
                 application/json application/xml image/svg+xml font/woff2;

    # Gzip (Fallback)
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_min_length 256;
    gzip_types text/plain text/css text/javascript application/javascript
               application/json application/xml image/svg+xml font/woff2;
}

Nginx wählt automatisch das richtige Verfahren basierend auf dem Accept-Encoding-Header des Browsers.

Komprimierung testen und verifizieren

Nach der Konfiguration solltest du unbedingt prüfen, ob die Komprimierung tatsächlich aktiv ist:

# Brotli testen
curl -s -H "Accept-Encoding: br" -I https://example.com | grep -i content-encoding
# Erwartete Ausgabe: content-encoding: br

# Gzip testen
curl -s -H "Accept-Encoding: gzip" -I https://example.com | grep -i content-encoding
# Erwartete Ausgabe: content-encoding: gzip

# Dateigröße vergleichen
curl -s -H "Accept-Encoding: identity" -o /dev/null -w "%{size_download}" https://example.com/style.css
curl -s -H "Accept-Encoding: br" -o /dev/null -w "%{size_download}" https://example.com/style.css

Zusätzlich empfehle ich Online-Tools wie brotli.pro oder die Chrome DevTools (Network-Tab → Spalte „Content-Encoding"), um die Komprimierung visuell zu überprüfen.

Build-Pipeline: Vorab-Komprimierung automatisieren

Wer die Komprimierung in den Build-Prozess integriert, spart Serverressourcen. Hier ein Beispiel mit einem einfachen Bash-Skript für CI/CD-Pipelines:

#!/bin/bash
# compress-assets.sh – Vorab-Komprimierung für Deployment

WEBROOT="/var/www/html"
EXTENSIONS="html css js svg json xml"

for ext in $EXTENSIONS; do
    find "$WEBROOT" -type f -name "*.$ext" | while read file; do
        # Brotli (Stufe 11 für maximale Komprimierung)
        brotli -q 11 -f -k "$file"
        # Gzip (Stufe 9 für maximale Komprimierung)
        gzip -9 -f -k "$file"
        echo "Komprimiert: $file"
    done
done

chmod +x compress-assets.sh
./compress-assets.sh

In Kombination mit brotli_static on; und gzip_static on; liefert Nginx die vorab komprimierten Dateien direkt aus, ohne sie bei jedem Request erneut zu komprimieren.

Häufige Fehler vermeiden

• Bilder komprimieren: JPEG, PNG und WebP sind bereits komprimiert. Gzip oder Brotli auf diese Formate anzuwenden, bringt nichts und verschwendet CPU-Zyklen.
• Zu hohe Komprimierungsstufe bei dynamischen Inhalten: Brotli Stufe 11 für dynamische API-Responses verlangsamt den Server. Nutze Stufe 4–6 für dynamische und Stufe 11 nur für statische, vorab komprimierte Inhalte.
• Fehlender Vary-Header: Ohne gzip_vary on; können CDNs und Proxies falsch gecachte Inhalte ausliefern.
• HTTPS vergessen: Brotli funktioniert ausschließlich über HTTPS. Ohne gültiges SSL-Zertifikat greift nur Gzip.

Fazit

Brotli ist Gzip in fast allen Belangen überlegen – bessere Komprimierungsraten, optimiert für Web-Inhalte und von allen modernen Browsern unterstützt. Die ideale Strategie ist klar: Brotli als primäre Komprimierung mit Gzip als Fallback. Wer zusätzlich auf statische Vorab-Komprimierung setzt, holt das Maximum an Performance heraus, ohne den Server zu belasten.

Die Umstellung lohnt sich: Bei typischen Websites reduziert der Wechsel von reinem Gzip auf optimiertes Brotli die übertragene Datenmenge um 15–25 %. Das verbessert nicht nur die Ladezeit, sondern auch das Google-Ranking durch bessere Core Web Vitals. Der Konfigurationsaufwand ist minimal – die Wirkung spürbar.