Huge, huge improvements. I’ve been following this spec keenly.

1. https://compression-dictionary-transport-threejs-demo.glitch...

2. https://compression-dictionary-transport-shop-demo.glitch.me...

The one example I can think of with a pre-seeded dictionary (for web, no less) is Brotli.

https://datatracker.ietf.org/doc/html/rfc7932#appendix-A

You can more or less see what it looks like (per an older commit): https://github.com/google/brotli/blob/5692e422da6af1e991f918...

Certainly it performs better than gzip by itself.

Some historical discussion: https://news.ycombinator.com/item?id=19678985

A more readable version of the Brotli dictionary:

https://gist.github.com/duskwuff/8a75e1b5e5a06d768336c8c7c37...

If you care about latencies or are on very low bandwidth or noisy connections preshared dictionaries matter a lot. By and large they generally always help but come with complexity so are often avoided in favor of a simpler approach whose compression is acceptable rather than optimal. But if there’s a clear and well implemented standard that’s widely adopted I would always choose preshared dictionaries. Likewise secure connections are hard and without TLS and other standards most people wouldn’t try unless they really needed it. But with a good standard and broad implementation it’s basically ubiquitous.

I guess you should outline the cases you care the most about, for anyone to be able to answer if there is any material performance improvements.

The only requirements are serving a lot of the same "kind" of content, enough such (or for some other business reason) that it doesn't make sense to send it all at once, and somebody willing to spend a bit of time to implement it. Map and local geocoding information comes to mind as a decent application, and if the proposed implementation weren't so hyper-focused on common compression standards you could probably do something fancy for, e.g., meme sites (with a finite number of common or similar background images).

Assuming (perhaps pessimistically) it won't work well for most sites serving images, other possibilities include:

- Real-estate searches (where people commonly tweak tons of parameters and geographies, returning frequently duplicated information like "This historical unit has an amazing view in each of its 2 bedrooms").

- Expanding that a bit, any product search where you expect a person to, over time, frequently query for the same sorts of stuff.

- Local business information (how common is it to open at 10am and close at 6pm every weekday in some specific locale for example).

...

If the JS, image, and structural HTML payloads dwarf everything else then maybe it won't matter in practice. I bet somebody could make good use of it though.

Yup, we did experiment with SDCH at a large social network around 2015 and it didn't massively outperform gzip. Outperforming it required creating a pipeline for dynamic dictionary generation and distribution.

SDHC?

Shared Dictionary Compression for HTTP

https://en.m.wikipedia.org/wiki/SDCH

Bro, this stuff will be wild for our iot stuff

Absolutely, for the use cases where it makes sense. There are some examples here: https://github.com/WICG/compression-dictionary-transport/blo...

In the web case, it mostly only makes sense if users are using a site for more than one page (or over a long time).

Some of the common places where it can have a huge impact:

- Delta-updating wasm or JS/CSS code between releases. Like the youtube player JavaScript or Adobe Web's WASM code. Instead of downloading the whole thing again, the version in the user's cache can be used as a "dictionary" and just the deltas for the update can be delivered. Typically this is 90-99% smaller than using Brotli with no dictionary.

- Lazy-loading a site-specific dictionary for the HTML content. Pages after the first one can use the dictionary and just load the page-specific content (compresses away the headers, template, common phrases, logos, inline svg's or data URI's, etc). This usually makes the HTML 60-90% smaller depending on how much unique content is in the HTML (there is a LOT of site boilerplate).

- JSON API's can load a dictionary that has the keys and common values and basically yield a binary format on the wire for JSON data, compressing out all of the verbosity.

I expect we're still just scratching the surface of how they will be used but the results are pretty stunning if you have a site with regular user engagement.

FWIW, they are not "pre-shared" so it doesn't help the first visit to a site. The can use existing requests for delta updates or the dictionaries can be loaded on demand but it is up to the site to load them (and create them).

It will probably fall over if it gets hit too hard, but there is some tooling here that can generate dictionaries for you (using the brotli dictionary generator) and let you test the effectiveness: https://use-as-dictionary.com/

> if you have a site with regular user engagement.

Ah, gotcha: this is a new Google standard that helps Google sites when browsed using Google Chrome.

Everyone else will discover that keeping the previous version of a library around at build time doesn’t fit into the typical build process and won’t bother with this feature.

Only Facebook and maybe half a dozen similar other orgs will enable this and benefit.

The Internet top-to-bottom is owned by the G in FAANG with FAAN just along for the ride.

Even a simple case of loading more than 2-3 pages from a given site over a few weeks could benefit from a dictionary for the HTML content (compressing out all of the common template code).

Just about any e-commerce site will involve a few pages to go through search, product pages and checkout.

Most news sites will likely see at least 2-3 pages loaded by a given user over the span of a few months. Heck, even this site could shave 20-50% for each of the pages a user visits by compressing out the common HTML: https://use-as-dictionary.com/generate/result.php?id=d639194...

Any place you'd justify building a SPA, by definition, could also be a multi-page app with dictionaries.

If you have a site that visitors always bounce immediately and only visit one page in their lifetime then it can't help, but those tend to be a lot less common.

It doesn't have to be a huge site to benefit, it just needs users that regularly visit to show large gains.

As CDNs implement support, the effort involved in supporting it will also drop, likely to the point where it can just be a checkbox to generate and use dictionary-based compression.

Cloudflare and similarly placed CDNs will likely make it enabling it for sites a checkbox like option, e.g., https://blog.cloudflare.com/this-is-brotli-from-origin/ That's where it will have the most savings globally.