Nginx Gzip-Komprimierung: Steigern Sie die Ladegeschwindigkeit Ihrer Website

Die Nginx Gzip-Komprimierung hilft Ihrer Website, schneller zu laden, indem sie textbasierte Antworten verkleinert, bevor sie über das Netzwerk übertragen werden. Wenn Ihre Seiten HTML, CSS, JavaScript, JSON, XML oder SVG-Dateien enthalten, kann die Komprimierung die Übertragungsgröße reduzieren, ohne dass sich für den Benutzer im Browser etwas ändert.

Das Ziel ist einfach: Weniger Bytes senden, Wartezeit reduzieren und Bandbreite besser nutzen. Für die meisten Produktionsseiten ist Gzip einer der einfachsten Nginx-Performance-Gewinne, die Sie sicher aktivieren können.

Wie die Gzip-Komprimierung in Nginx funktioniert

Die Gzip-Komprimierung erfolgt, nachdem Nginx eine Antwort ausgewählt hat, aber bevor es diese Antwort an den Client sendet. Der Browser kündigt die Unterstützung mit dem Accept-Encoding-Request-Header an. Wenn Gzip aktiviert ist und der Antworttyp Ihrer Konfiguration entspricht, komprimiert Nginx den Body und sendet ihn mit Content-Encoding: gzip.

Dies funktioniert am besten für Textformate, da sie wiederholte Muster enthalten. HTML-Vorlagen, CSS-Klassennamen, JavaScript-Bezeichner und JSON-Schlüssel lassen sich oft sehr gut komprimieren. Bilder, Videos, PDFs und Archive sind normalerweise bereits komprimiert, sodass der Versuch, sie zu gzippen, CPU verschwenden kann, ohne die Datei wesentlich zu verkleinern.

Eine grundlegende Konfiguration wird normalerweise im http-Block platziert, sodass sie serverübergreifend gilt:

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

Die Direktive gzip on aktiviert die Komprimierung. gzip_types teilt Nginx mit, welche MIME-Typen über den Standard text/html hinaus komprimiert werden sollen. gzip_min_length vermeidet CPU-Verschwendung für kleine Antworten, bei denen der Gzip-Header-Overhead den Nutzen zunichte machen kann.

gzip_vary on fügt einen Vary: Accept-Encoding-Header hinzu. Dies ist wichtig, wenn Ihre Website hinter einem CDN oder einem gemeinsamen Cache liegt, da Caches wissen müssen, dass komprimierte und unkomprimierte Versionen unterschiedliche Varianten derselben URL sind.

Für eine breitere Nginx-Performance-Basis sollten Sie auch Nginx-Performance-Tuning überprüfen.

Ein Detail, das oft übersehen wird: Nginx komprimiert text/html immer, wenn Gzip aktiviert ist, daher muss text/html nicht in gzip_types erscheinen. Wenn Sie es trotzdem hinzufügen, warnt Nginx möglicherweise, dass der MIME-Typ doppelt ist. Diese Warnung ist harmlos, aber ein Zeichen dafür, dass die Konfiguration kopiert wurde, ohne bereinigt zu werden.

Auswahl sicherer Komprimierungseinstellungen

Der größte Fehler bei der Nginx Gzip-Komprimierung ist, die Komprimierungsstufe wie einen Lautstärkeregler zu behandeln. Höher ist nicht immer besser. Gzip-Stufen reichen normalerweise von 1 bis 9. Stufe 1 ist am schnellsten, komprimiert aber weniger. Stufe 9 komprimiert mehr, kann aber deutlich mehr CPU kosten.

Für viele Websites ist gzip_comp_level 4, 5 oder 6 ein praktischer Bereich. Es bietet eine starke Komprimierung, ohne Ihren Server zu stark zu belasten. Wenn Ihr Nginx-Server hohen Datenverkehr verarbeitet oder auf einer kleinen Instanz läuft, vermeiden Sie es, direkt auf Stufe 9 zu springen.

Gute Standardeinstellungen sehen so aus:

• Verwenden Sie gzip_comp_level 5 für ein ausgewogenes Setup.
• Verwenden Sie gzip_min_length 1024, damit kleine Antworten die Komprimierung überspringen.
• Komprimieren Sie textbasierte Assets, keine bereits komprimierten Medien.
• Behalten Sie gzip_vary on bei, wenn Caches oder CDNs beteiligt sind.
• Testen Sie die CPU-Auslastung nach Aktivierung der Komprimierung.

Hier ist ein häufiges Szenario. Sie betreiben eine Dokumentationsseite mit vielen CSS-, JavaScript- und HTML-Seiten. Vor Gzip lädt eine Seite 650 KB an Text-Assets. Nach Aktivierung der Komprimierung kann die Übertragungsgröße drastisch sinken, während der Browser nach der Dekomprimierung immer noch dieselben Dateien erhält. Benutzer mit langsameren Verbindungen spüren die Verbesserung am meisten.

Die Gewinne sind nicht auf jeder Website gleich. Eine Seite, die von JPEG-Bildern dominiert wird, wird sich durch Gzip nicht wesentlich verbessern. Ein Dashboard, das große JSON-Antworten sendet, kann sich stark verbessern.

Für APIs sollten Sie gezielter vorgehen. Das Komprimieren einer winzigen JSON-Antwort wie {"ok":true} ist normalerweise sinnlos. Das Komprimieren eines 300 KB großen Suchergebnisses oder Berichts-Payloads kann sich lohnen. Wenn Ihre API private Daten zurückgibt und benutzergesteuerte Eingaben in derselben Antwort widerspiegelt, besprechen Sie die Komprimierungsrisiken mit dem Anwendungsteam, bevor Sie sie überall aktivieren. Das bedeutet nicht "niemals APIs komprimieren". Es bedeutet, dass die Komprimierung in denselben Überprüfungsbereich gehört wie Caching, Cookies und Antwort-Header.

So testen Sie, ob Gzip funktioniert

Testen Sie nach Änderungen an der Nginx-Konfiguration die Syntax vor dem Neuladen:

nginx -t

Laden Sie dann Nginx über Ihren Service-Manager oder Bereitstellungsprozess neu. Ein Neuladen reicht normalerweise aus, da es sich um eine Konfigurationsänderung handelt, nicht um einen vollständigen Binär-Neustart.

Sie können eine Antwort mit curl überprüfen:

curl -I -H "Accept-Encoding: gzip" https://example.com/app.css

Achten Sie auf diesen Header:

Content-Encoding: gzip

Überprüfen Sie auch auf:

Vary: Accept-Encoding

Wenn Sie Content-Encoding: gzip nicht sehen, überprüfen Sie den MIME-Typ der Antwort. Zum Beispiel kann eine JavaScript-Datei, die als text/plain bereitgestellt wird, trotzdem komprimiert werden, wenn text/plain enthalten ist, aber eine benutzerdefinierte API-Antwort mit einem ungewöhnlichen Inhaltstyp passt möglicherweise nicht zu Ihrer gzip_types-Liste.

Die Entwicklertools des Browsers können ebenfalls helfen. Öffnen Sie den Netzwerk-Tab, laden Sie die Seite neu und überprüfen Sie die Antwort-Header und die übertragene Größe. Die übertragene Größe sollte für komprimierbare Dateien kleiner sein als die unkomprimierte Ressourcengröße.

Wenn Sie auch ein CDN verwenden, denken Sie daran, dass das CDN möglicherweise eine eigene Komprimierung durchführt. In diesem Fall ist Nginx möglicherweise nicht die letzte Schicht, die entscheidet, was der Browser erhält. Testen Sie nach Möglichkeit sowohl den direkten Ursprungszugriff als auch die öffentliche CDN-URL.

Wenn die direkte Ursprungsantwort komprimiert ist, die CDN-Antwort jedoch nicht, überprüfen Sie die Komprimierungseinstellungen des CDN und das Cache-Key-Verhalten. Wenn die CDN-Antwort komprimiert ist, der Ursprung jedoch nicht, ist das in Ordnung. Viele Teams lassen das CDN absichtlich die öffentliche statische Komprimierung übernehmen, während die Ursprungskonfiguration einfacher bleibt.

Wann Sie bei Gzip vorsichtig sein sollten

Gzip ist für die meisten statischen und dynamischen Inhalte sicher, aber es gibt Fälle, in denen Sie langsamer vorgehen und sorgfältig testen sollten.

Komprimieren Sie keine Dateien, die bereits komprimiert sind. Häufige Beispiele sind:

• .jpg, .jpeg, .png und .webp
• .mp4, .mov und andere Videoformate
• .zip, .gz, .tar.gz und Paketarchive
• Die meisten Schriftartdateien, abhängig vom Format und Bereitstellungspfad

Sie sollten auch die CPU-Auslastung im Auge behalten. Die Komprimierung ist nicht kostenlos. Wenn Ihr Server bereits nahe an den CPU-Grenzen läuft, kann eine aggressive Komprimierung die Antwortzeiten unter Last verschlechtern. Beginnen Sie mit moderaten Einstellungen und überwachen Sie dann Datenverkehr, Latenz und CPU.

Sicherheitskritische Anwendungen sollten auch vermeiden, Geheimnisse in komprimierten Antworten neben angreifergesteuerten Eingaben preiszugeben. Dies ist ein spezielleres Risiko, aber es ist wissenswert für Apps, die Benutzereingaben in Seiten mit Tokens oder privaten Daten widerspiegeln.

Für statische Assets besteht eine weitere Möglichkeit darin, Dateien während Ihrer Build-Pipeline vorzukomprimieren und .gz-Versionen von der Festplatte bereitzustellen. Dies kann die Laufzeit-CPU reduzieren, insbesondere für große JavaScript-Bundles. Dynamische API-Antworten benötigen weiterhin eine Laufzeitkomprimierung, wenn Sie sie komprimiert haben möchten.

Wenn Sie vorkomprimierte Dateien bereitstellen, aktivieren Sie gzip_static on; und stellen Sie sicher, dass die .gz-Datei aus genau derselben Asset-Version wie die unkomprimierte Datei generiert wird. Eine veraltete app.js.gz neben einer neueren app.js ist ein frustrierender Fehler: Nur Clients, die Gzip anfordern, sehen den alten Code.

gzip_static on;

Diese Direktive ist nützlich für Build-Artefakte, nicht für dynamische Upstream-Antworten. Für dynamische Antworten, die von einem App-Server weitergeleitet werden, benötigt Nginx weiterhin eine Laufzeitkomprimierung, es sei denn, der Upstream sendet bereits einen komprimierten Body.

Wann Sie Hilfe holen sollten

Ziehen Sie einen erfahrenen Nginx-Administrator oder DevOps-Ingenieur hinzu, wenn die Aktivierung von Gzip zu hoher CPU, inkonsistentem CDN-Verhalten oder fehlerhaften Antworten für ältere Clients führt. Sie sollten auch Hilfe holen, wenn die Komprimierungseinstellungen über mehrere enthaltene Konfigurationsdateien gemischt sind und Sie nicht sicher sind, welcher Block tatsächlich aktiv ist.

Für eine einfache Website kann Gzip in Minuten aktiviert werden. Für eine stark frequentierte Anwendung behandeln Sie es wie jede andere Leistungsänderung: Testen Sie es, führen Sie es schrittweise ein und überwachen Sie das Ergebnis.

Die Nginx Gzip-Komprimierung ist eine praktische Möglichkeit, die Ladegeschwindigkeit für textlastige Websites und APIs zu verbessern. Halten Sie die MIME-Typen fokussiert, wählen Sie eine moderate Komprimierungsstufe und überprüfen Sie die Header nach dem Neuladen. Sobald es funktioniert, erhalten Benutzer kleinere Antworten, während Ihr Anwendungscode gleich bleibt.