Kompression aktiviert – warum kommen trotzdem unnötig viele Bytes an?
Brotli oder gzip im Hosting-Panel reicht nicht. Prüfen Sie Content-Encoding, Accept-Encoding, CDN-/Proxy-Verhalten, Cache-Varianten und die echte Transfergröße.
„Brotli ist aktiviert.“ Der Haken steht im Hosting-Panel – trotzdem überträgt die Startseite mehr Daten als erwartet.
HTTP-Kompression ist keine Eigenschaft Ihrer Quelldatei. Sie entsteht durch Content Negotiation entlang der echten Auslieferungskette: Browser, CDN, Reverse Proxy und Origin können alle beeinflussen, welche Variante am Ende ankommt.
Die bessere Frage lautet deshalb nicht: Ist Brotli eingeschaltet? Sondern: Welche Repräsentation bekommt ein echter Besucher tatsächlich?
Was der Browser aushandelt
Über Accept-Encoding nennt ein Client die Content Codings, die er versteht. Der Server oder ein vorgeschalteter Dienst kann beispielsweise mit gzip, br oder zstd antworten und die gewählte Kodierung in Content-Encoding kennzeichnen. RFC 9110 definiert diesen Mechanismus; MDN dokumentiert aktuell gzip, Brotli und Zstandard.
Textbasierte Antworten wie HTML, CSS, JavaScript, JSON, XML und SVG sind gute Kandidaten. web.dev empfiehlt deren Kompression und beschreibt Brotli als in der Regel effizienter als gzip für Webinhalte.
Aber ein aktivierter Algorithmus beweist noch nicht, dass jede relevante Antwort komprimiert beim Nutzer ankommt.
Red Flag 1: Nur HTML ist komprimiert
Prüfen Sie nicht nur /. Ein großer Teil des Traffics steckt oft in JavaScript-Chunks, CSS, JSON-APIs, GraphQL oder serverseitig gerenderten Routen.
Nehmen Sie eine Stichprobe aus HTML, größtem JavaScript-Bundle, zentralem CSS, typischer API-Antwort und SVG. Vergleichen Sie Transfergröße und Ressourcengröße und notieren Sie Content-Type, Content-Encoding und Cache-Status.
Wenn einzelne textbasierte Ressourcentypen unkomprimiert bleiben, sind häufig MIME-Type-Listen, Framework-Defaults oder Proxy-Regeln die Ursache.
Red Flag 2: Origin und Browser sehen unterschiedliche Verhandlungen
CDNs sind keine transparenten Kabel. Sie können Content Negotiation normalisieren und Antworten am Edge neu kodieren.
Cloudflare dokumentiert beispielsweise, dass sein CDN Accept-Encoding abhängig von den aktivierten Kompressionsverfahren gegenüber dem Origin anpassen und gecachte Assets passend zur Browser-Unterstützung rekomprimieren kann.
Das ist ein gutes Beispiel für eine allgemeine Audit-Regel: Testen Sie die öffentliche Domain über denselben Pfad wie Ihre Nutzer. Ein Direktaufruf des Origins hilft bei der Fehlersuche, beweist aber nicht, was nach CDN, WAF, Proxy und Cache ausgeliefert wird.
Red Flag 3: Cache und Content-Encoding passen nicht zusammen
Wenn dieselbe URL je nach Accept-Encoding unterschiedlich kodiert wird, ist Caching Teil der Funktion.
RFC 9110 definiert Vary als Signal dafür, welche Request-Felder die Auswahl der Repräsentation beeinflusst haben. CDN und Cache müssen komprimierte Varianten korrekt auseinanderhalten oder intern normalisieren.
Testen Sie deshalb mehrere Requests mit unterschiedlichen Accept-Encoding-Werten. Ändert sich Content-Encoding sinnvoll? Bleibt der Inhalt korrekt? Wird eine passende gecachte Variante geliefert? Verhalten sich ETags konsistent?
Ein Fehler muss die Seite nicht sofort zerstören. Es reicht schon, wenn bestimmte Clients dauerhaft eine größere Variante bekommen.
Red Flag 4: Bereits komprimierte Medien werden erneut bearbeitet
AVIF, WebP, JPEG, Video, ZIP und viele PDFs sind bereits stark komprimiert. Eine weitere HTTP-Kompression spart oft kaum Bytes, kostet aber CPU.
Noch problematischer ist echte Doppelkompression: Eine Schicht erhält bereits gzip- oder Brotli-kodierte Daten, verarbeitet sie erneut und Header und Body passen anschließend nicht mehr zusammen.
Darum sollte ein Check nicht nur nach Content-Encoding suchen, sondern prüfen, ob Kodierung, Payload und Ressourcentyp zusammenpassen.
Red Flag 5: Maximale Kompressionsstufe auf jeder dynamischen Antwort
Bei statischen Bundles können .br- oder .gz-Varianten einmal im Build erzeugt werden. Dynamisches HTML und JSON werden dagegen zur Laufzeit komprimiert.
Hier zählt nicht nur die kleinste Datei. Beobachten Sie auch Time to First Byte, CPU-Auslastung, Parallelität, Cache-Hit-Rate und Request-Häufigkeit. Eine extrem hohe Kompressionsstufe kann Bytes sparen und gleichzeitig den Server unnötig ausbremsen.
Die beste Einstellung ist diejenige, die End-to-End schneller und stabiler ist.
Brotli, gzip oder Zstandard?
gzip bleibt ein verbreiteter Fallback. Brotli ist in modernen Browsern etabliert. zstd wird ebenfalls in aktueller HTTP-/Browser-Dokumentation als Content Coding geführt und basiert auf dem in RFC 8878 beschriebenen Zstandard-Format.
Sie müssen nicht überall drei Verfahren erzwingen. Wichtiger sind saubere Negotiation und getestete Fallbacks:
- moderne Kodierung anbieten, wenn Client und Infrastruktur sie zuverlässig unterstützen,
- gzip als kompatiblen Fallback behalten,
identitydort akzeptieren, wo Kompression wenig Nutzen bringt,- die echte Client- und Infrastrukturmatrix testen.
Der 15-Minuten-Check
Öffnen Sie die Produktionsseite in einem frischen Browserprofil und laden Sie sie mit geöffnetem Network-Panel neu. Sortieren Sie nach übertragener Größe und prüfen Sie mehrere große textbasierte Antworten.
Kontrollieren Sie Content-Encoding, Content-Type, Transfergröße versus Ressourcengröße, Vary, Cache-Status und ob die Antwort wirklich aus dem Netzwerk kommt. Wiederholen Sie kontrollierte Requests mit gzip, Brotli und – sofern unterstützt – Zstandard sowie identity.
Das Ziel ist eine nachvollziehbare Matrix: Welche Ressourcentypen werden wo, womit und von welcher Infrastruktur-Schicht kodiert?
Was Website-Pflichtencheck prüfen würde
Ein Performance- und Hosting-Check betrachtet die öffentliche Auslieferungskette, nicht nur das Hosting-Panel. Geprüft werden können Accept-Encoding und Content-Encoding, Transfergrößen, Brotli-/gzip-/Zstandard-Fallbacks, unerwartet unkomprimierte MIME-Typen, CDN-/Proxy-/Origin-Verhalten, Cache-Varianten und Vary, ETags, statische Vor-Kompression, unnötige Medienkompression sowie CPU- und TTFB-Auswirkungen dynamischer Antworten.
Der relevante Befund lautet nicht „Brotli: an“.
Er lautet: Die wichtigen textbasierten Antworten erreichen echte Besucher zuverlässig in einer sinnvollen komprimierten Variante, ohne Cache- oder Serverkosten an anderer Stelle zu verschieben.
Wenn niemand im Team sagen kann, welche Schicht tatsächlich komprimiert, lohnt sich eine Messung der echten Kette – bevor Sie an Bundles sparen, während unterwegs weiterhin unnötig viele Bytes ausgeliefert werden.