Compression Dictionary Readiness Checker

Test any website for Compression Dictionary Transport: dictionary links, Use-As-Dictionary, Vary headers, Brotli, Zstandard, DCB and DCZ. Free, no sign-up.

Fetched server-side from Cubbbix, so no CORS limits. Only public http and https URLs are accepted; private addresses are refused. Nothing is stored.

How the score is calculated

The score is public on purpose: every check and its weight is listed here, so a low score tells you exactly what to fix. Encoding checks read the page response itself.

CheckPointsWhat passes
Secure context (HTTPS)10Page served over HTTPS. Dictionaries only work in secure contexts.
Brotli encoding10Page Content-Encoding includes br.
Zstandard encoding10Page Content-Encoding includes zstd.
Dictionary link present20A Link header or link tag with rel="compression-dictionary".
Dictionary serves Use-As-Dictionary20The dictionary response carries Use-As-Dictionary with a match pattern.
Correct Vary header10Vary includes both accept-encoding and available-dictionary.
CSP allows dictionary fetch10No CSP, or connect-src allows the dictionary host.
DCB or DCZ actually served10Page Content-Encoding includes dcb or dcz.

Grades: 80 to 100 is ready, 40 to 79 is partial, below 40 is not ready. Available-Dictionary negotiation is deliberately not scored: it is a request header the browser sends, and only a client-side test can observe it. That test is the next tool in this family.

What Compression Dictionary Transport actually does

Normal compression starts from nothing on every response. CDT lets the browser reuse something it already downloaded as the dictionary for the next response. Ship app-v1.js, then serve app-v2.js compressed against v1 as its dictionary, and a repeat visitor downloads only the difference. The same idea works for shared page templates: one dictionary built from your common HTML, reused across every page. In one lab test reported by Cloudflare, a 272 KB script compressed to 92.2 KB with gzip and to 2.6 KB with dcz against its previous version. Your numbers depend on how much actually changed, but for frequent small deploys the ratio is the whole point.

Dictionaries must be same-origin with the resources they compress, dictionary responses must be served over HTTPS, and a dictionary-compressed response must carry the right Vary header or caches will serve it to the wrong browsers. Get those three rules right and the rest is plumbing: publish a dictionary, point at it with a link, and serve dcb or dcz to browsers that ask for it.

How to fix a failing check

  1. Serve the site over HTTPS if it is not already. Nothing else in CDT works without it.
  2. Publish a dictionary file and reference it with a Link header or a link tag: rel="compression-dictionary".
  3. Serve that dictionary with Use-As-Dictionary and a match pattern covering the resources it applies to, for example match="/js/*".
  4. Add Vary: accept-encoding, available-dictionary to every dictionary-compressed response.
  5. If you set a Content Security Policy, make sure connect-src allows the dictionary URL, or the browser will refuse to fetch it.
  6. Precompress one delta per release for your largest versioned bundle, then measure transfer size in DevTools on a repeat visit.

Frequently Asked Questions

Related Developer Tools

Was this tool helpful?

Comments

Loading comments...

Check Out Other Popular Tools