Brotli oder Gzip für Textressourcen aktivieren

Cookbook: Ziel und Ergebnis

HTML, CSS, JavaScript, JSON und SVG werden einmal an der geeigneten Server-/CDN-Schicht komprimiert. Bilder, Video, ZIP und PDF bleiben gewöhnlich unverändert.

Rezept: Schritt für Schritt

1. Mit Browser/Headers prüfen, ob Host oder CDN bereits br/gzip liefert.
2. MIME-Typen für Text definieren; Brotli mit Gzip-Fallback konfigurieren. CDN und Ursprung nicht konkurrierend doppelt bearbeiten lassen.
3. Mit moderater Stufe beginnen: dynamische Antworten brauchen niedrige CPU-Kosten, statische Assets können bei Build/Cache stärker komprimiert werden.
4. Vary: Accept-Encoding, Content-Length/Transfer und Cache-Key testen.

Rechenweg oder Entscheidungsregel

Ersparnis (%) = (unkomprimierte Bytes − übertragene Bytes) / unkomprimierte Bytes × 100\nCPU-Kosten je Stunde = Kompressionszeit × Cache-Misses pro Stunde

Praxisbeispiel

CSS 240 kB → Brotli 42 kB (82,5 % weniger). JPEG 180 kB → erneut „komprimiert“ 179 kB: kein sinnvoller Gewinn. Wird das CSS am Edge lange gecacht, ist höhere statische Stufe vertretbarer als bei 50 dynamischen HTML-Antworten/s.

Prüfen, ob es funktioniert

• Kompatibler Client erhält Content-Encoding: br, Fallback gzip.
• Keine beschädigten Downloads, falschen Content-Length-Header oder Cache-Vermischung.
• Übertragene Bytes sinken, TTFB/CPU unter Last bleiben stabil.

Rollback

Zuletzt aktivierte Kompressionsschicht deaktivieren, alte Server-/CDN-Regeln wiederherstellen und Cache variantenübergreifend purgen. Konfiguration vor Reload testen.

Empfehlung

Aktiviere Brotli, wenn die Server-/CDN-Schicht es unterstützt, mit Gzip-Fallback. Wähle moderate Kompressionsstufen: maximale Kompression kostet CPU und bringt bei dynamischen Antworten oft nur wenig zusätzliche Bytes.

Apache

mod_brotli stellt den Brotli-Ausgabefilter bereit, mod_deflate DEFLATE/Gzip. Konfiguration sollte nach MIME-Typ erfolgen und den Vary: Accept-Encoding-Umgang respektieren. Auf Managed Hosting oder LiteSpeed sind entsprechende Funktionen häufig bereits aktiv.

Nicht doppelt komprimieren

CDN, Reverse Proxy und Ursprung müssen abgestimmt sein. JPEG, WebP, AVIF, MP4, ZIP und PDF sind schon komprimiert; erneute Kompression verbraucht CPU mit geringem Nutzen.

Erfolgskontrolle

Mit Antwortheadern und übertragenen Bytes prüfen, ob kompatible Clients br oder gzip erhalten. Unkomprimierte Größe, CPU und TTFB unter Last vergleichen.

Quellen und Prüfstand

• Apache: mod_brotli
• Apache: mod_deflate

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.