Brotli
Brotli ist ein modernes Komprimierungs-Verfahren für Web-Inhalte, das Text-Dateien wie HTML, CSS und JavaScript spürbar stärker verkleinert als das ältere Gzip – und damit Ladezeiten verkürzt sowie Übertragungs-Volumen reduziert.
Brotli ist Stand der Technik für die Komprimierung von Web-Inhalten. Es ergänzt das ältere Gzip, das weiterhin als Fallback für ältere Browser-Konfigurationen relevant bleibt. Beide Verfahren wirken auf die Server-Antwort und damit unmittelbar auf Core Web Vitals.
In einfachen Worten
Daten-Komprimierung verkleinert die Größe einer Datei, ohne ihren Inhalt zu verändern – ähnlich wie beim Komprimieren einer Datei in einem ZIP-Archiv. Bei der Web-Auslieferung werden Text-Inhalte wie HTML, CSS und JavaScript vor dem Versand vom Server komprimiert und im Browser unsichtbar wieder entpackt. Brotli ist ein modernes Komprimierungs-Verfahren, das diese Aufgabe für Text-Inhalte stärker erledigt als das ältere Gzip. Die genaue Ersparnis variiert je nach Inhalt; für typische Web-Dateien liegt der zusätzliche Spar-Effekt gegenüber Gzip im Bereich von rund 15 bis 25 Prozent. Browser unterstützen Brotli seit 2017 flächendeckend, sodass es heute ohne Risiko produktiv eingesetzt werden kann.
Wozu brauche ich das?
Schnellere Ladezeiten wirken unmittelbar auf Konvertierung und Suchmaschinen-Ranking. Für mobile Nutzer mit schwacher Verbindung kann eine spürbar kleinere Dateigröße den Unterschied zwischen Sichtbarkeit und Absprung ausmachen. Zusätzlich reduziert sich das übertragene Traffic-Volumen – relevant für Anbieter mit traffic-abhängigem Hosting-Modell oder hohem Mobil-Anteil bei begrenzten Daten-Volumen der Besucher.
Beispiel aus der Praxis
Eine Beispiel-Rechnung verdeutlicht die Größenordnung: Ein JavaScript-Bundle von rund 480 KB wird mit dem älteren Gzip auf etwa 142 KB komprimiert ausgeliefert, mit Brotli auf rund 108 KB – ein zusätzlicher Spar-Effekt von etwa einem Viertel gegenüber Gzip. Über einen Monat mit hohem Besucher-Volumen summiert sich das auf mehrere Gigabyte eingespartem Traffic, ohne dass eine Zeile Anwendungs-Code geändert wird. Wichtiger als die reine Bandbreiten-Ersparnis ist die Wirkung auf die Ladezeit: Auf einer durchschnittlichen mobilen Verbindung verkürzt sich der Largest Contentful Paint sichtbar – in günstigen Konstellationen reicht das, um die Core-Web-Vitals-Bewertung von „verbesserungswürdig" auf „gut" zu verschieben.
Wirtschaftlicher Nutzen
Die Aktivierung von Brotli erfordert bei modernen Hostern in der Regel keinen zusätzlichen Aufwand; viele Konfigurationen liefern bereits standardmäßig brotli-komprimierte Inhalte aus. Der wirtschaftliche Nutzen entsteht über zwei Wege: Eine schnellere Ladezeit wirkt direkt auf Konvertierung und Verweildauer, ein geringeres Übertragungs-Volumen reduziert die Hosting-Bandbreite. Bei Anbietern mit traffic-abhängiger Abrechnung sind die Einsparungen unmittelbar wirtschaftlich messbar; bei Pauschal-Hosting bleibt der Performance-Effekt der Haupt-Hebel.
Typische Fehler
- Brotli aktiviert, aber statische Dateien nicht vorab komprimiert – der Server komprimiert bei jeder Anfrage neu und belastet die CPU.
- Bereits komprimierte Dateien (JPEG, PNG, MP4) werden mit Brotli erneut bearbeitet – kostet Rechenzeit, bringt aber keine zusätzliche Ersparnis.
- Auslieferungs-Netz vor dem eigenen Server, das selbst nicht mit Brotli arbeitet – die Komprimierung verpufft auf der letzten Strecke.
- Keine Fallback-Strategie für Browser ohne Brotli-Unterstützung – ältere Clients erhalten unkomprimierte Dateien.
- Nach der Aktivierung nicht überprüft, ob die Auslieferung tatsächlich brotli-komprimiert läuft – die Konfiguration sieht aktiv aus, wirkt aber nicht.
Worauf achten?
- Server-Konfiguration muss Brotli unterstützen – gängige Web-Server und Auslieferungs-Netze bieten das, sofern aktiviert.
- Statische Dateien vorab komprimieren statt zur Laufzeit – spart Server-Ressourcen erheblich.
- Fallback auf Gzip für ältere Browser-Konfigurationen vorhalten – moderne Browser bevorzugen Brotli automatisch.
- Bereits komprimierte Dateien (Bilder, Videos, PDF-Dateien) vom Komprimierungs-Vorgang ausnehmen.
- Mit einem Werkzeug für die Performance-Bewertung verifizieren, dass die Auslieferung tatsächlich komprimiert erfolgt.
Häufig gestellte Fragen
Was unterscheidet Brotli von Gzip?
Beide sind Komprimierungs-Verfahren für Web-Inhalte. Brotli ist neuer und komprimiert Text-Inhalte (HTML, CSS, JavaScript) in der Regel stärker als Gzip – mit einer zusätzlichen Ersparnis im Bereich von rund 15 bis 25 Prozent. Bilder, Videos und bereits komprimierte Formate profitieren nicht.
Unterstützen alle Browser Brotli?
Die gängigen modernen Browser unterstützen Brotli seit 2017 flächendeckend. Für ältere Konfigurationen und einige spezielle Clients bleibt Gzip als Fallback relevant. Eine produktive Konfiguration liefert Brotli an Browser aus, die es unterstützen, und Gzip an den Rest.
Welche Dateien sollten komprimiert werden?
Alle Text-Inhalte: HTML, CSS, JavaScript, JSON, SVG. Nicht komprimieren sollten bereits komprimierte Formate wie JPEG, PNG, AVIF, MP4 oder PDF – sie sind in sich komprimiert, eine zusätzliche Bearbeitung kostet Rechenzeit, ohne nennenswert Volumen einzusparen.
Vorab oder zur Laufzeit komprimieren?
Statische Dateien sollten vorab komprimiert und gespeichert werden, sodass der Server sie ohne zusätzliche Bearbeitung ausliefert. Dynamische Inhalte werden zur Laufzeit komprimiert; hier ist eine moderate Komprimierungs-Stufe sinnvoll, um die CPU-Belastung im Rahmen zu halten.
Wirkt Brotli auf Core Web Vitals?
Indirekt ja. Eine kürzere Übertragungs-Dauer reduziert die Server-Antwortzeit (TTFB) und beschleunigt die Auslieferung der für den Largest Contentful Paint relevanten Inhalte. Der Effekt ist auf mobilen Verbindungen mit höherer Latenz besonders deutlich.