Klassische Kompression behandelt jede Antwort wie ein unbeschriebenes Blatt. Brotli oder Zstandard komprimieren das JavaScript-Bundle gegen ein eingebautes Standard-Wörterbuch - ohne zu wissen, dass der Browser die Vorgängerversion derselben Datei längst im Cache liegen hat. Nach jedem Deploy lädt der wiederkehrende Nutzer deshalb das komplette Bundle erneut, obwohl sich vielleicht drei Prozent des Codes geändert haben. Genau diese Lücke schließt Compression Dictionary Transport. Das Verfahren wurde im September 2025 als RFC 9842 auf dem Standards Track verabschiedet (IETF RFC 9842) und ist in Chrome und Edge ab Version 130 verfügbar (Can I use). Der Browser meldet über den Available-Dictionary-Header, welche Vorgängerversion er vorhält; der Server antwortet mit einem gegen dieses Wörterbuch komprimierten Delta. Laut MDN lässt sich damit eine um Größenordnungen bessere Kompression erreichen als mit dem eingebauten Standard-Wörterbuch (MDN Web Docs). Dieser Artikel zeigt die beiden Praxis-Muster, die nötige Server-Konfiguration, die Cache-Fallstricke und die ehrliche Antwort auf die Frage, wo sich der Aufwand rechnet.
Das Wichtigste in Kürze
- Compression Dictionary Transport ist seit September 2025 als RFC 9842 standardisiert und in Chrome und Edge ab Version 130 verfügbar (Can I use). Der Algorithmus bleibt Brotli oder Zstandard - neu ist nur das Wörterbuch, gegen das komprimiert wird.
- Muster 1 nutzt die Vorgängerversion desselben Bundles als Wörterbuch: Ein Frontend-Bundle sank von 344 KB mit Brotli auf 128 KB als Delta, also um 63 Prozent (WICG). Je kürzer der Abstand zwischen zwei Releases, desto kleiner das Delta.
- Muster 2 baut ein statisches Wörterbuch für dynamisches HTML. Google Search senkte damit die HTML-Auslieferung um 23 Prozent gegenüber Brotli und den LCP um 1,7 Prozent, auf Verbindungen mit hoher Latenz um bis zu 9 Prozent (Chrome for Developers).
- Die Einrichtung besteht aus dem Use-As-Dictionary-Header mit URL-Muster, HTTPS als Pflicht und Vary: Accept-Encoding, Available-Dictionary auf jeder cachefähigen Antwort. Der SHA-256-Hash im Kopf jeder Delta-Antwort deckt unpassende Wörterbücher sofort auf.
- Der Preis liegt in der Zwischenschicht: Halten Nutzer verschiedene Vorgängerversionen im Cache, entsteht pro Version eine eigene Cache-Variante derselben URL. Deshalb wird das Delta oft an der Kante berechnet oder die Zahl der Vorgängerversionen begrenzt.
- Browser ohne Unterstützung senden keinen Wörterbuch-Header und bekommen die gewöhnliche Brotli- oder Gzip-Antwort; die Abdeckung liegt global bei rund 69 Prozent (Can I use). Bei kleinen Bundles oder seltenen Deploys bleibt der Nutzen nahe null.
Warum jeder Deploy das komplette Bundle neu kostet
Moderne Frontends liefern ihr JavaScript unter gehashten Dateinamen aus: app.9f2c1d.js wird mit Cache-Control: immutable für ein Jahr im Browser-Cache abgelegt. Das ist korrekt und schnell - solange nichts deployt wird. Ändert sich eine einzige Zeile, ändert sich der Hash, die URL ist eine andere, und der Cache-Eintrag der alten Datei wird schlicht wertlos. Der Browser lädt die neue Datei vollständig, obwohl er einen Großteil ihres Inhalts bereits gespeichert hat. Bei wöchentlichen Deploys zahlt ein wiederkehrender Nutzer diesen vollen Preis jede Woche erneut.
Der Effekt skaliert mit der Bundle-Größe, und die wächst in vielen Projekten weiter. Sichtbar wird das Problem selten im Labor, sondern im Feld: bei Nutzern auf Mobilfunk, in Randlagen und auf älteren Geräten, wo jedes zusätzliche Kilobyte spürbar Zeit kostet. Wer sein Frontend über JavaScript-Performance-Budgets steuert, kennt die Mechanik: Die Transfergröße des Hauptbundles begrenzt, wie früh die Seite interaktiv wird - und damit auch, wie die Core Web Vitals im Feld ausfallen.
Der wiederkehrende Nutzer ist der übersehene Fall
Nicht der Algorithmus, sondern das Wörterbuch
Hier lohnt eine saubere Abgrenzung, weil das Thema häufig mit der Algorithmuswahl vermischt wird. Ob Gzip, Brotli oder Zstandard die kleinste Datei liefert und wie die Content-Encoding-Verhandlung abläuft, ist eine eigene Frage - beantwortet im Beitrag zu Brotli und Zstandard als Textkompression. Compression Dictionary Transport ändert den Algorithmus nicht. Es ändert das Wörterbuch, gegen das komprimiert wird.
Jeder Kompressor ersetzt wiederkehrende Byte-Folgen durch Rückverweise auf bereits Gesehenes. Brotli bringt dafür ein eingebautes Standard-Wörterbuch mit häufigen Web-Fragmenten mit - aber es kennt weder Ihren Framework-Code noch Ihre Klassennamen. Ein Wörterbuch, das aus Ihrer eigenen Vorgängerversion besteht, kennt beides exakt. Der Kompressor muss dann nicht mehr die Datei beschreiben, sondern nur noch ihren Unterschied zur bekannten Version. Deshalb spricht die Spezifikation von Delta-Kompression, und deshalb sind die Sprünge so groß: Die Kompression startet nicht bei null, sondern kurz vor dem Ziel.
Was hier neu ist - und was nicht
dcb für Dictionary-Compressed Brotli und dcz für Dictionary-Compressed Zstandard (IETF RFC 9842). Beide nutzen dieselben Kompressionsverfahren wie bisher, nur eben mit einem externen Wörterbuch. Eine dcb-Antwort beginnt mit einem 36 Byte langen Kopf, der vier Magic-Bytes und den 32 Byte langen SHA-256-Hash des verwendeten Wörterbuchs enthält (IETF RFC 9842); bei dcz sind es 40 Byte. So kann der Client vor dem Dekomprimieren prüfen, ob er wirklich das passende Wörterbuch hat.Der Ablauf einer Delta-Antwort
Der Austausch läuft in drei Schritten und kommt ohne Client-JavaScript aus. Zuerst markiert der Server eine ausgelieferte Datei per Use-As-Dictionary-Header als Wörterbuch-Kandidat. Der Pflichtparameter match ist ein URL-Pattern - reguläre Ausdrücke sind ausdrücklich ausgeschlossen (IETF RFC 9842) - und beschreibt, für welche künftigen Anfragen diese Datei als Wörterbuch dienen darf. Optional grenzt match-dest auf bestimmte Fetch-Ziele ein, etwa nur auf Skripte, und id gibt dem Server einen eigenen Bezeichner von bis zu 1024 Zeichen mit (IETF RFC 9842), den der Client später per Dictionary-ID zurückspiegelt.
Beim nächsten Deploy fragt der Browser die neue, anders gehashte Datei an. Passt sie auf das gespeicherte match-Muster, sendet er zusätzlich zum erweiterten Accept-Encoding den Available-Dictionary-Header mit dem SHA-256-Hash genau eines Wörterbuchs - des am besten passenden (IETF RFC 9842). Der Server erkennt daran, welche Vorgängerversion der Client besitzt, komprimiert die neue Datei gegen diese und antwortet mit Content-Encoding: dcb. Der Browser rekonstruiert daraus die vollständige Datei; über die Leitung ging nur das Delta.
# 1) Der Server markiert das ausgelieferte Bundle als Wörterbuch-Kandidat
HTTP/2 200 OK
Content-Type: application/javascript
Content-Encoding: br
Use-As-Dictionary: match="/assets/app.*.js", match-dest=("script")
Cache-Control: public, max-age=31536000, immutable
# 2) Nächster Deploy: der Browser meldet, welches Wörterbuch er im Cache hat
GET /assets/app.9f2c1d.js HTTP/2
Accept-Encoding: dcb, dcz, br, gzip
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
# 3) Der Server antwortet mit dem Delta gegen genau dieses Wörterbuch
HTTP/2 200 OK
Content-Type: application/javascript
Content-Encoding: dcb
Vary: Accept-Encoding, Available-DictionaryZwei Randbedingungen sind nicht verhandelbar. Das Verfahren funktioniert ausschließlich in sicheren Kontexten, also über HTTPS (IETF RFC 9842). Und Wörterbücher sind an ihren Origin gebunden: Das match-Muster kann nur Ressourcen desselben Origin treffen, und der Cache partitioniert sie. Die Spezifikation verlangt sogar, dass Clients Wörterbücher wie Cookies behandeln - inklusive Partitionierung und Löschung, wenn Cookies gelöscht werden (IETF RFC 9842). Ein Wörterbuch ist damit kein Tracking-Vektor über Website-Grenzen hinweg.
Muster 1: Delta gegen die Vorgängerversion
Das erste und einfachere Muster braucht keine zusätzliche Datei: Das Wörterbuch ist die alte Version des Bundles, die der Nutzer ohnehin schon geladen hat. Es passt zu gehashten Build-Assets - dem Haupt-JavaScript, dem CSS, großen Vendor-Chunks. Der Charme liegt darin, dass das Wörterbuch beim Deploy von selbst entsteht: Jede ausgelieferte Version ist automatisch der Wörterbuch-Kandidat für die nächste.
Die Beispielsammlung des WICG-Projekts zeigt, wie groß der Unterschied ausfällt. Das React-Bundle eines Nachrichtenportals schrumpfte über ein Jahr Versionsabstand von 344 KB mit Brotli auf 128 KB als Delta - 63 Prozent weniger (WICG compression-dictionary-transport). Ein Header-Bundle derselben Website fiel von 90 KB auf 2 KB, also um 98 Prozent (WICG compression-dictionary-transport). Bei einem großen Video-Player sank die Auslieferung von 1,8 MB Brotli auf 384 KB über einen Quartalsabstand - und auf 172 KB, also 90 Prozent weniger, wenn nur eine Woche zwischen den Versionen lag (WICG compression-dictionary-transport). Chrome for Developers rechnet dasselbe an einer verbreiteten Bibliothek vor: Version 1.8.3 gegen 1.7.9 als Wörterbuch komprimiert ergibt gut 4 KiB statt 53 KiB mit gewöhnlichem Brotli - eine Kompressionsrate von nahezu 98 Prozent (Chrome for Developers).
Je kürzer der Abstand zwischen zwei Versionen, desto kleiner das Delta. Häufiges Deployen ist bei diesem Muster kein Nachteil, den man abfedern muss - es ist die Voraussetzung, unter der es am besten funktioniert.
Diese Zahlen erklären auch, warum das Muster mit Code-Splitting harmoniert: Kleine, stabile Chunks erzeugen winzige Deltas, während ein einziges Monolith-Bundle bei jeder Änderung neu bewertet wird. Wie sich Bundles sinnvoll schneiden lassen, behandelt der Beitrag zu Lazy Loading und Code-Splitting.
Muster 2: Statisches Wörterbuch für wiederkehrende Fragmente
Das zweite Muster zielt auf Inhalte, die keine Vorgängerversion haben, sich aber stark ähneln: Produktdetailseiten, Suchergebnisse, Listenansichten. Jede dieser HTML-Antworten ist einzigartig, doch der Rahmen - Navigation, Footer, Markup-Gerüst, wiederkehrende Klassennamen - ist über tausende Seiten fast identisch. Hier baut man eine eigene Wörterbuch-Datei aus einer repräsentativen Stichprobe echter Seiten, liefert sie einmal aus und referenziert sie per Link: rel="compression-dictionary" oder <link rel="compression-dictionary">. Danach werden alle passenden HTML-Antworten gegen dieses Wörterbuch komprimiert.
Der prominenteste Praxisfall ist Google Search selbst, das seit Frühjahr 2025 ein statisches Wörterbuch aus einer Stichprobe echter Ergebnisseiten einsetzt und es über eine automatisierte Pipeline mehrmals täglich aktuell hält. Über alle Chrome-Nutzer hinweg sank die durchschnittliche HTML-Auslieferung dadurch um 23 Prozent (Chrome for Developers) gegenüber gewöhnlichem Brotli; der Largest Contentful Paint verbesserte sich um 1,7 Prozent insgesamt und um bis zu 9 Prozent auf Verbindungen mit hoher Latenz (Chrome for Developers). Bemerkenswert ist die Einordnung der Autoren: Diese Gewinne entstanden auf einer bereits hochoptimierten Seite - weniger optimierte Websites hätten entsprechend mehr Spielraum (Chrome for Developers).
Die WICG-Sammlung bestätigt das für Shop-Seiten. Mit einem 1 MB großen Wörterbuch fielen Produktseiten eines großen Marktplatzes von 84 KB auf 10 KB Transfergröße, andere Beispiele liegen zwischen 60 und 90 Prozent Ersparnis; Suchergebnisseiten wurden um 30 bis 66 Prozent kleiner (WICG compression-dictionary-transport). Für dynamisches HTML ist das der interessantere Hebel, weil er auch beim ersten Aufruf einer Unterseite greift - anders als beim Delta-Muster, das erst ab dem zweiten Deploy zahlt. In Single-Page-Anwendungen lohnt der Blick zusätzlich auf die Messseite: Wie sich Vitals über Ansichtswechsel hinweg überhaupt erfassen lassen, zeigt der Beitrag zu Soft Navigations in SPAs.
| Kriterium | Delta gegen Vorgängerversion | Statisches Wörterbuch |
|---|---|---|
| Das Wörterbuch ist | die alte Version derselben Datei | eine eigens gebaute Sammeldatei |
| Bekanntmachung | Use-As-Dictionary auf dem Asset | Link: rel=compression-dictionary |
| Ideal für | gehashte Build-Bundles (JS, CSS) | HTML-Fragmente, Produkt- und Listenseiten |
| Beim ersten Besuch | kein Gewinn, normale Brotli-Antwort | Wörterbuch wird einmal zusätzlich geladen |
| Belegte Ersparnis | 63 bis 98 Prozent (WICG) | 30 bis 66 Prozent bei Suchergebnissen (WICG) |
| Pflegeaufwand | entsteht automatisch beim Deploy | Pipeline muss das Wörterbuch aktuell halten |
Server-Konfiguration und Integritätsprüfung
Die Konfiguration besteht aus drei Bausteinen: die Wörterbuch-Kandidaten korrekt auszeichnen, die Delta-Kompression bereitstellen und die Caches sauber trennen. Der erste Baustein ist reine Header-Arbeit und lässt sich in nginx oder auf der Anwendungsebene erledigen. Der zweite verlangt, dass die ausliefernde Schicht dcb beziehungsweise dcz erzeugen kann - entweder vorberechnet zur Build-Zeit für bekannte Versionspaare oder in Echtzeit an der Kante.
# Muster 1: gehashte Build-Assets als Wörterbuch für den nächsten Deploy anbieten
location ~ ^/assets/app\..+\.js$ {
add_header Use-As-Dictionary 'match="/assets/app.*.js", match-dest=("script")' always;
add_header Vary "Accept-Encoding, Available-Dictionary" always;
add_header Cache-Control "public, max-age=31536000, immutable" always;
}
# Muster 2: separates, statisches Wörterbuch für HTML-Fragmente ausliefern
location = /dictionaries/shell.dat {
add_header Use-As-Dictionary 'match="/produkt/*", match-dest=("document")' always;
add_header Cache-Control "public, max-age=2592000" always;
}
# Im Dokument bekannt machen - per Link-Header oder <link rel="compression-dictionary">
# Link: </dictionaries/shell.dat>; rel="compression-dictionary"Die Integritätsprüfung ist dabei kein Extra, sondern eingebaut: Weil der SHA-256-Hash des Wörterbuchs im Kopf jeder dcb- und dcz-Antwort steht (IETF RFC 9842), erkennt der Client sofort, wenn Antwort und Wörterbuch nicht zusammenpassen - etwa weil ein Cache eine falsche Variante ausgeliefert hat. Für dcz schreibt die Spezifikation zusätzlich vor, dass Dekompressionsfenster von mindestens 8 MB oder dem 1,25-fachen der Wörterbuchgröße unterstützt werden, gedeckelt bei 128 MB (IETF RFC 9842). Wer Wörterbücher plant, dimensioniert sie also bewusst und nicht beliebig groß.
-
Use-As-Dictionarynur auf Dateien setzen, die als Wörterbuch taugen - versionierte Bundles, nicht jede Kleindatei -
match-Muster eng fassen und mitmatch-destauf das passende Fetch-Ziel eingrenzen -
Vary: Accept-Encoding, Available-Dictionaryauf jeder cachefähigen Delta-Antwort senden - Wörterbuch-Größe gegen den Nutzen abwägen - größer ist nicht automatisch besser
- Für Muster 2 die Wörterbuch-Erzeugung automatisieren, damit sie nicht veraltet
- Nach dem Rollout mit echten Antworten prüfen, welches
Content-Encodingtatsächlich ankommt
Cache-Fallstricke: Vary und die Varianten-Explosion
Der heikelste Teil sitzt nicht im Browser, sondern in der Zwischenschicht. Eine dcb-Antwort ist nur für genau den Client verwertbar, der genau dieses Wörterbuch besitzt. Liefert ein CDN sie versehentlich an einen anderen Nutzer aus, kann dieser sie nicht dekomprimieren. Deshalb verlangt die Spezifikation für cachefähige Antworten zwingend einen Vary-Header, der Caches daran hindert, wörterbuchkomprimierte Antworten an Clients ohne passendes Wörterbuch auszuliefern (IETF RFC 9842). In der Praxis lautet er Vary: Accept-Encoding, Available-Dictionary (MDN Web Docs).
Jede Wörterbuch-Version erzeugt eine eigene Cache-Variante
Vary cacht, kann so ihre Trefferquote verlieren. Deshalb wird dcb für stark geteilte Objekte oft an der Kante berechnet statt vorgehalten - oder man begrenzt bewusst, gegen wie viele Vorgängerversionen überhaupt Deltas angeboten werden.Das macht die Einführung zu einer Architektur- und nicht zu einer Header-Entscheidung. Wer eine mehrstufige Cache-Landschaft betreibt, sollte vorher klären, wie Edge-Caching im Shop mit den zusätzlichen Varianten umgeht und ob die Kante die Kompression selbst übernehmen kann. Für vorgelagerte Caches im eigenen Stack gilt dasselbe Prinzip wie bei anderen variantenreichen Antworten - siehe Caching-Strategien mit Varnish und Redis.
Der Fallback für Browser ohne Unterstützung
Compression Dictionary Transport ist ein Fall von progressiver Verbesserung, und das ist der beruhigende Teil. Ein Browser ohne Unterstützung sendet weder Available-Dictionary noch dcb im Accept-Encoding - und bekommt damit automatisch die gewöhnliche Brotli- oder Gzip-Antwort. Es gibt keinen Sonderpfad, den man bauen müsste, und keinen Nutzer, der ausgeschlossen wird. Der Fallback ist die bestehende Kompression.
Realistisch bleibt die Reichweite eine Teilmenge. Unterstützt wird das Verfahren in Chrome und Edge ab Version 130 sowie in weiteren Chromium-Browsern; Firefox und Safari liefern derzeit keine Unterstützung, woraus sich eine globale Abdeckung von rund 69 Prozent ergibt (Can I use). Für einen Teil der Nutzer ändert sich also nichts - und der andere Teil profitiert, ohne dass jemand ein Risiko trägt. Das ist ein ähnlich asymmetrisches Nutzen-Risiko-Verhältnis wie bei jeder gestaffelten Kompressionskette aus Brotli, Zstandard und Gzip.
- Client unterstützt dcb und hat ein passendes Wörterbuch: Delta-Antwort, kleinste Übertragung
- Client unterstützt dcb, hat aber kein passendes Wörterbuch: gewöhnliche Brotli-Antwort
- Client unterstützt Brotli, aber keine Wörterbücher: gewöhnliche Brotli-Antwort
- Client ohne Brotli oder über unverschlüsselte Verbindung: Gzip-Antwort
- Zwischencache ohne Varianten-Trennung: konservativ auf die nicht-wörterbuchbasierte Variante zurückfallen
Wo sich der Aufwand lohnt - und wo nicht
Das Verfahren ist kein Standardschritt für jede Website, und es als solchen zu verkaufen wäre unredlich. Der Gewinn entsteht aus dem Zusammenspiel dreier Faktoren: Wie groß ist das Bundle, wie oft wird deployt, und wie viele Nutzer kommen wieder? Fällt einer dieser Faktoren klein aus, bleibt vom Effekt wenig übrig. Eine Broschüren-Website mit 60 KB JavaScript und zwei Deploys im Jahr gewinnt nichts Messbares - hier liegen die Hebel bei Bildern, Schriften und Server-Antwortzeit.
Häufiger Deploy-Rhythmus
Je kürzer der Abstand zwischen zwei Versionen, desto kleiner das Delta - im Wochenabstand belegen die Beispiele bis zu 90 Prozent Ersparnis gegenüber Brotli (WICG compression-dictionary-transport). Wer täglich ausliefert, hat den Effekt bereits eingebaut.
Große Bundles mit stabilem Kern
Shops und SaaS-Oberflächen tragen umfangreiche Frameworks und Vendor-Chunks, die sich zwischen Releases kaum ändern. Genau dieser stabile Anteil wird zum Delta zusammengefaltet, während sich der geänderte Rest normal komprimiert.
Kontrolle über Header und Kante
Nötig sind HTTPS, eigene Response-Header und eine Cache-Schicht, die Varianten sauber trennt (IETF RFC 9842). Wo diese Kontrolle fehlt - etwa bei starrem Fremd-Hosting - ist das Verfahren praktisch kaum sauber umsetzbar.
Ebenso ehrlich gehört die Gegenseite benannt. Bei seltenen Deploys, kleinen Bundles oder überwiegend neuen Besuchern liegt der Nutzen nahe null. Wo die Cache-Landschaft komplex ist, kann die Varianten-Trennung mehr Aufwand kosten, als die Bytes einbringen. Und wenn ein Shop primär unter Backend-Zeit leidet, hilft ein kleineres Bundle wenig - dann zählen Datenbank, Rendering und Antwortzeit zuerst, wie bei Shopware-Performance regelmäßig sichtbar wird. Ein zusätzlicher Aspekt betrifft die Serverlast automatisierter Zugriffe: Wörterbücher wirken für Nutzer mit Cache, nicht für die wachsende Zahl an KI-Crawlern ohne Cache-Historie.
Einordnung in den Kompressions-Stack
Shared Dictionaries ersetzen nichts - sie setzen eine Ebene obendrauf. Brotli auf Maximalstufe bleibt die richtige Antwort für statische Assets, zstd oder mittleres Brotli für dynamische Antworten, Gzip die universelle Rückfallebene. Compression Dictionary Transport fügt dieser Staffel eine vierte, spezialisierte Stufe hinzu, die nur dann greift, wenn Client und Server ein gemeinsames Wörterbuch haben. Alles andere läuft unverändert weiter.
Die sinnvolle Reihenfolge ist deshalb klar: erst die Grundlagen - Kompression überhaupt aktiv, Assets vorkomprimiert, Cache-Header korrekt, Bundle sinnvoll geschnitten -, dann diese Ebene. Wer sie zu früh einzieht, optimiert das Delta eines Bundles, das schlicht zu groß ist. In unseren Projekten bewerten wir deshalb zuerst Bundle-Struktur und Deploy-Rhythmus in einer technischen Analyse und entscheiden daraus, ob sich die Wörterbuch-Auslieferung rechnet. Fällt die Antwort positiv aus, richten wir sie samt Fallback als Teil der Frontend-Optimierung ein und messen den Transfergewinn an echten Antworten - eingebettet in die übrigen Performance-Leistungen rund um Server, Caching und Auslieferung.
Quellen und Studien
Available-Dictionary-Header und erhalten die gewöhnliche Brotli- oder Gzip-Antwort.dcb oder dcz erzeugen und pro Wörterbuch-Variante sauber cachen - gesteuert über Vary: Accept-Encoding, Available-Dictionary (MDN Web Docs). Fehlt diese Kontrolle, etwa bei starrem Fremd-Hosting, bleibt das Verfahren praktisch außer Reichweite. Dann bringen vorkomprimierte Assets und saubere Cache-Header meist mehr als der Versuch, Wörterbücher nachzurüsten.