jquery.app
Francais
EnglishDeutschFrancaisEspanol日本語Nederlands

Outils GitHub Pages

Gratuit Assistant d'en-tete de compression Zstandard

Generez la configuration serveur pour la compression Zstandard avec fallback gzip/brotli pour Nginx, Apache, Cloudflare et Netlify.

Chargement de l'outil...

Qu'est-ce que Assistant d'en-tete de compression Zstandard ?

Zstandard (zstd) is a compression algorithm developed by Meta that provides compression ratios approaching LZMA and Deflate with decompression speeds comparable to LZ4. It became Baseline 2026 with Chrome 123+ adding support for zstd Content-Encoding responses. When a browser sends Accept-Encoding: zstd in its request headers, the server can compress responses with zstd and set Content-Encoding: zstd. For clients that do not support zstd, the server must fall back to brotli (br) or gzip. Shared Dictionary Compression (SDCH) is an optional extension where the server and client share a compression dictionary, enabling delta updates that send only the changed content between page versions.

Réponse rapide

Generate server configuration for Zstandard (zstd) compression with Content-Encoding: zstd headers, Accept-Encoding negotiation, and fallback to brotli and gzip. Supports Nginx, Apache, Cloudflare Workers, and Netlify. Optional Shared Dictionary Compression for delta updates. Chrome 123+, Edge 123+, Safari 18.2+.

Limites

  • Zstandard Content-Encoding is not supported in Firefox (as of early 2026) and has limited browser market share compared to brotli and gzip. A multi-format Accept-Encoding negotiation with gzip fallback is always required for production deployment.
  • CDN and reverse proxy support for zstd pass-through is inconsistent. Cloudflare does not natively cache zstd responses. Vercel and Netlify have limited zstd support in their edge networks. Test the entire delivery chain before enabling zstd in production.
  • Shared Dictionary Compression requires server-side dictionary generation infrastructure and client-side dictionary caching. The initial page load without a cached dictionary is not compressed with SDCH, and dictionary version management adds operational complexity that may not be worthwhile for small sites.

Comment utiliser cet outil

  1. Select your hosting platform: Nginx, Apache, Cloudflare Workers, or Netlify. Each platform uses a different configuration format for enabling compression and setting Content-Encoding headers.
  2. Choose whether to enable zstd alongside existing brotli and gzip compression or replace one of them. The generated config includes proper Accept-Encoding negotiation with fallback ordering.
  3. Optionally enable Shared Dictionary Compression (SDCH) for delta updates. Requires both server and client configuration, and the generated snippet includes the dictionary negotiation headers.
  4. Copy the generated configuration into your server config file, CDN edge function, or platform-specific headers configuration file. Deploy and verify the Content-Encoding header on compressed responses.

A quoi il sert

  • Reduce bandwidth costs and page load times on a high-traffic static site by enabling zstd compression for HTML, CSS, and JavaScript assets.
  • Deploy zstd on an Nginx server fronted by Cloudflare, with proper Accept-Encoding negotiation so Cloudflare passes through zstd responses to supporting browsers.
  • Enable Shared Dictionary Compression for a frequently updated documentation site, where each deploy changes only a fraction of the total content and delta compression significantly reduces download sizes for returning visitors.

Cas d'usage

Exemples concrets

Exemple

Nginx with zstd and brotli fallback

A high-traffic blog serves HTML pages from an Nginx server. Enable zstd compression with Content-Encoding: zstd for browsers that send Accept-Encoding: zstd, with brotli as the secondary preference and gzip as the universal fallback. The generated Nginx config uses the ngx_brotli and zstd modules with a configuration block that negotiates the best compression format per request.

Exemple

Cloudflare Workers with CDN compression

A static site uses Cloudflare in front of an origin server. Since Cloudflare does not natively serve zstd-compressed content from origin, deploy a Cloudflare Worker that checks the Accept-Encoding header, fetches from the origin, compresses the response with zstd using the Web Platform Compression Streams API (CompressionStream), and sets Content-Encoding: zstd. For non-supporting browsers, the Worker passes through the origin response unchanged.

Erreurs frequentes

  • Enabling zstd without verifying the browser Accept-Encoding header -- serving gzip content with Content-Encoding: zstd header causes browsers without zstd support to fail parsing the response, displaying garbage or a blank page.
  • Using zstd in Cloudflare without a Worker -- Cloudflare does not cache or serve zstd responses from origin natively. The origin must either serve zstd through a Worker or Cloudflare must pass through the origin Content-Encoding header, which may not be cached correctly.
  • Enabling Shared Dictionary Compression without testing the dictionary negotiation -- SDCH requires careful coordination between the server and client dictionary versions. An expired or mismatched dictionary causes compression errors that break page rendering.

Vérification

  1. After deploying the zstd configuration, open the site in Chrome 123+ and check the Network panel. The response headers should include Content-Encoding: zstd. Verify the response body decompresses correctly by checking the decoded Size column in DevTools.
  2. Test the fallback chain by sending requests with different Accept-Encoding headers using curl. Run curl -H "Accept-Encoding: gzip" -I https://yoursite.com/ and confirm the response uses gzip. Run curl -H "Accept-Encoding: zstd" -I https://yoursite.com/ and confirm the response uses zstd.

FAQ

Questions sur Assistant d'en-tete de compression Zstandard

How does Zstandard compare to Brotli and Gzip?

At compression level 3-5, zstd typically compresses 5-15% better than brotli at equal speeds. At higher levels (10-19), zstd approaches LZMA-level compression ratios while decompressing 2-3x faster than brotli. Gzip is the slowest to decompress and achieves the lowest compression ratio of the three. For web content, zstd level 3 offers the best balance of compression speed and ratio. However, brotli has broader browser support (all modern browsers) compared to zstd (Chrome 123+, Edge 123+, Safari 18.2+).

Which browsers support Content-Encoding: zstd?

Content-Encoding: zstd is supported in Chrome 123+, Edge 123+, and Safari 18.2+ (Baseline 2026). Firefox does not support zstd Content-Encoding as of early 2026. Always include gzip or brotli as a fallback in your Accept-Encoding negotiation. The server Accept-Encoding handling should order the compression formats by preference, with zstd first for supporting clients.

What is Shared Dictionary Compression (SDCH) for zstd?

SDCH uses a shared dictionary between the client and server to compress only the changes between page versions. When a client visits a page, the server sends a dictionary ID and the compressed delta. On subsequent visits, the client uses the cached dictionary to decompress the delta, downloading only the changed content. This can reduce page update sizes by 80-95% for sites where most content changes slowly. SDCH requires the server to track dictionary versions and the client to cache dictionaries. It is configured via the Use-As-Dictionary and Sec-Dictionary headers.

Outils lies

Autres outils outils github pages

A essayer aussi

A essayer aussi