Chrome has something like this called SDCH, but it hasn't seen a ton of adoption outside Google: https://en.wikipedia.org/wiki/SDCH https://en.wikipedia.org/wi

Chrome has something like this called SDCH, but it hasn't seen a ton of adoption outside Google: https://en.wikipedia.org/wiki/SDCH https://en.wikipedia.org/wiki/SDCH https://engineering.linkedin.com/shared-dictionary-compression-http-linkedin https://engineering.linkedin.com/shared-dictionary-compressi... https://aprescott.com/posts/sdch https://aprescott.com/posts/sdch Guessing part of the hurdle is that you can't simply drop it in like gzip; you have to generate a dictionary and serve it and refresh it now and then (the LinkedIn post explains). And a CDN can't just cache "the SDCH'd version" of a resource; ideally it'd cache one version for each recently used dict. The other, slightly happier "problem," is that other tuning can make the additional gains from SDCH less dramatic. I looked, and the Google homepage has a blob of JS that's 40KB gzip+sdch'd--but it's ~100KB gzip -9'd, and probably costs me 0KB most of the time because it's cacheable and its Last-Modified is about a month ago. CloudFlare's Railgun proxy does use delta coding to good effect, though in a much different context (origin server to edge location). I can imagine other variations, like priming Brotli's (de)compressor's history buffer with the first bytes of the old version of a cacheable resource in an If-None-Match request, if both sides have the old version handy and advertise the encoding. Sounds like what you're saying. Like SDCH, that still isn't drop-in; the server has to remember old versions of things. And it only applies to cached resources. Anyhow, interesting space.