v156 · network · compression

Compression dictionary transport Updates

Compression Dictionary Transport lets a server nominate one response as a dictionary for compressing later responses (with dcb Brotli or dcz Zstandard), cutting repeated bytes across a site. Chrome 156 tightens how a <link rel="compression-dictionary"> is fetched: it now sets the request's destination to compression-dictionary and aligns crossorigin and referrer/referrerpolicy handling with the spec.

concepts

  1. Link request semantics

    The exact change: add a <link rel="compression-dictionary"> and read back — from a server echo route — the request the browser actually made. Chrome 156 sends Sec-Fetch-Dest: compression-dictionary and applies the element's crossorigin and referrerpolicy; older Chrome does not. The panel reports the real headers the server saw, and honestly flags when the echo route is not yet wired.

  2. Dictionary negotiation

    The full handshake: a response advertises Use-As-Dictionary, the browser stores it, and a later matching request carries Available-Dictionary (a SHA-256 hash) plus Dictionary-ID, offering dcb/dcz in Accept-Encoding. This concept walks each header with a live server echo, showing what your browser negotiates — and what it omits when the feature is off.

  3. Client-observable probe

    What you can verify with no server cooperation at all: that link.relList.supports("compression-dictionary") is true, whether PerformanceResourceTiming.contentEncoding exists to reveal dcb/dcz after the fact, and the secure-context and enable-flag prerequisites — a real capability read, not a claim.

why it shipped

The base feature (Chrome 130) delivers dictionary-compressed responses, but the way a declared dictionary link was fetched did not match the HTML Standard. The v156 update (whatwg/html#11620) makes the fetch set the request destination to compression-dictionary (rather than only marking the initiator), and makes the fetch honour the <link> element's crossorigin and referrer/referrerpolicy attributes, mode and credentials as the spec prescribes. That matters for correctness: servers and service workers can key on the destination, and cross-origin dictionaries now follow the same CORS and referrer rules as any other declared resource.

The mechanism itself: a response carries Use-As-Dictionary: match="/app/*/main.js"; the browser stores that resource as a dictionary; a later request whose URL matches sends Available-Dictionary: :<sha-256>: (and Dictionary-ID if the server gave one) with dcb/dcz in Accept-Encoding; the server responds Content-Encoding: dcb with a delta against the dictionary. Requires a secure context.

the API

<!-- Declare a dictionary. Chrome 156 fetches this with
     destination = "compression-dictionary" and applies these attributes. -->
<link rel="compression-dictionary"
      href="/dictionaries/app-v42.dat"
      crossorigin="anonymous"
      referrerpolicy="no-referrer">
# Dictionary response
Use-As-Dictionary: match="/app/*/main.js", id="app-v42", type="raw"

# A later matching request the browser sends
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "app-v42"
Accept-Encoding: gzip, br, zstd, dcb, dcz

research notes

Grounded in RFC 9842 (Compression Dictionary Transport — the Use-As-Dictionary match/match-dest/id/type grammar, Available-Dictionary SHA-256 byte sequence, Dictionary-ID, and the dcb/dcz content-encodings) and the merged HTML change whatwg/html#11620 ("Set the destination instead of initiator" for load a compression dictionary; No-CORS → Anonymous). Flags confirmed in Blink's runtime_enabled_features.json5: base CompressionDictionaryTransport (shipped, Chrome 130) plus the three experimental v156 alignment features — CDTNewDestination, CDTNewCrossOriginHandling, CDTNewReferrerAndReferrerPolicyHandling. Enable with --enable-features=CompressionDictionaryTransport and --enable-blink-features=CDTNewDestination,CDTNewCrossOriginHandling,CDTNewReferrerAndReferrerPolicyHandling (or --enable-experimental-web-platform-features), in a secure context. This is an HTTP/header feature, so two concepts need a server echo route (spec queued for the reviewer to wire in server.ts); the third is fully client-observable. Portfolio: basic/exact-change (link-request-semantics), practical negotiation walkthrough (dictionary-negotiation), capability/edge probe (client-observable-probe).

references