Zstandard Content-Encoding

[nidhijaju]

こんにちは TAG-さん!

I'm requesting a TAG review of Zstandard Content-Encoding.

Zstandard, or “zstd”, is a data compression mechanism described in RFC8878. It is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better compression ratios. The "zstd" token was added as an IANA-registered Content-Encoding token as per https://datatracker.ietf.org/doc/html/rfc8878#name-content-encoding.

Adding browser support for "zstd" as a Content-Encoding will help load pages faster, use less bandwidth, and spend less time and CPU/power on compression on servers, resulting in reduced server costs.

• Explainer¹ (minimally containing user needs and example code): https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
• Specification URL: https://datatracker.ietf.org/doc/html/rfc8878
• Tests: Add tests for zstd content-encoding web-platform-tests/wpt#44393
• User research: https://https://facebook.github.io/zstd/#benchmarks
• Security and Privacy self-review²: https://docs.google.com/document/d/1IS9g7CcGl44KCCLGS0q75KQFcPgVs56amWszELpo08g/edit?usp=sharing
• GitHub repo (if you prefer feedback filed there): https://https://github.com/facebook/zstd
• Primary contacts (and their relationship to the specification):
  • Nidhi Jaju (@nidhijaju), Google, Chromium support implementor
  • Felix Handte (@felixhandte), Meta, Zstd maintainer
  • Yann Collet (@Cyan4973), Meta, RFC Author & Zstd maintainer
• Organization(s)/project(s) driving the specification: Meta, Google Chrome
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification:
  • Chromium comments: Chromium Issue, Intent to Prototype, Intent to Experiment
  • Mozilla comments: Zstandard compression format for Content-Encoding mozilla/standards-positions#775
  • WebKit comments: Zstandard compression format for Content-Encoding WebKit/standards-positions#168
  • Etc.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/6186023867908096

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Chromium is planning to ship support in M123 (branches on Feb 19, 2024).
• The group where the work on this specification is currently being done: IETF HTTP working group
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): IETF HTTP working group
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Meta, Google

You should also know that...

N/A

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[ylafon]

Hi, we discuss this with @martinthomson

The TAG recognizes that small improvements in efficiency, both in compression ratio and CPU cost, do have real benefits for web users. There are costs to adding more code to the platform and having more choices available does increase the cost and complexity of negotiation. However, those costs only mean that the benefits need to be meaningful. Zstd generally performs better than brotli, the current best of the (other) standardized options.
Adding zstd would be welcome.