Brotli & Gzip Benchmark

Brotli & Gzip Komprimierungs-Benchmark & Bandbreiten-Rechner

Analysieren Sie Text-, CSS- und JavaScript-Nutzlasten mit der nativen CompressionStream-API, um Brotli/Gzip-Raten und mobile 3G/4G-Ladezeiten präzise zu ermitteln.

Presets:
Netzwerkprofil:
Monatliche Aufrufe:
Ready14.6 KB initcwndCSS
Eingabe-Nutzlast (Code / Text)2.39 KB
Algorithmus & KomprimierungsstufeZielverhältnis & TCP-Status
Uncompressed (Raw)Baseline
2.39 KB1x
Fastest (0 ms)
Passt in 1. TCP-Burst (≤ 14.6 KB)
Deflate (RFC 1951)Standard
839 B(-66%)2.92x
Native Stream
Passt in 1. TCP-Burst (≤ 14.6 KB)
Gzip (RFC 1952, Level 6)Universal
856 B(-65%)2.86x
Native Stream
Passt in 1. TCP-Burst (≤ 14.6 KB)
Brotli Dynamic (Level 5-6)Web Standard
668 B(-73%)3.66x
+18% vs Gzip(1.5ms)
Passt in 1. TCP-Burst (≤ 14.6 KB)
Brotli Static Pre-comp (Level 11)Maximum Density
608 B(-75%)4.02x
+26% vs Gzip
Passt in 1. TCP-Burst (≤ 14.6 KB)
Zstandard (Zstd Level 3)High Throughput
702 B(-71%)3.49x
Fastest Decompress(0.8ms)
Passt in 1. TCP-Burst (≤ 14.6 KB)
Brotli-Vorteil ggü. Gzip
+8%Dichtere Kompression

Das statische Brotli-Wörterbuch kodiert HTML- und CSS-Token in 1-2 Bytes statt voller ASCII-Zeichen.

3G-Ladezeitgewinn
36 msEingespart beiSlow 3G

Reduziert initiale TCP-Slow-Start-Umläufe und beschleunigt First Contentful Paint (FCP).

Cloud-Transferkosten-Ersparnis
$0.18 / yr (AWS CDN)

Berechnet bei 1M req Skalierung zum Standardtarif von $0.085/GB Egress.

100% Browser-native CompressionStream Engine

Keine Server-Uploads. Nutzt die moderne Web Streams API (CompressionStream), um Bytegrößen und Komprimierungszeiten direkt im Browser zu messen.

Empirische Brotli- & Zstandard-Modelle

Berücksichtigt das 122 KB Web-Wörterbuch von Brotli und sliding-window Redundanz für präzise dynamische (Stufe 5) und statische (Stufe 11) Vorhersagen.

Realistische TCP-Slow-Start Simulation

Modelliert das Initial Congestion Window (initcwnd = 14,6 KB) und Round-Trip-Bursts für präzise 3G/4G-Latenzanalysen.

Technische Referenz & Architektur-Leitfaden

Brotli & Gzip Komprimierungs-Benchmark & Bandbreiteneinsparungs-Rechner — Referenz-Leitfaden

Analysieren Sie Text-, CSS- und JavaScript-Nutzlasten mit der nativen CompressionStream-API, um Brotli/Gzip-Raten und mobile 3G/4G-Ladezeiten präzise zu ermitteln.

Wichtige Parameter & Steuerelemente

Nutzlast-Eingabe (Payload Input)String | File Buffer

Quell-Klartext, JavaScript-Bundles, CSS-Stylesheets, JSON oder HTML-Inhalte, die komprimiert und bewertet werden sollen.

Standard: Beispiel-JavaScript / CSS-Bundle
Ziel-KomprimierungsalgorithmusEnum (Brotli | Gzip | Both)

Zu evaluierender Algorithmus. Brotli (RFC 7932) bietet integrierte statische Wörterbücher für Web-Assets, während Gzip (RFC 1952 DEFLATE) universelle Abwärtskompatibilität gewährleistet.

Standard: Both (Vergleichend)
Komprimierungsstufe (Quality Level)Integer (Gzip: 1-9 | Brotli: 0-11)

Verhältnis zwischen CPU-Rechenaufwand und erzielter Byte-Kompression. Niedrige Stufen eignen sich für dynamische Streaming-Antworten; Maximalstufen (Brotli 11, Gzip 9) sind ideal für statische CDN-Build-Artefakte.

Standard: Brotli 6 / Gzip 6 (dynamisch) | Brotli 11 (statisch)
Netzwerk-SimulationsprofilEnum (Slow 3G | Fast 3G | 4G LTE | Broadband)

Simulierte Netzwerkdrosselung mit spezifischen RTT-Latenzen und Durchsatzraten zur Berechnung von TTFB und Gesamtdauer der Übertragung.

Standard: Fast 3G (1,6 Mbps, 150ms RTT)

Profi-Tipps & Best Practices

Komprimieren Sie produktive JS

Komprimieren Sie produktive JS-, CSS- und SVG-Assets bereits während des CI/CD-Builds mit Brotli Stufe 11 und Gzip Stufe 9 (oder Zopfli). Die Bereitstellung über Nginx mit brotli_static on; spart maximale Bandbreite bei 0 % Laufzeit-CPU-Last.

Nutzlasten unter 1 KB können durch den

Nutzlasten unter 1 KB können durch den Header- und Metadaten-Overhead von Brotli/Gzip nach der Komprimierung größer als das Original werden. Konfigurieren Sie Ihren Webserver mit gzip_min_length 1024; und brotli_min_length 1024;.

Stellen Sie sicher

Stellen Sie sicher, dass Reverse-Proxys und CDNs den Vary: Accept-Encoding-Header berücksichtigen, um zu verhindern, dass Clients ohne Brotli-Unterstützung fehlerhaft gecachte Content-Encoding: br-Inhalte erhalten.

Deaktivieren Sie die

Deaktivieren Sie die HTTP-Komprimierung für sensible Antworten, die Benutzereingaben zusammen mit Geheimnissen (z. B. CSRF-Tokens) widerspiegeln, oder trennen Sie Tokens in ungepufferten Cookies bzw. separaten Sub-Requests.

Häufige Fallstricke & Fehlerbehebung

Die komprimierte Datei ist größer als die unkomprimierte Originaldatei

Dateien unter ca. 1 KB oder bereits komprimierte Binärformate (wie JPEG, PNG, WOFF2) besitzen keine wiederkehrenden Textmuster. Die Header und Huffman-Tabellen übersteigen die Einsparung. Setzen Sie einen Schwellenwert (z. B. 1024 Bytes) und filtern Sie Binärformate aus.

Der Browser lädt Rohdaten herunter oder zeigt unleserliche Sonderzeichen an

Der Webserver hat komprimierte Daten ohne den entsprechenden HTTP-Header Content-Encoding: br oder Content-Encoding: gzip gesendet. Überprüfen Sie die Header-Konfiguration Ihres Webservers oder CDN-Origins.

Hohe Server-CPU-Last und Latenzspitzen bei starkem Benutzerverkehr

Die dynamische Komprimierung in Echtzeit auf Maximalstufe (Brotli 10-11, Gzip 9) überlastet die CPU. Begrenzen Sie dynamische Payloads auf Brotli 4-5 bzw. Gzip 5-6 und lagern Sie statische Ressourcen vollständig in den Build-Schritt aus.

Häufig gestellte Fragen (FAQ)

Warum komprimiert Brotli Webinhalte deutlich effizienter als Gzip?▼

Brotli verwendet ein gleitendes Fenster von bis zu 16 MB (gegenüber 32 KB bei Gzip DEFLATE) und verfügt über ein festes statisches Wörterbuch mit über 120.000 typischen HTML-, JS- und Webbegriffen. Dies ermöglicht bei Text-Assets 15 % bis 25 % höhere Kompressionsdichten im Vergleich zu Gzip.

Funktioniert Brotli in modernen Browsern auch über unverschlüsseltes HTTP?▼

Nein. Alle führenden Browser (Chrome, Firefox, Safari, Edge) setzen für Brotli (Content-Encoding: br) zwingend HTTPS voraus, da ältere zwischengeschaltete Proxys unverschlüsselte Brotli-Datenströme auf Port 80 häufig beschädigt haben.

Welche Komprimierungsstufe sollte für dynamische vs. statische Ressourcen gewählt werden?▼

Für statische Dateien, die im CI/CD-Prozess erzeugt werden, empfiehlt sich Brotli Stufe 11 (--best) oder Gzip 9/Zopfli, da der Rechenaufwand nur einmal anfällt. Für dynamisch pro Anfrage erzeugte API-Antworten sind Brotli 4-5 oder Gzip 5-6 der beste Kompromiss aus Latenz und CPU-Ressourcen.

Wie wirkt sich die Nutzlast-Komprimierung direkt auf die Core Web Vitals aus?▼

Durch die Reduzierung kritischer CSS- und JS-Dateien werden First Contentful Paint (FCP) und Largest Contentful Paint (LCP) beschleunigt, da weniger TCP-Pakete übertragen werden müssen und Verzögerungen durch TCP Slow-Start entfallen.

Sollten Bild- und Videoformate wie WebP, AVIF oder MP4 komprimiert werden?▼

Nein. Moderne Medienformate wie WebP, AVIF oder MP4 sind bereits stark verlustbehaftet oder verlustfrei entropiekodiert. Ein nachträgliches Komprimieren mit Gzip oder Brotli verbraucht unnötig CPU-Zyklen und vergrößert häufig die Datei.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →