Re: Implementation experience: Dictionary TTL for dynamic content delta compression (RFC 9842)

Thanks. This wasn't something we had considered when originally looking at
the dictionary lifetime.

The main use case we had considered for decoupling the dictionary lifetime
from the resource lifetime was to shorten the dictionary lifetime for
long-lived resources that are updated frequently (think a versioned URL for
the youtube desktop player if it is updated daily). Shortening the
dictionary lifetime can reduce the number of variants (and cache entries
used) for "vary: available-dictionary" if you want to only support
delta-encoding for a shorter timespan than the long tail of re-visits.
Optimally you'd just shorten the cache lifetime of the versioned resource
since you know it won't actually be used a year later so there wasn't a
strong use case for it.

Luckily, overriding the dictionary with an explicit ttl should be
backwards-compatible and fall back to the cache lifetime of the resource
for the dictionary so, as long as that is taken into account when using it,
it should be a safe extension.

I look forward to the results from the larger production-scale test.

I'd love to hear from others if managing a per-session dictionary in a
server-side cache is something they'd consider or if the number of
dictionaries they'd have to manage is a problem. The similar case that
comes to mind would be an API endpoint of some kind where it maintains a
sticky session and the responses are somewhat specific to the session but
very common across requests to the same session. In that case, the first
response could also serve as a dictionary that the server keeps with the
session (and could optionally refresh as needed from future responses).
That would let you do some pretty good compression of API-style traffic
without having to use a separate stand-alone dictionary.

On Sat, Mar 7, 2026 at 5:47 AM Carlos Mateo <carlos23p@gmail.com> wrote:

> Hi all,
>
> I wanted to share implementation experience relevant to decoupling
> dictionary and cache lifetimes in Compression Dictionary Transport (RFC
> 9842).
>
> This was discussed during standardization (httpwg/http-extensions#2649)
> and scoped out. Now that CDT has shipped and the Dictionary TTL extension
> is available for developer testing in Chromium (
> https://groups.google.com/a/chromium.org/g/blink-dev/c/pW8bjRXGNKs), I've
> built a prototype that measures the impact of using previous responses as
> dictionaries for dynamic (no-cache) content.
>
> Full writeup:
> https://dev.to/carlosmateom/beyond-static-resources-delta-compression-for-dynamic-html-3hn4
> Live demo: https://delta-compression-demo.onrender.com
> Source code: https://github.com/carlosmateo10/delta-compression-demo
>
> The prototype generates realistic dynamic pages (~50KB) with
> session-dependent CSS class hashing, large inline JSON state, and
> per-request tokens (CSP nonces, CSRF tokens).
>
> Using the previous response from the same session as a dcb dictionary
> achieves 96-98% compression savings on cross-query navigation-10-27x
> smaller than standard Brotli, and 7-19x smaller than a static shared
> dictionary built from different sessions. The static dictionary misses
> everything session-specific: hashed class names, CSS values,
> feature-flag-dependent DOM structures, and inline state.
>
> For duplicate queries (tab restore, back-button, refresh), the entire page
> compresses to ~100 bytes, a 468x reduction over standard Brotli. Only the
> per-request CSRF token, CSP nonce, and timestamp changed. The server-side
> cost is per-session dictionary storage with TTL-based eviction. For 100K
> concurrent sessions with a 600-second TTL, this is roughly 10 GB within a
> single cache instance.
>
> Given these initial results, I would love to start a conversation about
> drafting a spec extension that adds support for the TTL parameter. We are
> also experimenting with this approach for Google Search, and we will have
> data from a large-scale deployment to add to the conversation soon. The
> Dictionary TTL mechanism (Use-As-Dictionary: match="/search*", ttl=600)
> reuses the existing dcb/dcz encoding, the only addition is a TTL parameter.
>
> Feedback welcome on the approach, measurements, or implementation.
>
> Best,
> Carlos Mateo Muñoz
>