HTTP-Kompressions-Prüfer

Überprüft, ob Ihr Webserver gzip und Brotli-Kompression unterstützt. Vergleicht komprimierte und unkomprimierte Response-Größen, berechnet das Kompressionsverhältnis, überprüft Content-Encoding-Header und verifiziert Vary-Header für korrektes CDN-Caching.

So verwenden Sie HTTP-Kompressions-Prüfer

  1. 1Geben Sie eine URL ein, um HTTP-Kompression zu testen.
  2. 2Das Tool ruft die URL mit gzip und Brotli Accept-Encoding-Headern ab.
  3. 3Komprimierte und unkomprimierte Response-Größen werden verglichen.
  4. 4Kompressionsverhältnis, Content-Encoding und Vary-Header werden angezeigt.
ZenovayAnalytics

Sehen Sie, wer gerade auf Ihrer Seite ist.

  • Besucher-Tracking in Echtzeit
  • Datenschutz zuerst, kein Cookie-Banner
  • In zwei Minuten eingerichtet
Zenovay entdecken

Häufig gestellte Fragen

Warum ist HTTP-Kompression für die Leistung wichtig?
HTTP-Kompression reduziert die Größe von textbasierten Ressourcen (HTML, CSS, JavaScript, JSON, XML), die über das Netzwerk gesendet werden. Gzip reduziert typischerweise Dateigröße um 60-80%, und Brotli erreicht 15-25% bessere Kompression als gzip. Für große Seiten kann dies Hunderte von Kilobyte sparen, wodurch die Time-to-First-Byte (TTFB) und Core Web Vitals (LCP, FCP) erheblich verbessert werden. Die Kompression ist besonders wirkungsvoll auf langsamen mobilen Verbindungen.
Was ist der Unterschied zwischen gzip und Brotli?
Gzip (Content-Encoding: gzip) ist der ältere, universelle Kompressions-Standard, der seit 2010 von allen Browsern unterstützt wird. Brotli (Content-Encoding: br) ist Googles neuerer Algorithmus, der bessere Kompressionsquoten erreicht, besonders für Text-Inhalt. Brotli wird von allen modernen Browsern unterstützt (Chrome 49+, Firefox 44+, Safari 11+, Edge 15+). CDNs wie Cloudflare und Fastly unterstützen beide. Wenn Ihr Server Brotli unterstützt, sollte es bevorzugt werden – besonders für statische Assets.
Wofür ist der Header Vary: Accept-Encoding?
Wenn ein Server verschiedene komprimierte Antworten basierend auf dem serviert, was der Client unterstützt, muss er Vary: Accept-Encoding in der Antwort einschließen. Dies teilt CDN-Proxys und Caches mit, dass die Antwort um den Accept-Encoding-Request-Header variiert, sodass sie separate Versionen für gzip vs. Brotli vs. unkomprimiert zwischenspeichern. Ohne Vary: Accept-Encoding könnte ein CDN eine gzip-Antwort zwischenspeichern und an einen Client servieren, der gzip nicht dekomprimieren kann, was zu unleserlichen Inhalten führt.
Sollte ich alle Inhaltstypen komprimieren?
Komprimieren Sie textbasierte Inhalte: HTML, CSS, JavaScript, JSON, XML, SVG, Klartext und Web-Schriften (WOFF/WOFF2). Komprimieren Sie NICHT bereits komprimierte Formate: JPEG, PNG, WebP, AVIF, MP4, ZIP, PDF, WOFF2. Die Komprimierung von vorkomprimierten Binärdaten verschwendet CPU und kann die Größe leicht erhöhen. Die meisten Webserver handhaben dies automatisch mit einer MIME-Typ-Zulassungsliste.
Wie aktiviere ich Brotli auf meinem Server?
Nginx: Installieren Sie ngx_brotli-Modul und fügen Sie brotli on; brotli_comp_level 6; brotli_types text/html text/css application/javascript; zu Ihrer Konfiguration hinzu. Apache: Installieren Sie mod_brotli und verwenden Sie AddOutputFilterByType BROTLI_COMPRESS. Cloudflare: wendet automatisch Brotli auf alle Antworten an. Node.js/Express: verwenden Sie das shrink-ray-current-Middleware. Caddy: standardmäßig aktiviert.