Brotli-Komprimierung auf nginx und Apache aktivieren

Brotli ist ein verlustfreier Komprimierungsalgorithmus, entwickelt von den Google-Ingenieuren Jyrki Alakuijala und Zoltan Szabadka, im September 2015 als Open Source veröffentlicht und als RFC 7932 (Juli 2016) standardisiert. Verglichen mit gzip (dem langjährigen Standard) liefert Brotli 15 bis 25 Prozent kleinere Dateien für HTML, CSS und JavaScript bei vergleichbarem CPU-Aufwand, dank eines 120 KB großen statischen Wörterbuchs gängiger Web-Tokens. Brotli wird von allen modernen Browsern seit 2017 unterstützt (Chrome 50 im April 2016, Firefox 44 im Januar 2016, Safari 11 im September 2017, Edge 15 im April 2017) und von jedem großen CDN (Cloudflare seit 2017, Fastly, Akamai, CloudFront seit September 2020). Die HTTP-Content-Encoding-Kennung ist br, vom Browser über Accept-Encoding: gzip, deflate, br angefragt und vom Server mit Content-Encoding: br bestätigt. Brotli reduziert das Seitengewicht typischerweise um 15 bis 30 KB auf einer 200 KB Seite und verbessert Largest Contentful Paint (LCP) um 50 bis 150 ms auf langsamen Mobilverbindungen.

Wann sollte ich Brotli einsetzen?

• Immer für statische Textassets: HTML, CSS, JavaScript, JSON, XML, SVG, Web Fonts (woff2 enthält Brotli intern, nicht erneut komprimieren).
• Niemals für bereits komprimierte Binärformate: JPEG, PNG, WebP, AVIF, MP4, WebM, ZIP, GZ, PDF. Doppelte Komprimierung verschwendet CPU und vergrößert die Ausgabe.
• Immer mit gzip als Fallback, damit sehr alte Clients ohne br-Unterstützung trotzdem komprimierte Antworten erhalten.
• Statisch (vorab komprimiert) nutzt Brotli Quality 11 (langsam, kleinste Ausgabe) zur Build-Zeit. Dynamisch nutzt Quality 4 bis 6 zur Anfragezeit, um CPU und Größe abzuwägen.

Brotli auf nginx aktivieren

nginx liefert Brotli-Support nicht im Mainline. Es wird das Drittanbieter-Modul ngx_brotli von Google benötigt (aktueller Tag 2024) oder nginx Plus, das es kommerziell mitbringt.

Option A: vorgefertigtes ngx_brotli installieren (Ubuntu, Debian)

Modernes Ubuntu (22.04+) und Debian (Bookworm) bieten libnginx-mod-brotli als Paket:

sudo apt update
sudo apt install libnginx-mod-http-brotli-filter libnginx-mod-http-brotli-static

Dann in /etc/nginx/nginx.conf im http-Block:

# Vorab komprimierte Dateien (.br-Dateien zur Build-Zeit erzeugt)
brotli_static on;

# On-the-fly-Komprimierung
brotli on;
brotli_comp_level 6;
brotli_min_length 256;
brotli_types
    application/atom+xml
    application/javascript
    application/json
    application/ld+json
    application/manifest+json
    application/rss+xml
    application/vnd.geo+json
    application/vnd.ms-fontobject
    application/x-font-ttf
    application/x-web-app-manifest+json
    application/xhtml+xml
    application/xml
    font/opentype
    image/bmp
    image/svg+xml
    image/x-icon
    text/cache-manifest
    text/css
    text/plain
    text/vcard
    text/vnd.rim.location.xloc
    text/vtt
    text/x-component
    text/x-cross-domain-policy;

Testen und neu laden:

sudo nginx -t
sudo systemctl reload nginx

Option B: ngx_brotli aus Quellcode kompilieren

sudo apt install build-essential libpcre3-dev libssl-dev zlib1g-dev libbrotli-dev git

NGINX_VERSION=$(nginx -v 2>&1 | grep -oP '\d+\.\d+\.\d+')
wget https://nginx.org/download/nginx-$NGINX_VERSION.tar.gz
tar xf nginx-$NGINX_VERSION.tar.gz
cd nginx-$NGINX_VERSION

git clone --recursive https://github.com/google/ngx_brotli.git

./configure --with-compat --add-dynamic-module=./ngx_brotli
make modules
sudo cp objs/ngx_http_brotli_filter_module.so /etc/nginx/modules/
sudo cp objs/ngx_http_brotli_static_module.so /etc/nginx/modules/

In /etc/nginx/nginx.conf oben:

load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;

Brotli auf Apache aktivieren

Apache 2.4.26 (Juni 2017) und neuer liefern mod_brotli direkt mit. Aktivieren:

sudo a2enmod brotli
sudo systemctl restart apache2

Auf RHEL, CentOS, Rocky Linux und AlmaLinux explizit laden in /etc/httpd/conf.modules.d/00-brotli.conf:

LoadModule brotli_module modules/mod_brotli.so

Konfiguration in /etc/apache2/conf-available/brotli.conf:

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript
    AddOutputFilterByType BROTLI_COMPRESS application/javascript application/json application/xml application/xhtml+xml application/rss+xml
    AddOutputFilterByType BROTLI_COMPRESS application/ld+json application/manifest+json
    AddOutputFilterByType BROTLI_COMPRESS image/svg+xml image/x-icon
    AddOutputFilterByType BROTLI_COMPRESS font/ttf font/otf

    BrotliCompressionQuality 5
    BrotliCompressionWindow 18
    BrotliCompressionMaxInputBlock 24

    <IfModule mod_headers.c>
        Header append Vary Accept-Encoding
    </IfModule>
</IfModule>

sudo a2enconf brotli
sudo apachectl configtest
sudo systemctl reload apache2

BrotliCompressionQuality reicht von 0 (am schnellsten, am schwächsten) bis 11 (am langsamsten, am stärksten). 5 ist der empfohlene Default für dynamische Inhalte. 4 ist eine gute Wahl auf stark belasteten Shared Servern.

Brotli auf Managed-WordPress-Hostern

Wie prüfe ich, ob Brotli aktiv ist?

1. Chrome DevTools öffnen, Network Tab, beliebiges Textasset anklicken. Unter Response Headers nach content-encoding: br suchen.
2. Im Terminal:

   curl -I -H "Accept-Encoding: br" https://example.de/style.css | grep -i content-encoding
   # Erwartet: content-encoding: br

3. https://tools.keycdn.com/brotli-test oder https://www.giftofspeed.com/gzip-test/ als Web-Test.
4. Lighthouse und PageSpeed Insights zeigen unter Diagnostics "Enable text compression" an, falls Brotli fehlt.

Statische Vorab-Komprimierung für maximale Einsparung

Bei Seiten mit überwiegend statischen Assets (CSS-Bundles, JS-Bundles aus dem Build) einmalig zur Build-Zeit mit Quality 11 vorkomprimieren und mit brotli_static on (nginx) oder über Apache Rewrite ausliefern:

# Im Build (CI/CD)
find ./dist -type f \( -name "*.html" -o -name "*.css" -o -name "*.js" -o -name "*.svg" \) \
  -exec brotli -q 11 -f {} \;

nginx liefert dann automatisch style.css.br aus, wenn der Client Accept-Encoding: br sendet. Das spart weitere 5 bis 10 Prozent, weil Quality 11 zur Anfragezeit unpraktisch ist.

Häufige Fehler

• Vary: Accept-Encoding vergessen: CDN- und Proxy-Caches müssen nach Encoding variieren, sonst bekommen Clients ohne Brotli Brotli-Inhalte.
• Bilder komprimieren: nur Textformate. Doppelte Komprimierung von JPEG/PNG verschwendet CPU und Bandbreite.
• Quality 11 zur Anfragezeit: nur Quality 4 bis 6 ist dynamisch sinnvoll. 11 ist für Build-Zeit.
• Brotli ohne TLS: die meisten Browser fragen Brotli nur über HTTPS an. Ohne TLS gibt es gzip.
• BREACH-Angriff: BREACH (2013) nutzt die Komprimierung von Geheimnissen wie CSRF-Tokens in HTML aus. Gegenmaßnahmen: keine Secrets im HTML, SameSite-Cookies, Response Length randomisieren. Gilt für gzip genauso.
• Alte Shared Hoster: manche alten Hoster haben Apache ohne mod_brotli. Cloudflare davor schalten.

Brotli vs. gzip vs. zstd

zstd kommt auf, ist 2025 aber noch begrenzt verbreitet. Brotli plus gzip-Fallback deckt alle Browser ab.

Wie hilft InspectWP bei Brotli?

InspectWP analysiert den Content-Encoding-Header jedes angefragten Assets und meldet, ob Brotli, gzip oder keine Komprimierung verwendet wird. Der Report markiert große unkomprimierte Textassets, bei denen Brotli Bandbreite sparen würde.