If/when shipping, just remember to add this to the list of "Accepted Content-Encodings" that shows up on the developer tools, under the "Network conditions" panel. :) [image: image.png]
☆*PhistucK* On Wed, Jun 21, 2023 at 6:08 PM Dale Curtis <[email protected]> wrote: > On Wed, Jun 21, 2023 at 3:18 AM Adam Rice <[email protected]> wrote: > >> Drive by question: Given that the codec is going to be in the browser, >>> are there plans to surface this up to CompressionStreams? (same question >>> applies for Brotli, I suppose) >> >> >> For the zstd Content-Encoding, we will only be linking in the >> decompression part of the zstd library. But for CompressionStreams, >> supporting a format only for decompression and not for compression is >> likely to confuse and frustrate developers. >> > > FWIW, asymmetric codec capabilities are quite common in media and > developers have adapted just fine. E.g., we may only have hevc/aac/theora > decoding, but not encoding. > > >> >> So while I'd like to add Zstd to CompressionStreams, we'll need a good >> justification for the extra binary size increase caused by linking in the >> compression code. The same applies to Brotli. >> >> Thanks for the question! >> >> On Wed, 21 Jun 2023 at 18:53, Sangwhan Moon <[email protected]> wrote: >> >>> >>> >>> On 2023年06月21日 18時02分49秒 (+09:00), Nidhi Jaju wrote: >>> >>> >>> >>> On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju <[email protected]> >>>> wrote: >>>> >>>>> Contact [email protected] >>>>> >>>>> Explainer >>>>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing >>>>> Specificationhttps://datatracker.ietf.org/doc/html/rfc8878 >>>>> >>>>> Design docs >>>>> https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing >>>>> >>>>> Summary >>>>> >>>>> 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 support for "zstd" as a Content-Encoding will help load pages >>>>> faster >>>>> and use less bandwidth. >>>>> >>>>> Blink componentInternals>Network >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork> >>>>> >>>>> Motivation >>>>> >>>>> Supporting zstd content-encoding in the browser would allow sites to >>>>> spend less time and CPU/power on compression on their servers, resulting >>>>> in >>>>> reduced server costs. There are several published benchmarks[i.e. 1 >>>>> <https://facebook.github.io/zstd/#benchmarks>, 2 >>>>> <https://peazip.github.io/fast-compression-benchmark-brotli-zstandard.html>] >>>>> and existing research showing promising potential wins. Zstd is roughly >>>>> three times faster than Brotli for decompression. Combined with zstd being >>>>> faster at compression, this will result in faster page load times. >>>>> Initial public proposalNone >>>>> >>>>> TAG reviewNone >>>>> >>>> >>> Drive by question: Given that the codec is going to be in the browser, >>> are there plans to surface this up to CompressionStreams? (same question >>> applies for Brotli, I suppose) >>> >>> >>>>> >>>>> TAG review statusNot applicable >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> Servers that have a broken implementation of zstd might exist, but the >>>>> risk of this is small. Additionally, middleware and middleboxes like virus >>>>> checkers that intercept HTTPS connections might not support zstd, but >>>>> might >>>>> fail to remove it from the Accept-Encoding header in the request. >>>>> >>>> >>>> Are we planning to only support this encoding under secure contexts >>>> and/or H2+ to reduce that risk? >>>> >>> >>> Yes, we're only planning to support zstd encoding under secure contexts, >>> same as Brotli. >>> >>> >>>> >>>> >>>>> >>>>> >>>>> *Gecko*: No signal ( >>>>> https://github.com/mozilla/standards-positions/issues/775) >>>>> >>>>> *WebKit*: No signal ( >>>>> https://github.com/WebKit/standards-positions/issues/168) >>>>> >>>>> *Web developers*: Positive (https://crbug.com/1246971) Facebook >>>>> (Yann) and Akamai (Nic) seem to be positive about zstd content-encoding >>>>> support in the browser. Facebook is also excited to test the feature. >>>>> >>>>> *Other signals*: >>>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> No special support needed. >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?Not yet. >>>>> >>>>> Flag nameZstdContentEncoding >>>>> >>>>> Requires code in //chrome?True >>>>> >>>>> Tracking bug >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1246971 >>>>> >>>>> Estimated milestones >>>>> Shipping on desktop 117 >>>>> Shipping on Android 117 >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/6186023867908096 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAN%3DdFzxxXGt%2BTscR9zfu-dF38u_E4rQ7ynv8C%3D1C67YPA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAN%3DdFzxxXGt%2BTscR9zfu-dF38u_E4rQ7ynv8C%3D1C67YPA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxjsRhddJWgPP%3DHF5dbU9L9feqi369310-kFAzM_R6GAw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxjsRhddJWgPP%3DHF5dbU9L9feqi369310-kFAzM_R6GAw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwfV7F4QT_2g_CG9kypeujEKxaQ1MKe5fzVbY4uGSZifLw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwfV7F4QT_2g_CG9kypeujEKxaQ1MKe5fzVbY4uGSZifLw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JkoEUc77LGtAEMpt%2BQ%2BPeVJ028jbGzNrvM4y%2B09OBrYw%40mail.gmail.com.
