4 ms·

Is anyone serving zstd over HTTP to browsers (instead of gzip or brotli)? It seems like the speed would be ideal in this use case.

• cratermoon 6y ago
  The performance of zstd suffers without a dictionary, making it comparable to brotli on large files, but worse on small files. Lacking a clear source for a public dictionary suited to the web corpus, there's not much point in putting it in browsers.
  • Keithamus 6y ago
    Brotli has a static dictionary (contents of which can be seen here[1]) which was created from a web corpus. It’s part of the spec[2]. A derivative implementation of zstd could make use of this as a static dictionary. [1] https://gist.github.com/klauspost/2900d5ba6f9b65d69c8e https://gist.github.com/klauspost/2900d5ba6f9b65d69c8e [2] https://tools.ietf.org/html/rfc7932#appendix-A https://tools.ietf.org/html/rfc7932#appendix-A
    • cratermoon 6y ago
      Yeah I think the only holdup is getting an agreement on dictionary or, more likely, dictionaries, to be shipped with the spec implementation
• loeg 6y ago
  https://tools.ietf.org/html/rfc8478 https://tools.ietf.org/html/rfc8478 I'm unfamiliar with the IETF process and whether or not browsers support zstd compression yet.
• felixhandte 6y ago
  Browsers, no, they haven't shipped support at present. Facebook is using it for its HTTP traffic to its apps though. We've seen significant benefits. The compression ratio is pretty comparable to Brotli, but it decompresses very much faster, which is nice when the client is a mobile device--lower latency, longer battery life, etc.