PageSpeed-Audit empfiehlt Brotli. Das aktive Team brotli on; brotli_comp_level 11 auf Nginx für alles – einschließlich einer 200-Kilobyte-JSON-API, die bei jeder Anfrage generiert wird. Die Zeit bis zum ersten Byte erhöht sich von einhundertzwanzig Millisekunden auf dreihundertachtzig auf einem VPS mit zwei vCPUs; Der Lighthouse-Score steigt bei der Metrik „Übertragene Bytes“. Mobile Nutzer spüren die Langsamkeit.
Durch die Komprimierung werden Bytes verkleinert – sie kostet CPU und verzögert manchmal bis zum ersten Byte. Brotli versus gzip ist keine Religion: Es ist eine Entscheidung darüber, wo und auf welcher Ebene komprimiert werden soll, abhängig von der Art des Inhalts und der Serverlast.
gzip vs. Brotli: die Kompromisse
| Algorithmus | Komprimierung | Komprimierungsgeschwindigkeit | Typische Verwendung |
|---|---|---|---|
| gzip Level 6 | Gut | Schnell | Dynamisches HTML, API |
| Brotli Stufe 4 bis 6 | Am besten | Mäßig | Dynamisch, wenn Prozessor verfügbar |
| Brotli Level 11 + Vorkomprimierung | Maximal | Offline | statisch .js/.css |
Vorkomprimierung besteht aus der Generierung von „file.js.br“ im Upstream („brotli -k file.js“) und der anschließenden Bereitstellung mit „Content-Encoding: br“ – keine CPU-Auslastung zum Zeitpunkt der Anforderung.
Das Komprimieren eines JPEG-Bildes bedeutet, dass der Prozessor für null eingesparte Bytes bezahlt werden muss.
Nginx, Apache, CDN: eine einzelne Ebene
Konfigurieren Sie unter Nginx „gzip on;“ gzip_types...; Brotli auf; brotli_types ...;` mit moderaten Stufen (vier bis sechs). Cloudflare und ähnliche CDNs beinhalten häufig eine Komprimierung am Rand – deaktivieren Sie die doppelte Komprimierung auf der Ursprungsseite.
Bei Shared wird die Komprimierung manchmal von der Systemsteuerung vorgegeben. Messen Sie die Auswirkung auf die Verzögerung bis zum ersten Byte, bevor Sie mehrere Schichten stapeln.
Dynamisch vs. statisch: zwei Strategien
Für statisch erzeugt die Build-Pipeline „.gz“- und „.br“-Dateien; nginx enable gzip_static on; brotli_static on;. Für dynamisch reicht oft Gzip-Level fünf aus – messen Sie die Verzögerung bei Perzentil 95, bevor Sie ein aggressives Brotli aktivieren. Bei JSON-APIs ist die Komprimierung ab einem Wert von ein bis zwei Kilobyte sinnvoll. Mikroantworten profitieren davon nicht.
HTTP/2 und HTTP/3 ändern die Header-Komprimierung, nicht die komprimierbare Body-Logik.
Shared und VPS: Host-Einschränkungen
Bei Shared wird die Komprimierung oft global vom Host aktiviert – Sie wählen nicht immer den Algorithmus oder die Stufe aus. Messen Sie, bevor Sie eine PHP-Ebene oder ein WordPress-Plugin hinzufügen, das bereits das komprimiert, was der Server komprimiert. Auf VPS steuern Sie Nginx oder Apache – aber ein VPS mit zwei vCPUs wird unter Black Friday-Last schnell mit Brotli Level 11 auf dynamischem HTML gesättigt sein.
Überprüfen Sie die Hosting-Datei im Verzeichnis, um zu prüfen, ob Edge-Komprimierung oder CDN enthalten ist – manchmal ergibt sich der beste Gewinn aus dem Hosting-Produkt und nicht aus einer aggressiven Nginx-Einstellung.
Maß: Bytes versus Latenz
Vergleichen Sie die übertragenen Bytes (Browser-Entwicklertools), die Zeit bis zum ersten Byte (Navigations-Timing) und die CPU-Auslastung des Ursprungs unter realer Last. Das Ziel besteht darin, Bytes zu gewinnen, ohne die Verzögerung auf kritischen Seiten um mehr als fünfzig Millisekunden zu erhöhen.
Häufige Fehler
Doppelte PHP-Komprimierung plus Nginx. „gzip_min_length 256“ vergessen. Brotli wird auf SSE- oder WebSocket-Streams angewendet, wo es ungeeignet ist. Maximaler HTML-Wert, der unter Last generiert wird, was einen bescheidenen VPS in einen CPU-Engpass verwandelt.
Der Gipfel: Leuchtturm-Score, verschlechterte Erfahrung
Komprimieren ohne zusätzliche Latenz bedeutet das Statische vorkomprimieren, das Dynamische zu moderieren und am richtigen Netzwerk-Hop (Netzwerkrand statt Ursprung) zu komprimieren.
Entscheide dich und gehe ohne blinden Fleck voran
Überwachen Sie die bereitgestellten MIME-Typen und eliminieren Sie unnötige Komprimierung bereits komprimierter Formate. Statische Assets im Build vorkomprimieren und über Nginx oder CDN bereitstellen. Wenden Sie nach der Messung gzip an oder moderieren Sie Brotli auf dynamisches HTML. Stellen Sie sicher, dass nur eine Ebene jede Antwort komprimiert. Messen Sie die Verzögerung bis zum ersten Byte** vor und nach Änderungen. Vergleichen Sie Hosts und CDNs über das Verzeichnis und den Vergleicher.
Häufig gestellte Fragen
Ist Brotli immer besser als gzip?
Brotli komprimiert Text im Allgemeinen besser, insbesondere bei hohen Pegeln – allerdings ist die Komprimierung langsamer. Es ist ideal für vorkomprimierte statische Assets; gzip oder Brotli auf mittlerem Niveau eignen sich am besten für dynamisches HTML.
Wo komprimieren – Nginx, CDN oder PHP?
Bevorzugen Sie Network Edge oder Nginx für statische Dateien. Vermeiden Sie die Komprimierung in PHP, wenn Nginx dies bereits tut. Überprüfen Sie bei Shared die vom Host vorgegebenen Prozessorgrenzen.
Welche MIME-Typen sollen komprimiert werden?
text/html, text/css, application/javascript, application/json, image/svg+xml – nicht das bereits komprimierte JPEG, PNG oder WebP.
Wie kann Brotli für ältere Browser bereitgestellt werden?
Aushandlung über Accept-Encoding: Brotli, falls unterstützt, ansonsten gzip. Das CDN verwaltet die beiden Versionen häufig in einem separaten Cache mithilfe des Vary-Headers.
Weniger Bytes zählen nur, wenn das erste Byte pünktlich ankommt.