Does anyone know which (if any) CDNs support zstd compression?
-
Does anyone know which (if any) CDNs support zstd compression?
Apparently it's used for at least one response within ~13% of pageviews [1], so I'm guessing that's Meta's web properties (given it's their tech), one big CDN or some other third-parties
/cc @PatMeenan @programmingart
[1]: https://chromestatus.com/metrics/feature/timeline/popularity/4629
-
@ryantownsend @programmingart my guess is the usage is a combination of Meta's web properties and their 3rd-party embeds on other sites (retargeting js).
To trigger the feature usage it just needs to be used by one response anywhere in the page.
I know there's one other big Asian site that uses it but can't remember which off the top of my head.
-
@programmingart said Microsoft are heavily experimenting with it too, so maybe Bing traffic/retargeting could be in that pool too.
-
@ryantownsend @PatMeenan @programmingart Have you found it useful for web-like-things?
-
@orangeacme @PatMeenan @programmingart I haven’t personally implemented it, but it compresses far faster than Brotli at similar rates of compression.
Should be pretty beneficial for large CDNs cost-wise over compressing with Brotli, which is why many only compress cacheable content.
Zstd should make on-the-fly compression possible while having a better compression ratio than Gzip.
-
@ryantownsend @PatMeenan @programmingart
Several do, yes. Here's a link to a place that pays my bills, lol. Regardless, one can safely assume that if Fastly supports zstd at various levels of the caching architecture, then partner CDNs do as well (for multiple reasons, only some of which are technical in nature).
Something to consider, when CDN marketing says "We support $thing", it's not just one layer of the data transit or data cached which is in play... data cached on persistent block storage, data compressed in volatile cache, data compression between cluster nodes, between customer origin and CDN ingress, during metadata log analysis and streaming metrics provided to the customer, and eventually data compression between the edge itself and the user's browser.
Does the QUIC handshake require compression to be fast?
QUIC promises a built-in, low-latency handshake. But can it achieve its promise alone? Let’s look at the value of handshake compression in helping QUIC achieve fast startup performance.
(www.fastly.com)
-
@winterschon @PatMeenan @programmingart absolutely – I should have probably been more specific: I’m talking about automated compression by the CDN for delivery to end-users (e.g. website visitors, API clients etc).
Certainly not just pass-through from origin.