Chrome Feature: ZSTD Content-Encoding

Original Article ↗ Hacker News Discussion ↗

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.