Gzip vs Brotli: HTTP Compression Methoden im Vergleich für Hosting

Gzip vs Brotli entscheidet im Hosting über Ladezeit, Dateigröße und CPU-Budget. In diesem Vergleich zeige ich praxisnah, wann ich welche HTTP-Kompressionsmethode aktiviere, welche Level ich nutze und wie sich das direkt auf Core Web Vitals und Kosten auswirkt.

Zentrale Punkte

• Kompressionsrate: Brotli spart 15–25 % mehr Bytes als Gzip, vor allem bei statischen Assets.
• Geschwindigkeit: Gzip komprimiert schneller on-the-fly, Brotli dekomprimiert im Browser oft schneller.
• Statisch/Dynamisch: Brotli für vorab komprimierte Dateien, Gzip für dynamische Antworten.
• Fallback: Brotli priorisieren, Gzip als kompatible Rückfallebene nutzen.
• SEO/UX: Kleinere Dateien senken Latenz, stärken Core Web Vitals und Rankings.

Warum HTTP‑Kompression Hosting-Erfolg treibt

Ich setze auf HTTP‑Kompression, weil sie jede Antwort leichter macht und damit weniger Zeit über das Netzwerk braucht. Kürzere Transfers verbessern die Interaktivität, drücken die TTFB-Anmutung und stabilisieren die Ladeabfolge. Gerade auf mobilen Verbindungen zählt jedes Kilobyte, und Kompression senkt diesen Fußabdruck spürbar. Zusätzlich spare ich Bandbreite auf dem Server, was bei viel Traffic echte Kosten reduziert. Wer Performance priorisiert, aktiviert daher konsequent die richtige Kompressionsmethode an allen Kanten: Server, CDN und Edge.

Gzip: Stärken, Level und Einsatzfelder

Gzip basiert auf DEFLATE und liefert in der Praxis 50–70 % kleinere Dateien bei sehr kurzer Kompressionszeit. Für dynamische HTML-Antworten wähle ich häufig Level 6, weil es ein gutes Verhältnis aus Geschwindigkeit und Einsparung bietet. Bei hohem Durchsatz schont das die CPU und hält die Latenz niedrig. Für stark dynamische Inhalte setze ich je nach Last auch Level 4–5 ein, um die On-the-fly-Zeit weiter zu senken. Als Fallback bleibt Gzip unverzichtbar, da es praktisch überall funktioniert.

Brotli: Vorteile, Level und Grenzen

Brotli nutzt LZ77, Huffman-Codierung und ein rund 120‑KB‑Wörterbuch mit häufigen Webmustern. Dadurch schrumpfen HTML, CSS und JavaScript im Schnitt deutlich stärker als bei Gzip, vor allem bei hohen Leveln. Ich sehe typischerweise 15–25 % weniger Bytes im Vergleich zu Gzip, was die Übertragungszeit klar drückt. Die Dekompression im Browser läuft sehr flott, was die Render-Pipeline entlastet. Für on-the-fly nutze ich moderate Level (z. B. 4–6), für vorab komprimierte Assets ziehe ich Level 8–11 in Build‑Prozessen vor.

Gzip vs Brotli im Hosting-Alltag

Ich entscheide nach Inhalt und Lastprofil: dynamisch eher Gzip, statisch eher Brotli. Für CSS/JS, Fonts und große HTML-Templates lohnt sich die Vorab‑Komprimierung mit Brotli spürbar. Bei Content, der pro Anfrage variiert, zählt Kompressionszeit, also punktet Gzip. Moderne Stacks fahren beides parallel: Brotli priorisiert, Gzip als Fallback. Wer tiefer einsteigen will, findet in diesem detaillierten Vergleich weitere Kennzahlen und konkrete Anwendungsfälle.

Vergleichstabelle: Kennzahlen und Support

Die folgende Tabelle ordnet die wichtigsten Kriterien für Hosting-Setups ein und zeigt, wann welches Verfahren punktet. Sie hilft mir, Entscheidungen nach Dateityp, Last und Kompatibilität zu treffen. Ich bewerte Kompressionsrate, Serveraufwand, Browser-Support und Wirkung auf die wahrgenommene Geschwindigkeit. So lege ich fest, ob ich on-the-fly oder als Build‑Schritt komprimiere. Für große statische Bundles skaliert die Vorab‑Komprimierung mit Brotli besonders gut.

Kriterium	Gzip	Brotli	Wirkung in der Praxis
Kompressionsrate	ca. 50–70 % kleiner	typisch 15–25 % kleiner als Gzip	Weniger Bytes, schnellere Übertragung
Kompressionsgeschwindigkeit	Schnell, vor allem bei Level 1–6	Langsamer bei hohen Leveln (8–11)	Gzip für dynamische Antworten vorteilhaft
Dekomprimierung	Schnell	Oft noch schneller	Render-Start wirkt flüssiger
Browser-Support	Nahezu vollständig	Sehr breit bei modernen Browsern	Gzip als kompatible Rückfallebene
CPU-Verbrauch	Gering bei niedrigen Leveln	Höher bei hohen Leveln	Build‑Zeit vs. Laufzeit sauber abwägen

Ich addiere zu diesen Kennzahlen noch TTFB und Bandbreite als Entscheidungsfaktoren. Bei knappen CPU‑Reserven wähle ich niedrigere Level für Live‑Kompression. In CI/CD‑Pipelines packe ich statische Dateien mit hohen Brotli‑Leveln vor. So kombiniere ich kurze Antwortzeiten mit sehr kleinen Assets. Die Mischung liefert konsistent bessere Ladeerlebnisse.

Konfigurationspraxis mit Nginx und Apache

Ich aktiviere Brotli und Gzip über Module, stelle sinnvolle MIMEs ein und reguliere Level je nach Serverlast. Für Nginx nutze ich getrennte Einstellungen für on-the-fly und für vorab komprimierte Dateien mit .br/.gz‑Endungen. In Apache konfiguriere ich über Module wie mod_brotli und mod_deflate sowie über .htaccess Regeln für Caching und Vary‑Header. Wichtig bleibt die Pre‑Komprimierung im Build, damit der Server nur ausliefert und nicht ständig packen muss. Wer eine Schritt‑für‑Schritt-Anleitung sucht, startet mit dieser HTTP-Compression Konfiguration.

Strategien: Dynamisch vs. Statisch

Bei dynamischen Seiten zählt die Zeit bis zur ersten Antwort, daher komprimiere ich schnell mit Gzip auf Level 4–6. Für statische Ressourcen setze ich Brotli in hohen Leveln ein und speichere die Artefakte bereits im Dateisystem oder im CDN. Diese Strategie entlastet die CPU zur Laufzeit und reduziert die Bytes maximal. Ich stelle sicher, dass der Server anhand von Accept‑Encoding die passende Variante wählt. So bediene ich moderne Browser mit Brotli und ältere Clients zuverlässig mit Gzip.

SEO‑Effekte und Core Web Vitals

Kleinere Dateien verringern die Latenz und bringen Inhalte schneller auf die Fläche. Ich registriere häufig eine bessere First Contentful Paint und stabilere Largest Contentful Paint. Auf Mobilgeräten mit schwacher Verbindung macht sich das deutlich bemerkbar. Zudem spare ich Datentransfer, was bei großem Traffic messbare Kosten senkt. Diese Vorteile zahlen in Summe auf Sichtbarkeit, Conversion und Nutzerzufriedenheit ein.

Monitoring und Tuning: Messbar schneller

Ich überprüfe den Effekt von Kompression mit Lab‑ und Feldmessungen. Tools wie PageSpeed oder RUM‑Daten zeigen mir FCP, LCP, TTFB und Transfergrößen vor und nach Anpassungen. Bei hoher CPU‑Last senke ich Level, bei zu großen Dateien erhöhe ich sie in Build‑Schritten. Caching‑Header wie Cache‑Control und ETag verhindern unnötiges Neu‑Packen und stärken die Effizienz. Wichtig bleibt, regelmäßig zu testen, weil Traffic‑Muster und Asset‑Größen sich ändern.

Praxis‑Setup: Hybrid‑Ansatz für WordPress & Co.

Für WordPress wähle ich häufig Brotli für CSS/JS/Fonts und Gzip für PHP‑generierte HTML‑Seiten. CDNs liefern die vorab komprimierten Dateien aus, während der Origin dynamische Antworten schnell packt. Ich achte auf Vary‑Header, um Caches sauber zu trennen, und auf identische ETags für .br/.gz‑Varianten. Wer feiner abstimmen will, findet hier Details zu Kompressionslevel und CPU-Last. So bleibt die Render‑Kette leicht, die Serverlast kalkulierbar und die Kompatibilität hoch.

Welche Dateien ich nicht komprimiere

Nicht alles profitiert von HTTP‑Kompression. Einige Formate sind bereits intern optimal gepackt oder benötigen Byte‑Range‑Anfragen, bei denen zusätzliche Kompression eher stört. Ich lasse daher in der Regel unkomprimiert:

• Bilder: JPEG/JPG, PNG, GIF, WebP, AVIF (bereits stark komprimiert)
• Video/Audio: MP4, WebM, MOV, MP3, OGG, AAC
• Archive/Container: ZIP, 7z, RAR, ISO, PDF (oft komprimiert), DMG
• Schriftformate: WOFF2 (nutzt intern Brotli), WOFF teils komprimierbar, TTF/OTF je nach Setup vorab packen
• Binärdownloads, die häufig per Range geladen werden

Komprimiert werden sollten vor allem Textformate: HTML, CSS, JavaScript, JSON, XML, SVG, Web‑Manifeste und sitemaps. SVG als XML profitiert stark; WOFF2 hingegen nicht – hier spare ich mir Content‑Encoding.

HTTP/2/HTTP/3 und TLS: Zusammenspiel mit Kompression

HTTP/2 und HTTP/3 beschleunigen Transport und Multiplexing, ersetzen aber nicht die Nutzlast‑Kompression. Header‑Kompression (HPACK/QPACK) kümmert sich nur um Header, nicht um den Body. Weniger Bytes im Body bleiben daher ein deutlicher Vorteil. Wichtig: Brotli wird von Browsern in der Praxis überwiegend nur über HTTPS angeboten. Wer noch reines HTTP fährt, sieht in der Regel nur Gzip als Option. In TLS‑Terminationsketten achte ich darauf, dass Kompression am Edge nah am Client passiert, um Latenz und Egress zu minimieren.

Varianten-Handling: Accept‑Encoding, Caches und ETags

Saubere Content‑Negotiation entscheidet über Cache‑Trefferquoten. Ich setze konsequent den Vary‑Header auf Accept‑Encoding, damit Proxies und CDNs Varianten korrekt trennen. Bei vorab gepackten Assets halte ich Last‑Modified gleich und vergebe getrennte ETags pro Repräsentation (.br/.gz/identisch). CDNs sollten den Cache‑Key um Accept‑Encoding erweitern. Wichtig ist, Doppel‑Kompression auszuschließen: Ist eine Datei bereits als .br vorhanden, darf der Server sie nicht erneut gzippen. Bei Byte‑Ranges (z. B. Video) liefere ich die unkomprimierte Variante, da sich Ranges auf die kodierte Repräsentation beziehen und Caches sonst inkonsistent werden können.

Feintuning: Schwellenwerte, Level und CPU‑Budget

Ich arbeite mit Mindestgrößen, damit Kleinstdateien nicht unnötig verpackt werden (typisch 1–2 KB Schwelle). Für dynamische Antworten wähle ich Gzip Level 4–6 oder Brotli 4–6. Für Build‑Artefakte bevorzuge ich Brotli 9–11, sofern die Build‑Zeit vertretbar bleibt. Faustregeln, die sich bewährt haben:

• Kleine HTML‑Snippets und API‑Antworten: Gzip 4–5 oder Brotli 4–5
• Große Bundles (JS/CSS > 50 KB): Brotli 8–11 vorab
• Sehr hohes Live‑Traffic‑Volumen: Level senken, um Warteschlangen und TTFB‑Spitzen zu vermeiden

Wichtig ist, CPU‑Peaks im Blick zu behalten. Wenn die Kompressionspipeline staut, verschlechtert sich die wahrgenommene TTFB. Dann senke ich die Live‑Level und verlagere Einsparungen in den Build.

Sicherheit: Kompression ohne Risiko

Transport‑Kompression über TLS ist sicher, aber es gibt seit Jahren bekannte Seitenkanal‑Angriffe auf inhaltliche Kompression (Stichwort BREACH). Praktisch heißt das: Seiten, die geheime Token enthalten und gleichzeitig Benutzereingaben reflektieren, komprimiere ich vorsichtig oder gar nicht. Ich trenne z. B. Formularseiten mit CSRF‑Token von reflektierenden Parametern, minimiere Echo‑Inhalte oder deaktiviere Kompression auf diesen Endpunkten. Statische Assets sind hiervon nicht betroffen – die komprimiere ich weiterhin aggressiv.

CDN, Serverless und Objektspeicher: Zuständigkeiten klären

In CDN‑Setups lasse ich die Edge‑Kompression aktiv und lade zusätzlich vorab komprimierte Artefakte hoch. Wichtig sind korrekte Metadaten: Content‑Type und Content‑Encoding müssen stimmen, sonst serven CDNs falsche Varianten oder komprimieren doppelt. In Serverless‑Funktionen halte ich die Live‑Level konservativ (Gzip 4–5 oder Brotli 4), um Kaltstarts und CPU‑Spitzen zu vermeiden. Für Objektspeicher (z. B. als Origin) speichere ich .br/.gz neben der Rohdatei; das CDN wählt anhand von Accept‑Encoding. Die Build‑Pipeline erzeugt alle Varianten deterministisch, damit ETags stabil bleiben.

Kontrolle und Debugging: So prüfe ich den Effekt

Ich validiere die Auslieferung regelmäßig mit Browser‑DevTools: In der Netzwerkansicht kontrolliere ich Content‑Encoding, gesendete Bytes und ob der Server aus dem Cache antwortet. Zusätzlich prüfe ich, ob die Vary‑Header sitzen und ob Brotli wirklich an HTTPS‑Clients geliefert wird. Für API‑Antworten vergleiche ich komprimierte vs. unkomprimierte Größen und beobachte TTFB unter Last. Fallen mir Fehlerbilder auf, sind es meist: fehlender Vary‑Header (Cache‑Poisoning), doppelte Kompression (br+gz), falsch gesetzte Content‑Type/Encoding‑Paare oder unnötige Kompression winziger Dateien. Diese Fälle behebe ich zuerst, bevor ich Level weiter erhöhe.

Kostenwirkung kurz kalkuliert

Kompression spart nicht nur Zeit, sondern auch Egress‑Volumen. Wer pro Monat z. B. 1 TB Text‑Traffic ausliefert und durch Brotli im Schnitt 20 % zusätzlich gegenüber Gzip einspart, reduziert den Ausgeh‑Traffic um rund 200 GB. Je nach Tarif summieren sich solche Einsparungen merklich. Auf Compute‑Seite gilt: Höhere Live‑Level kosten CPU‑Zeit. Ich balanciere daher Egress‑Kosten gegen CPU‑Budget und verschiebe teure Level in den Build, wo sie nur einmalig anfallen.

Edge‑Cases: Streaming, Proxies und kleine Dateien

Bei Server‑Sent Events oder gestreamten Antworten bevorzuge ich Gzip in niedrigen Leveln oder deaktivierte Kompression, damit Chunks ohne Verzögerung fließen. Hinter älteren Proxies, die Accept‑Encoding verändern, halte ich Gzip als robusten Fallback aktiv. Und für Dateien unter ~1 KB spare ich mir die Kompression ganz, da Header‑Overhead und Latenz den Gewinn oft neutralisieren.

Zusammenfassung: Der kluge Mix zahlt sich aus

Ich setze Brotli bevorzugt bei statischen Dateien ein und halte Gzip als zuverlässige Rückfallebene parat. Für dynamische Antworten peile ich schnelle Level an, für Builds maximale Einsparung. So kombiniere ich kurze TTFB mit sehr kleinen Transfers und stärke die Core Web Vitals nachhaltig. Mit sauberer Konfiguration, Pre‑Komprimierung und Monitoring bleibt der Stack schnell und stabil. Wer diesen Mix konsequent nutzt, spürt die Ladezeit‑Vorteile sofort.