GitHub-Pages- & Deployment-Tools

Kostenlose Zstandard Compression Header Helfer

Generieren Sie Server-Konfiguration fur Zstandard-Kompression mit gzip/brotli-Fallback fur Nginx, Apache, Cloudflare und Netlify.

Tool wird geladen...

Was ist Zstandard Compression Header Helfer?

Zstandard (zstd) ist ein von Meta entwickelter Kompressionsalgorithmus, der Kompressionsverhältnisse nahe LZMA und Deflate mit Dekompressionsgeschwindigkeiten vergleichbar mit LZ4 bietet. Es wurde Baseline 2026 mit Chrome 123+, das Unterstützung für zstd Content-Encoding-Antworten hinzufügte. Wenn ein Browser Accept-Encoding: zstd in seinen Anfrage-Headern sendet, kann der Server Antworten mit zstd komprimieren und Content-Encoding: zstd setzen. Für Clients, die zstd nicht unterstützen, muss der Server auf brotli (br) oder gzip zurückfallen. Shared Dictionary Compression (SDCH) ist eine optionale Erweiterung, bei der Server und Client ein Kompressionswörterbuch teilen, das Delta-Updates ermöglicht, die nur die geänderten Inhalte zwischen Seitenversionen senden.

Kurze Antwort

Generieren Sie Server-Konfiguration für Zstandard (zstd)-Komprimierung mit Content-Encoding: zstd-Headern, Accept-Encoding-Aushandlung und Fallback zu brotli und gzip. Unterstützt Nginx, Apache, Cloudflare Workers und Netlify. Optionale Shared Dictionary Compression für Delta-Updates. Chrome 123+, Edge 123+, Safari 18.2+.

Last updated: 2026-06-03

Einschränkungen

Zstandard Content-Encoding wird in Firefox nicht unterstützt (Stand Anfang 2026) und hat einen begrenzten Browser-Marktanteil im Vergleich zu brotli und gzip. Eine Multi-Format-Accept-Encoding-Aushandlung mit gzip-Fallback ist für den Produktionseinsatz immer erforderlich.
Die Unterstützung von CDN und Reverse-Proxy für zstd-Pass-Through ist inkonsistent. Cloudflare cached zstd-Antworten nicht nativ. Vercel und Netlify haben begrenzte zstd-Unterstützung in ihren Edge-Netzwerken. Testen Sie die gesamte Lieferkette, bevor Sie zstd in Produktion aktivieren.
Shared Dictionary Compression erfordert serverseitige Wörterbuchgenerierungs-Infrastruktur und clientseitiges Wörterbuch-Caching. Der anfängliche Seitenaufbau ohne zwischengespeichertes Wörterbuch wird nicht mit SDCH komprimiert, und die Wörterbuch-Versionsverwaltung fügt operationelle Komplexität hinzu, die sich für kleine Seiten möglicherweise nicht lohnt.

Sources:MDN Web Docs · W3C Specifications · jquery.app on GitHub

So nutzt du dieses Tool

Wählen Sie Ihre Hosting-Plattform: Nginx, Apache, Cloudflare Workers oder Netlify. Jede Plattform verwendet ein anderes Konfigurationsformat zum Aktivieren der Komprimierung und Setzen von Content-Encoding-Headern.
Wählen Sie, ob Sie zstd neben bestehender brotli- und gzip-Komprimierung aktivieren oder eine davon ersetzen möchten. Die generierte Konfiguration enthält eine ordnungsgemäße Accept-Encoding-Aushandlung mit Fallback-Reihenfolge.
Aktivieren Sie optional Shared Dictionary Compression (SDCH) für Delta-Updates. Erfordert sowohl Server- als auch Client-Konfiguration, und das generierte Snippet enthält die Dictionary-Aushandlungs-Header.
Kopieren Sie die generierte Konfiguration in Ihre Server-Konfigurationsdatei, CDN-Edge-Funktion oder plattformspezifische Header-Konfigurationsdatei. Stellen Sie bereit und überprüfen Sie den Content-Encoding-Header auf komprimierten Antworten.

Wofür du es nutzen kannst

Reduzieren Sie Bandbreitenkosten und Seitenladezeiten auf einer stark frequentierten statischen Seite durch Aktivierung der zstd-Komprimierung für HTML-, CSS- und JavaScript-Assets.
Setzen Sie zstd auf einem Nginx-Server mit vorgeschaltetem Cloudflare ein, mit ordnungsgemäßer Accept-Encoding-Aushandlung, sodass Cloudflare zstd-Antworten an unterstützende Browser weiterleitet.
Aktivieren Sie Shared Dictionary Compression für eine häufig aktualisierte Dokumentationsseite, bei der jedes Deployment nur einen Bruchteil des gesamten Inhalts ändert und die Delta-Komprimierung die Download-Größen für wiederkehrende Besucher erheblich reduziert.

Anwendungsfalle

Praxisbeispiele

Beispiel

Nginx mit zstd und brotli-Fallback

Ein stark frequentierter Blog serviert HTML-Seiten von einem Nginx-Server. Aktivieren Sie die zstd-Komprimierung mit Content-Encoding: zstd für Browser, die Accept-Encoding: zstd senden, mit brotli als sekundäre Präferenz und gzip als universellem Fallback. Die generierte Nginx-Konfiguration verwendet die ngx_brotli- und zstd-Module mit einem Konfigurationsblock, der das beste Komprimierungsformat pro Anfrage aushandelt.

Beispiel

Cloudflare Workers mit CDN-Komprimierung

Eine statische Seite verwendet Cloudflare vor einem Origin-Server. Da Cloudflare nativ keine zstd-komprimierten Inhalte vom Origin ausliefert, setzen Sie einen Cloudflare Worker ein, der den Accept-Encoding-Header prüft, vom Origin abruft, die Antwort mit zstd über die Web Platform Compression Streams API (CompressionStream) komprimiert und Content-Encoding: zstd setzt. Für nicht unterstützende Browser leitet der Worker die Origin-Antwort unverändert durch.

Haufige Fehler

zstd zu aktivieren, ohne den Browser Accept-Encoding-Header zu überprüfen - das Ausliefern von gzip-Inhalten mit Content-Encoding: zstd-Header führt dazu, dass Browser ohne zstd-Unterstützung die Antwort nicht parsen können und Müll oder eine leere Seite anzeigen.
zstd in Cloudflare ohne einen Worker zu verwenden - Cloudflare cached oder serviert zstd-Antworten vom Origin nicht nativ. Der Origin muss zstd entweder durch einen Worker ausliefern oder Cloudflare muss den Origin Content-Encoding-Header durchreichen, was möglicherweise nicht korrekt gecached wird.
Shared Dictionary Compression ohne Testen der Dictionary-Aushandlung zu aktivieren - SDCH erfordert sorgfältige Koordination zwischen Server- und Client-Dictionary-Versionen. Ein abgelaufenes oder nicht übereinstimmendes Dictionary verursacht Kompressionsfehler, die das Seitenrendering beeinträchtigen.

Überprüfung

Öffnen Sie die Seite nach der Bereitstellung der zstd-Konfiguration in Chrome 123+ und prüfen Sie das Network-Panel. Die Antwort-Header sollten Content-Encoding: zstd enthalten. Überprüfen Sie, dass der Antworttext korrekt dekomprimiert wird, indem Sie die dekodierte Size-Spalte in DevTools prüfen.
Testen Sie die Fallback-Kette, indem Sie Anfragen mit verschiedenen Accept-Encoding-Headern per curl senden. Führen Sie curl -H 'Accept-Encoding: gzip' -I https://ihreseite.com/ aus und bestätigen Sie, dass die Antwort gzip verwendet. Führen Sie curl -H 'Accept-Encoding: zstd' -I https://ihreseite.com/ aus und bestätigen Sie, dass die Antwort zstd verwendet.

FAQ

Fragen zu Zstandard Compression Header Helfer

Wie vergleicht sich Zstandard mit Brotli und Gzip?

Auf Kompressionsstufe 3-5 komprimiert zstd typischerweise 5-15% besser als brotli bei gleichen Geschwindigkeiten. Auf höheren Stufen (10-19) erreicht zstd LZMA-nahe Kompressionsverhältnisse bei 2-3x schnellerer Dekompression als brotli. Gzip ist am langsamsten zu dekomprimieren und erreicht das niedrigste Kompressionsverhältnis der drei. Für Webinhalte bietet zstd Stufe 3 die beste Balance aus Kompressionsgeschwindigkeit und -verhältnis. Brotli hat jedoch eine breitere Browserunterstützung (alle modernen Browser) im Vergleich zu zstd (Chrome 123+, Edge 123+, Safari 18.2+).

Welche Browser unterstützen Content-Encoding: zstd?

Content-Encoding: zstd wird in Chrome 123+, Edge 123+ und Safari 18.2+ (Baseline 2026) unterstützt. Firefox unterstützt Stand Anfang 2026 kein zstd Content-Encoding. Fügen Sie immer gzip oder brotli als Fallback in Ihre Accept-Encoding-Aushandlung ein. Die Server-Accept-Encoding-Verarbeitung sollte die Komprimierungsformate nach Präferenz ordnen, mit zstd zuerst für unterstützende Clients.

Was ist Shared Dictionary Compression (SDCH) für zstd?

SDCH verwendet ein gemeinsames Wörterbuch zwischen Client und Server, um nur die Änderungen zwischen Seitenversionen zu komprimieren. Wenn ein Client eine Seite besucht, sendet der Server eine Dictionary-ID und das komprimierte Delta. Bei nachfolgenden Besuchen verwendet der Client das zwischengespeicherte Wörterbuch, um das Delta zu dekomprimieren und lädt nur den geänderten Inhalt herunter. Dies kann die Größe von Seitenaktualisierungen um 80-95% für Seiten reduzieren, bei denen sich der meiste Inhalt langsam ändert. SDCH erfordert, dass der Server Wörterbuchversionen verfolgt und der Client Wörterbücher zwischenspeichert. Es wird über die Use-As-Dictionary- und Sec-Dictionary-Header konfiguriert.

Verwandte Tools