Brotli ist ein von Google entwickelter, quelloffener Kompressionsalgorithmus für die Übertragung von Webinhalten, der Text-Ressourcen wie HTML, CSS und JavaScript in der Regel stärker verkleinert als das ältere Gzip. Alle gängigen modernen Browser unterstützen Brotli über verschlüsselte Verbindungen (HTTPS).
Brotli presst die Dateien Ihrer Website vor dem Versand zusammen wie eine Vakuumverpackung: Der Inhalt bleibt derselbe, aber das Paket ist kleiner und schneller beim Empfänger. Der Browser packt die Daten anschließend automatisch wieder aus – Besucher merken davon nichts, außer kürzeren Ladezeiten.
Wozu brauche ich Brotli-Kompression?
Bevor ein Browser eine Seite anzeigen kann, müssen HTML, CSS und JavaScript übertragen werden. Kompression verkleinert diese textbasierten Dateien vor dem Versand erheblich. Brotli wurde 2015 von Google als freier Algorithmus veröffentlicht; bei der Vorstellung nannte Google rund 20 bis 26 Prozent bessere Kompressionsraten gegenüber dem Gzip-kompatiblen Vorgänger Zopfli (Google). In der Praxis sind Brotli-komprimierte Text-Dateien daher in der Regel spürbar kleiner als ihre Gzip-Pendants.
Kleinere Dateien bedeuten weniger Übertragungszeit – besonders in Mobilfunknetzen. Das wirkt sich direkt auf Kennzahlen wie den Largest Contentful Paint (LCP) aus und unterstützt damit gute Core Web Vitals. Gerade moderne Shop-Frontends liefern umfangreiche JavaScript- und CSS-Bündel aus; auch SVG-Grafiken, Webfont-Begleitdateien und JSON-Antworten von Schnittstellen zählen zu den komprimierbaren Inhalten. Da die Kompression nach einmaliger Konfiguration dauerhaft ohne weiteres Zutun wirkt, gehört sie zu den Maßnahmen mit einem besonders guten Verhältnis von Aufwand zu Nutzen.
Praxis-Relevanz für Shop- und Website-Betreiber
Brotli arbeitet vollständig im Hintergrund: Browser und Server handeln über den Accept-Encoding-Header aus, welches Verfahren verwendet wird. Unterstützt ein Client kein Brotli, fällt der Server automatisch auf Gzip zurück – das Risiko von Darstellungsproblemen ist daher gering. Besonders effizient ist statisches Vorkomprimieren: Dateien werden einmalig mit der höchsten Stufe komprimiert und dann fertig ausgeliefert, statt bei jeder Anfrage neu gepackt zu werden. Wie sich das in einem Shop-Projekt umsetzen lässt, zeigt unser Beitrag zur Brotli-Asset-Komprimierung für Shop-Performance.
Typische Fehler
- Nur HTML komprimieren: Auch CSS, JavaScript, SVG und JSON profitieren deutlich – Bilder und Videos dagegen nicht, sie sind bereits komprimiert.
- Höchste Stufe für dynamische Inhalte: Brotli-Stufe 11 ist für Live-Komprimierung sehr rechenintensiv; dynamische Antworten werden besser mit einer mittleren Stufe gepackt.
- HTTPS-Voraussetzung übersehen: Browser akzeptieren Brotli praktisch nur über verschlüsselte Verbindungen.
- Konfiguration nie geprüft: Ob Brotli tatsächlich aktiv ist, verrät der Response-Header Content-Encoding – manche Setups liefern unbemerkt weiterhin nur Gzip aus.
Worauf Sie achten sollten
Prüfen Sie zunächst, ob Ihr Hoster oder Ihr CDN Brotli unterstützt und ob statische Assets vorkomprimiert ausgeliefert werden. Bei professionellem Managed Hosting gehört eine korrekt eingerichtete Kompression in der Regel zum Standard. Sinnvoll ist, die vorkomprimierten Dateien bereits im Build- oder Deploy-Prozess zu erzeugen, sodass der Webserver sie nur noch ausliefern muss. Den messbaren Effekt kontrollieren Sie etwa mit Lighthouse oder den Browser-Entwicklertools – im Rahmen unserer PageSpeed-Optimierung zählt Kompression zu den Basismaßnahmen, ergänzt um eine passende Server-Konfiguration aus Hosting & Wartung.
Öffnen Sie die Entwicklertools (Netzwerk-Tab) und prüfen Sie bei einer CSS- oder JS-Datei den Response-Header: Steht dort "content-encoding: br", ist Brotli aktiv; bei "gzip" gibt es in der Regel noch Optimierungspotenzial.