Nginx-Komprimierung meistern: Gzip vs. Brotli für Web-Performance

Nginx-Komprimierung ist eine dieser Änderungen, die sich klein anfühlen, bis man das Netzwerk-Panel betrachtet. Eine CSS-Datei, ein JavaScript-Bundle, eine HTML-Seite, eine JSON-API-Antwort oder ein SVG können oft als viel kleinere Antwort über das Netzwerk reisen und sich dann im Browser wieder zum gleichen Inhalt entfalten.

Die praktische Wahl ist normalerweise nicht "Gzip oder Brotli für immer." Die meisten Produktionsumgebungen verwenden beide: Brotli für Browser, die danach fragen, Gzip als Fallback und vorab komprimierte statische Dateien, die die Build-Pipeline im Voraus erstellen kann. Die Details sind jedoch wichtig. Ein kopierter Komprimierungsblock kann CPU verschwenden, wichtige MIME-Typen überspringen oder stillschweigend fehlschlagen, weil das Brotli-Modul nicht installiert ist.

Web-Komprimierung in Nginx verstehen

Komprimierung funktioniert, indem sie wiederkehrende Muster in Daten (wie HTML-, CSS- oder JavaScript-Dateien) findet und durch kürzere Referenzen ersetzt. Dies reduziert die Gesamtgröße der über das Netzwerk übertragenen Datei. Nginx fungiert als Vermittler, der den gewählten Komprimierungsalgorithmus dynamisch anwendet, bevor die Daten an den Browser gesendet werden.

Nginx benötigt typischerweise das ngx_http_gzip_module für Gzip und ein separates Brotli-Modul für Brotli. Die meisten gängigen Nginx-Pakete enthalten Gzip-Unterstützung. Brotli ist variabler: Einige Distributionen paketieren es als dynamisches Modul, einige Drittanbieter-Repositories enthalten es, und einige Builds haben es überhaupt nicht.

Voraussetzungen

Stellen Sie sicher, dass Ihre Nginx-Installation Brotli unterstützt, wenn Sie es verwenden möchten. Sie können oft überprüfen, ob Brotli verfügbar ist, indem Sie Folgendes ausführen:

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

Wenn die Ausgabe Brotli erwähnt, bestätigen Sie, ob es kompiliert oder als dynamisches Modul geladen ist. Auf Debian- oder Ubuntu-basierten Systemen überprüfen Sie auch Dateien unter /etc/nginx/modules-enabled/, wenn Ihr Paket dynamische Module verwendet:

ls -l /etc/nginx/modules-enabled/ | grep -i brotli

Wenn Nginx brotli on; während nginx -t ablehnt, ist das Modul für dieses laufende Nginx-Binary nicht verfügbar, selbst wenn das Betriebssystem ein Brotli-Paket anderswo installiert hat.

1. Gzip-Komprimierung konfigurieren

Gzip ist der ausgereifte, weitgehend unterstützte Standard für Inhaltskomprimierung. Es bietet eine gute Balance zwischen Komprimierungsrate und CPU-Aufwand.

Gzip in der Nginx-Konfiguration aktivieren

Gzip-Einstellungen werden typischerweise in den http-, server- oder location-Blöcken Ihrer Nginx-Konfigurationsdatei (nginx.conf oder eingebundene Konfigurationsdateien) platziert.

Um die Gzip-Komprimierung zu aktivieren, verwenden Sie die folgenden Direktiven:

http {
    # Gzip-Komprimierung aktivieren
    gzip on;

    # Minimale Antwortgröße für Komprimierung festlegen (Bytes)
    # Nur Dateien größer als 1000 Bytes komprimieren
    gzip_min_length 1000;

    # Komprimierungsstufe (1=schnellste/niedrigste Komprimierung, 9=langsamste/höchste Komprimierung)
    gzip_comp_level 6;

    # Festlegen, welche MIME-Typen komprimiert werden sollen
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

    # Empfohlen: Den Vary: Accept-Encoding-Header senden, damit Proxys sowohl komprimierte als auch unkomprimierte Versionen zwischenspeichern
    gzip_vary on;

    # Empfohlen: Gzip-Header zur Identifikation hinzufügen
    gzip_proxied any;
}

Wichtige Gzip-Direktiven erklärt

• gzip on;: Aktiviert das Gzip-Modul.
• gzip_comp_level: Die Einstellung zwischen 4 und 6 ist oft der optimale Bereich für die Leistung. Höhere Stufen sparen mehr Bandbreite, erhöhen aber die CPU-Auslastung auf dem Server.
• gzip_types: Entscheidend ist, dass Sie niemals bereits komprimierte Formate wie Bilder (.jpg, .png, .gif) oder Videos komprimieren sollten.

2. Brotli-Komprimierung konfigurieren

Brotli ist ein neuerer Komprimierungsalgorithmus, der von Google entwickelt wurde. Für Text-Assets erzeugt es oft kleinere Dateien als Gzip. Der genaue Gewinn hängt vom Inhalt, der Komprimierungsstufe und davon ab, ob Dateien bei jeder Anfrage oder vorab während der Bereitstellung komprimiert werden.

Brotli in der Nginx-Konfiguration aktivieren

Die Brotli-Konfiguration verwendet ähnliche Direktiven, ersetzt jedoch gzip durch brotli.

brotli on;
brotli_comp_level 6; # Typischerweise 4 bis 8 wird empfohlen
brotli_static on; # Aktiviert das Ausliefern vorab komprimierter .br-Dateien, falls verfügbar
brotli_types text/plain text/css application/json application/javascript application/x-javascript text/xml;

Wichtiger Hinweis zur Vorkompression (brotli_static):

Brotli-Komprimierung kann CPU-intensiv sein, wenn sie für jede Anfrage dynamisch durchgeführt wird. Eine gängige Best Practice ist es, Assets mit einem dedizierten Offline-Tool (wie dem brotli-Kommandozeilenprogramm) vorzukomprimieren und die .br-Version neben der Originaldatei zu speichern (z.B. style.css und style.css.br).

Die Einstellung brotli_static on; weist Nginx an, zu prüfen, ob eine vorab komprimierte .br-Datei für die angeforderte Ressource existiert, und diese direkt auszuliefern, wenn der Client Brotli unterstützt, wodurch die Echtzeitverarbeitung vollständig umgangen wird.

3. Gzip vs. Brotli: Die richtige Wahl treffen

Die Wahl zwischen Gzip und Brotli hängt stark von der Client-Unterstützung und Ihren Server-Ressourcen ab.

Merkmal	Gzip	Brotli	Empfehlung
Komprimierungsrate	Gut	Oft besser für Text-Assets	Brotli gewinnt normalerweise
CPU-Last (dynamisch)	Niedrig	Mittel bis Hoch	Gzip ist leichter
Client-Unterstützung	Nahezu universell (Alle modernen Browser)	Sehr hoch (Die meisten modernen Browser)	Gzip ist sicherer für Legacy-Unterstützung
Vorkompression	Möglich, aber weniger üblich	Sehr empfohlen (brotli_static)	Verwenden Sie nach Möglichkeit vorab komprimiertes Brotli

Der hybride Ansatz: Best Practice

Die robusteste moderne Konfiguration verwendet einen hybriden Aufbau, der Brotli für moderne Clients priorisiert und gleichzeitig Gzip als zuverlässigen Fallback bereitstellt.

1. Brotli priorisieren: Konfigurieren Sie Brotli zuerst, oft mit brotli_static on; für Geschwindigkeit.
2. Fallback auf Gzip: Stellen Sie sicher, dass Gzip aktiviert und konfiguriert ist, um Clients zu behandeln, die Brotli nicht unterstützen.

Nginx wählt eine Antwort basierend auf dem Accept-Encoding-Header des Clients und den in Ihrem Build aktivierten Modulen aus. Im normalen Browserverkehr wird Brotli bevorzugt, wenn der Client br ankündigt; Gzip bleibt nützlich für Clients, Tools, Proxys und ältere Stacks, die nur gzip anfordern.

Beispiel für eine hybride Konfiguration

Wenn Ihre Nginx-Version beide Module unterstützt, können Sie beide gleichzeitig aktivieren. Nginx priorisiert, welches Modul den Inhalt basierend auf den Anforderungsheadern des Clients ausliefert.

http {
    # --- Brotli-Konfiguration ---
    brotli on;
    brotli_comp_level 6;
    brotli_static on;
    brotli_types
        text/plain
        text/css
        application/javascript
        application/json
        application/xml
        image/svg+xml;

    # --- Gzip-Konfiguration (Fallback) ---
    gzip on;
    gzip_comp_level 5;
    gzip_vary on;
    gzip_proxied any;
    gzip_types
        text/plain
        text/css
        application/javascript
        application/json
        application/xml
        image/svg+xml;
}

Tipps zur Leistungsoptimierung

Unabhängig davon, für welchen Algorithmus Sie sich entscheiden, befolgen Sie diese Best Practices für maximale Wirkung:

1. Die tatsächliche Antwort überprüfen

Gehen Sie nicht davon aus, dass die Komprimierung funktioniert, nur weil die Konfigurationsdatei gzip on; oder brotli on; enthält. Überprüfen Sie eine echte Antwort:

curl -I -H 'Accept-Encoding: br,gzip' https://example.com/app.js
curl -I -H 'Accept-Encoding: gzip' https://example.com/app.js

Achten Sie auf Content-Encoding: br oder Content-Encoding: gzip. Fügen Sie auch Vary: Accept-Encoding zu Antworten hinzu, die von einem CDN oder einem gemeinsamen Proxy zwischengespeichert werden könnten, damit komprimierte und unkomprimierte Varianten nicht vermischt werden.

2. Übermäßige Komprimierung vermeiden

Setzen Sie gzip_comp_level oder brotli_comp_level niemals zu hoch (z.B. 9 oder 11), es sei denn, Ihr Server ist stark unterausgelastet. Der marginale Gewinn bei der Dateigrößenreduzierung rechtfertigt selten die zusätzlichen CPU-Zyklen, die für die Berechnung erforderlich sind.

3. Vorab komprimierte Dateien zwischenspeichern

Für Brotli ist die Verwendung von brotli_static on; und das Vorkomprimieren Ihrer statischen Assets der größte Leistungsgewinn. Dies verlagert die CPU-Last von der Anfragezeit auf die Bereitstellungszeit.

4. Testen Sie Ihre Konfiguration

Testen Sie nach der Änderung Ihrer Nginx-Konfiguration immer die Syntax, bevor Sie neu laden:

sudo nginx -t

Wenn erfolgreich, laden Sie Nginx neu, um die Änderungen zu übernehmen:

sudo systemctl reload nginx

Sie können auch die Entwicklertools des Browsers oder Leistungstestdienste verwenden, um zu bestätigen, dass Antworten mit Content-Encoding: gzip oder Content-Encoding: br ausgeliefert werden.

Ein praktischer Weg zur Einführung

Beginnen Sie mit Gzip, wenn die Site noch gar keine Komprimierung hat. Es ist in den meisten Nginx-Paketen enthalten und bietet Ihnen eine schnelle Basislinie. Fügen Sie dann Brotli hinzu, sobald Sie die Modulunterstützung bestätigt haben und eine Möglichkeit haben, .br-Dateien für statische Assets während der Bereitstellung zu generieren.

Für eine React-, Vue- oder statische Dokumentationsseite ist die beste Einrichtung normalerweise vorab komprimierte .br- und .gz-Dateien für gebaute Assets, moderate dynamische Komprimierung für HTML- und API-Antworten sowie eine CDN-Konfiguration, die Accept-Encoding respektiert. Für eine kleine API, die nahe an den CPU-Grenzen läuft, kann eine konservative Gzip-Stufe der bessere erste Schritt sein.

Der Gewinn sind nicht nur kleinere Dateien. Eine gute Komprimierung hält die Bandbreite niedrig, hilft langsameren Client-Verbindungen und eliminiert unnötige Übertragungszeit, ohne den Anwendungscode zu ändern. Die Hauptdisziplin besteht darin, die Header zu testen, die Komprimierung von bereits komprimierten Medien zu vermeiden und die Komprimierungsstufen so langweilig zu halten, dass Ihr Server auch bei Verkehrsspitzen noch atmen kann.