demo · v130
library version evolution
The chromestatus motivation cites "incremental library updates" as the primary win. Walk through a real-world JavaScript bundle through four versions — each adding a few lines, fixing a bug, or bumping a feature flag — and watch the dictionary-compressed delta stay tiny while plain brotli still re-ships the whole file every time.
pick a version to fetch (cursor: the previous version is the dictionary)
dictionary cache scenario
app.v?.js — diff vs advertised dictionary highlighted
compressed byte savings by version pair
what the wire looks like
why this is the killer use case
Most production sites version their app bundle by content hash and ship a fresh full file on every deploy. The bundle is mostly framework code that didn't change — React, your design system, your routing — with a tiny delta of your application logic. Brotli compresses each bundle in isolation: every deploy is a fresh hundreds-of-kB download.
Shared brotli (dcb) lets the browser reuse the previous version it already has on disk as a dictionary. The diff that gets transferred is the size of the actual code change, not the full bundle. The bigger the static framework portion and the smaller the change, the better the ratio.
Cloudflare's published case study on this measured a 99.8% reduction on a Three.js update — 1.5 MB down to 7 kB — and 72% even for a minor Angular bump where most of the change was internal refactoring. The browser had the dictionary cached from the user's previous visit; the only thing transferred was the patch.