Chrome Feature: ZSTD Content-Encoding

Original Article ↗ Hacker News Discussion ↗

Chrome’s adoption of Zstandard (zstd) as an HTTP content-encoding signals a shift toward faster, more efficient web compression beyond gzip and Brotli. Commenters highlight zstd’s strong balance of speed and compression ratio, its advantages for both large and small payloads, and ongoing work to integrate it into languages, libraries, servers, and proxies. Some raise concerns about ecosystem fragmentation, Chrome-led standard setting, and operational trade-offs such as recompression costs and caching, but most see broad browser and tooling support as inevitable.

Overall reaction

  • Many are enthusiastic that Chrome now supports zstd content-encoding and expect wider ecosystem support (languages, frameworks, proxies).
  • Some are surprised major browsers didn’t add it years ago, given perceived advantages over gzip and Brotli.
  • A few think the benefits over Brotli are marginal and question the cost/benefit for servers and CDNs.

Performance vs other compression formats

  • General view: zstd offers a strong trade-off between compression ratio and speed; often “good enough” versus LZ4 and much faster than gzip for similar or better ratios.
  • Comparisons mentioned:
    • zstd vs gzip: similar or better ratios, much faster compression and decompression in several benchmarks.
    • zstd vs Brotli: zstd usually faster, Brotli can yield slightly better ratios, especially on some JSON/web content.
    • zstd vs xz/LZMA: xz can compress smaller, but decompression is much slower; zstd at high levels comes close with ~10× faster decompression.
    • LZ4 considered best when absolute speed matters (e.g., RAM/ZRAM), but poor compression for web transfer.

Real-world usage reports

  • One user switched disk images from xz to zstd and saw negligible size increase but >10× faster threaded decompression.
  • Several use zstd for filesystem compression (e.g., zstd level ~3) as a default.
  • A production service reports traffic mix shifting to ~40% zstd, ~50% Brotli, with similar ratios but higher zstd encode latency at high percentiles; bandwidth costs make even 1% savings matter.

Browser support and compatibility

  • Chrome already ships zstd, including on Android; Safari/WebKit and Firefox are expected to follow, with active tracking bugs.
  • HTTP content negotiation allows serving zstd where supported while falling back to gzip/Brotli, so compatibility is maintained.
  • Chrome currently doesn’t support very high compression levels (≥20).

Dictionaries and web standards

  • Several want a standardized static zstd dictionary for the web, akin to Brotli’s built-in dictionary, to help small resources.
  • Others prefer zstd’s flexible custom-dictionary model and note an IANA registry is reserved for future shared dictionaries.
  • There is an active proposal for shared dictionary compression over HTTP; some see security risks, others note multiple rounds of formal review but remain wary.

Ecosystem integration

  • Interest in:
    • zstd in language standard libraries (Go, .NET, etc.).
    • Support in HTTP middleware, reverse proxies (nginx, HAProxy, Traefik), and Compression Streams / JS APIs.
  • cgo-based bindings can be faster but add toolchain complexity; some prefer pure-language implementations despite lower speed.

Security and trust concerns

  • The recent xz backdoor motivates a shift to zstd in some infra; also leads to scrutiny of zstd’s optional linkage to liblzma.
  • Some are skeptical of Chrome adding features, fearing long-term “embrace-extend” dynamics; others counter that zstd is an open, widely used standard and this looks like straightforward engineering.