Brotli & Asset-Komprimierung: Shops schneller ausliefern

Jede ausgelieferte Byte kostet Zeit, und Zeit kostet Umsatz. Bevor HTML, CSS und JavaScript Ihres Online-Shops im Browser ankommen, lassen sie sich auf einen Bruchteil ihrer ursprünglichen Größe schrumpfen, vorausgesetzt, der Server komprimiert sauber. Genau hier setzt Brotli an, der modernere Nachfolger von Gzip: Brotli komprimiert HTML rund 21%, CSS 17% und JavaScript 14% stärker als Gzip (DebugBear). Trotzdem liefern nach wie vor 61% der Origin-Server ihre Antworten in Gzip aus, nur 39% in Brotli (HTTP Archive). Und 56% aller HTML-Antworten sowie 18% der JavaScript- und CSS-Ressourcen werden überhaupt nicht komprimiert (HTTP Archive). Dieser Leitfaden zeigt, wie Brotli und Gzip funktionieren, wie Sie Textassets durch Minifizierung und korrekte Serverkonfiguration ausliefern und warum die Wahl der richtigen Kompressionsstufe über Ladezeit und Performance entscheidet.

Warum Asset-Komprimierung über Umsatz entscheidet

Textbasierte Ressourcen sind komprimierbar wie kaum etwas sonst. Eine durchschnittliche Startseite transportiert heute 22 kB HTML, 82 kB CSS und 697 kB JavaScript (jeweils Median, HTTP Archive 2025), und gerade die letzte Zahl wächst seit Jahren. Die mediane Seite wiegt inzwischen 2,86 MB auf dem Desktop und 2,56 MB mobil (HTTP Archive 2025). Ein großer Teil davon ist Text, der sich aggressiv verkleinern lässt, ohne dass ein einziges Pixel verloren geht. Bilder dominieren das Gewicht zwar mit rund 1.059 kB pro Startseite (HTTP Archive), doch sie sind bereits binär komprimiert. Die echte, oft brachliegende Reserve liegt im Textanteil.

Der Geschäftswert ist direkt messbar. Laut der Studie Milliseconds Make Millions von Google und Deloitte steigert jede Verbesserung der Ladezeit um 0,1 Sekunden die Conversions im Handel um 8,4% und den durchschnittlichen Bestellwert um 9,2% (Google/Deloitte). Amazon errechnete, dass jede zusätzliche 100 ms Latenz rund 1% Umsatz kostet (Conductor). Eine Analyse von über 100 Millionen Seitenaufrufen ergab, dass Seiten mit einer Sekunde Ladezeit zu 3,05% konvertieren, bei zwei Sekunden nur noch zu 1,68% und bei fünf Sekunden zu 1,08% (Portent). Komprimierung ist einer der wenigen Hebel, die sich ohne Designänderung und ohne Risiko für alle Seiten gleichzeitig ziehen lassen.

Der Charme der Asset-Komprimierung liegt in ihrer Reichweite. Anders als die Optimierung eines einzelnen Templates wirkt eine korrekte Serverkonfiguration auf jede HTML-Seite, jede Stylesheet- und jede Skriptdatei gleichzeitig. Sie ist damit ein klassischer Quick Win: hohe Wirkung bei geringem Aufwand und ohne sichtbare Änderung an der Oberfläche. Gerade für Online-Shops, deren Seitengewicht mit jedem neuen Feature, jedem Tracking-Skript und jeder Drittanbieter-Einbindung wächst, ist das ein nachhaltiger Hebel gegen den schleichenden Performance-Verfall. Hinzu kommt ein oft übersehener Nebeneffekt: Weniger übertragene Bytes bedeuten auch geringere Bandbreitenkosten und entlasten mobile Datenvolumina der Nutzenden, was die wahrgenommene Qualität eines Shops gerade unterwegs spürbar steigert.

Wie HTTP-Kompression funktioniert

HTTP-Kompression ist eine Aushandlung zwischen Browser und Server. Der Browser sendet im Request einen Accept-Encoding-Header, der die unterstützten Verfahren auflistet, etwa gzip, br, zstd. Der Server wählt daraus ein Verfahren, komprimiert die Antwort und kennzeichnet sie mit Content-Encoding. Der Browser dekomprimiert sie, bevor er sie verarbeitet. Für die Nutzenden ist der Vorgang unsichtbar, nur die Ladezeit verkürzt sich. Diese Aushandlung passiert bei jedem einzelnen Request, weshalb eine konsistente Serverkonfiguration so wichtig ist: Es genügt nicht, dass HTML komprimiert ankommt, wenn das nachgeladene JavaScript unkomprimiert bleibt.

Wichtig ist eine Eigenheit moderner Browser: Chrome, Firefox, Edge und Safari kündigen Accept-Encoding: br ausschließlich über HTTPS an. Bei reinem HTTP fallen sie auf Gzip zurück, selbst wenn beide Seiten Brotli beherrschen. Brotli ist damit faktisch an TLS gekoppelt, was in der Praxis kein Problem ist, da ohnehin nahezu jeder Shop über HTTPS läuft. Rund 97% der Nutzenden surfen mit einem Browser, der Brotli unterstützt (caniuse); Brotli wird seit Chrome 50, Firefox 44, Edge 15 und Safari 11 verstanden. Damit gibt es kaum noch ein Argument, Brotli aus Kompatibilitätsgründen zurückzuhalten, solange Gzip als Rückfallebene konfiguriert bleibt.

Zu unterscheiden ist außerdem, ob komprimiert wird, während eine Anfrage bearbeitet wird, oder ob bereits fertig komprimierte Dateien ausgeliefert werden. Bei der On-the-fly-Kompression entsteht die komprimierte Antwort pro Request neu, was CPU-Zeit kostet. Bei der Precompression liegt die Datei bereits in einer .br- oder .gz-Variante vor und wird nur noch herausgereicht. Diese Unterscheidung ist der Schlüssel zur richtigen Wahl der Kompressionsstufe, auf die der Abschnitt zu den Stufen genauer eingeht.

Brotli vs. Gzip: der direkte Vergleich

Gzip basiert auf dem DEFLATE-Algorithmus und ist seit den 1990er-Jahren etabliert. Brotli wurde 2015 von Google entwickelt und bringt einen entscheidenden Vorteil mit: ein vordefiniertes Wörterbuch aus über 13.000 häufigen Zeichenketten des Webs, darunter typische HTML-Tags, CSS-Eigenschaften und JavaScript-Schlüsselwörter. Dadurch erkennt Brotli wiederkehrende Muster in Webcode besser und erzielt höhere Kompressionsraten, gerade bei kleinen Textdateien, bei denen Gzip ohne Vorwissen schlechter abschneidet, weil sich noch keine statistischen Muster aufgebaut haben.

In Akamais Benchmark lag die mediane Einsparung bei 82% mit Brotli gegenüber 78% mit Gzip (DebugBear). Pro Dateityp ist Brotli rund 21% besser bei HTML, 17% bei CSS und 14% bei JavaScript (DebugBear). In einem realen Test komprimierte DebugBear eine 173-kB-JavaScript-Bibliothek mit Gzip auf 61 kB und mit Brotli auf 52 kB, also rund 15% kleiner als Gzip (DebugBear). Der Unterschied klingt klein, summiert sich aber über Hunderte von Requests pro Seite und über Millionen von Seitenaufrufen. Bei einer mittelgroßen Shop-Startseite mit dem genannten Medien-Mix kann der Wechsel von Gzip auf Brotli ohne weitere Maßnahmen mehrere Dutzend Kilobyte pro Seitenaufruf sparen.

Am Horizont steht bereits Zstandard (zstd), das von CDNs zunehmend genutzt wird: Sie liefern inzwischen 12% der Requests in zstd aus, 46% in Brotli und 42% in Gzip (HTTP Archive). zstd bietet ein ähnliches Kompressionsniveau wie Brotli bei höherer Geschwindigkeit und ist damit besonders für dynamische Inhalte interessant. Origin-Server hinken dieser Entwicklung jedoch hinterher: Sie liefern weiterhin 61% in Gzip und nur 39% in Brotli aus (HTTP Archive). Für die meisten Shops bleibt daher die Kombination aus Brotli für statische Assets und Gzip als Fallback der pragmatische Standard, während zstd eine Option für die Zukunft ist.

Kompressionsstufen richtig wählen

Die Stufe entscheidet über das Verhältnis von Kompressionsrate zu Rechenzeit. Brotli kennt die Stufen 0 bis 11, Gzip die Stufen 1 bis 9. Die höchsten Brotli-Stufen erzielen die kleinsten Dateien, sind aber teuer: In Cloudflares Benchmark mit dynamischen Webinhalten komprimierte Brotli auf Stufe 9 rund 8,8 MB/s, auf Stufe 10 jedoch nur noch etwa 0,5 MB/s, also rund siebzehnmal langsamer (Cloudflare). Stufe 4 erreichte dagegen rund 51 MB/s und blieb damit schneller als zlib auf Stufe 8 und 9 bei vergleichbarer Kompressionsrate (Cloudflare). Entscheidend ist daher die Unterscheidung zwischen statischen und dynamischen Inhalten, denn nur bei statischen Assets fällt die Rechenzeit ein einziges Mal an statt bei jedem Seitenaufruf erneut.

Eine bewährte Strategie ist Precompression: Beim Build entstehen neben jeder .js- und .css-Datei direkt eine .br- und eine .gz-Variante. Der Webserver liefert dann die vorbereitete Datei aus, ohne pro Request neu zu komprimieren. So erhalten Sie die maximale Brotli-Ratio ohne jede Laufzeitkosten, ein Prinzip, das auch unser Hosting für statische Shop-Assets nutzt. Für dynamische Antworten wie Kategorie- und Detailseiten bleibt die On-the-fly-Kompression auf moderater Stufe der richtige Weg, weil das HTML dort von Sortiment, Login-Status und Warenkorb abhängt und sich nicht sinnvoll vorab erzeugen lässt.

Der Effekt der Stufenwahl ist messbar, aber nicht linear. Zwischen Brotli 4 und Brotli 11 liegen bei typischem Webcode oft nur wenige Prozentpunkte zusätzliche Einsparung, während die Rechenzeit um eine Größenordnung steigt. Genau deshalb ist die hohe Stufe nur dort sinnvoll, wo sie kostenlos ist, nämlich bei statischen, vorab komprimierten Dateien. Wer dynamisches HTML versehentlich auf Stufe 11 komprimiert, riskiert höhere Antwortzeiten unter Last, also genau das Gegenteil des gewünschten Effekts.

# Statische, vorkomprimierte Brotli-Dateien ausliefern
brotli_static on;

# On-the-fly Brotli für dynamisches HTML (moderate Stufe)
brotli on;
brotli_comp_level 5;
brotli_types text/html text/css application/javascript application/json image/svg+xml application/xml font/ttf;

# Gzip als Fallback für ältere Clients (br nur über HTTPS)
gzip on;
gzip_comp_level 6;
gzip_vary on;
gzip_types text/html text/css application/javascript application/json image/svg+xml application/xml;

Minifizierung: weniger Bytes vor der Kompression

Kompression und Minifizierung sind zwei verschiedene Schritte, die sich ergänzen. Minifizierung entfernt vor der Auslieferung alles Überflüssige aus dem Quelltext: Kommentare, Zeilenumbrüche, überflüssige Leerzeichen und teils auch lange Variablennamen. Das Ergebnis bleibt funktional identisch, ist aber deutlich kleiner. Typischerweise reduziert Minifizierung JavaScript um 30 bis 60% und CSS um 20 bis 40% (DebugBear). Bei modernen Build-Pipelines geschieht das automatisiert, oft kombiniert mit Tree Shaking, das ungenutzten Code vollständig entfernt.

Der eigentliche Effekt entsteht im Zusammenspiel. Ein unminifiziertes 88-kB-File schrumpft durch reine Minifizierung auf 26,5 kB, ein Minus von 70% (DebugBear). Kombiniert man Minifizierung mit Brotli, erreicht man insgesamt rund 90% Größenreduktion (DebugBear). Wichtig ist die Reihenfolge: erst minifizieren, dann komprimieren, denn auf bereits minifiziertem Code arbeitet der Kompressor effizienter, weil weniger redundante Struktur übrig bleibt, die er ohnehin entfernen müsste.

• JavaScript minifizieren - Kommentare und Whitespace entfernen, Variablen kürzen, Dead Code eliminieren (Tree Shaking) im Build-Prozess
• CSS minifizieren - ungenutzte Regeln entfernen, Whitespace reduzieren, Kurzschreibweisen nutzen
• HTML minifizieren - bei statischen Seiten Leerzeichen und Kommentare entfernen, bei dynamischen vorsichtig testen
• SVG optimieren - Metadaten und unnötige Pfaddaten entfernen, da SVG als Text komprimiert wird
• JSON-APIs schlank halten - keine Pretty-Print-Formatierung in Produktiv-Antworten ausliefern
• Code-Splitting nutzen - nur das JavaScript laden, das die jeweilige Seite tatsächlich braucht

Serverkonfiguration und typische Fehler

Trotz der klaren Vorteile bleibt viel Potenzial ungenutzt. 62% der Websites bestehen den Lighthouse-Audit Enable text compression, aber rund 21% liegen unter einem Score von 40 (HTTP Archive). Konkret werden 56% der HTML-Antworten sowie 18% der JavaScript- und CSS-Ressourcen gar nicht komprimiert (HTTP Archive). Bei den betroffenen Seiten könnten 82% ihr Seitengewicht um bis zu 1 MB senken (HTTP Archive), allein durch korrekt konfigurierte Kompression. Das ist eine erhebliche Reserve, die ohne neue Inhalte, ohne Redesign und ohne Risiko für die Funktion gehoben werden kann.

Die häufigsten Ursachen sind technischer Natur und schnell behoben. Oft fehlt die Aktivierung des Brotli-Moduls, oder die Liste der komprimierten MIME-Typen ist unvollständig, sodass etwa JSON-APIs oder SVGs unkomprimiert ausgeliefert werden. Ein klassischer Fehler ist auch ein vorgelagerter Reverse-Proxy oder eine Web Application Firewall, die komprimierte Antworten dekomprimiert und unkomprimiert weiterreicht. In solchen Fällen ist die Kompression am Origin korrekt konfiguriert, kommt aber beim Browser nicht an, ein Problem, das sich nur durch Prüfung des tatsächlich ausgelieferten Headers aufdecken lässt.

1. Brotli- und Gzip-Modul aktivieren und beide parallel konfigurieren, Brotli zuerst, Gzip als Fallback
2. MIME-Typen vollständig listen - HTML, CSS, JS, JSON, SVG und XML einschließen
3. Vary: Accept-Encoding setzen, damit Caches und CDNs die richtige Variante ausliefern
4. Statische Assets vorkomprimieren (.br/.gz) und mit brotli_static/gzip_static ausliefern
5. Stufen trennen - Brotli 11 für statisch, Brotli 4-5 bzw. Gzip 6 für dynamisch
6. Ergebnis verifizieren mit Lighthouse, WebPageTest oder dem Content-Encoding-Header in den DevTools

Komprimierung im Performance-Gesamtbild

Kompression wirkt am stärksten als Teil einer durchgängigen Performance-Strategie. Sie reduziert die Übertragungszeit, also den Zeitraum zwischen Anfrage und vollständigem Empfang einer Ressource. Damit zahlt sie direkt auf den Largest Contentful Paint und auf die Zeit bis zur Interaktivität ein, beides zentrale Core Web Vitals. Besonders auf mobilen Verbindungen mit begrenzter Bandbreite ist der Effekt spürbar, denn dort macht jede eingesparte Kilobyte einen messbaren Unterschied in der wahrgenommenen Ladezeit.

Kompression ersetzt jedoch keine der anderen Optimierungsschichten, sie ergänzt sie. Sinnvoll kombiniert wird sie mit serverseitigem Caching wie Redis, das die Antwortzeit des Backends senkt, mit moderner Protokoll-Optimierung durch HTTP/3 und QUIC, die den Verbindungsaufbau beschleunigt, und mit einer ganzheitlichen Shopware-Performance-Optimierung. Auslagern lassen sich Rechenlasten zudem an Serverless Edge Functions, während eine saubere Webhook-Architektur datenintensive Prozesse entkoppelt und so die Antwortzeit der eigentlichen Shop-Seiten stabil hält.

Für Online-Shops mit wachsendem Sortiment, vielen Kampagnen und steigendem JavaScript-Anteil ist saubere Asset-Komprimierung damit kein optionaler Feinschliff, sondern Grundausstattung. Sie ist die Basisschicht, auf der alle weiteren Optimierungen aufbauen, und sie kostet nach der einmaligen Einrichtung praktisch nichts. Als Agentur aus Niedersachsen mit Fokus auf Hosting und Wartung konfigurieren wir Brotli und Gzip serverseitig, etablieren Precompression im Build und verzahnen die Kompression mit Caching, Protokoll- und Frontend-Optimierung, damit jede ausgelieferte Byte zählt.

Häufig gestellte Fragen zu Brotli und Asset-Komprimierung