問題: より多くの配信 = キャッシュの減少
エージェント型クローラー、ブラウザ、その他のツールは繰り返しエンドポイントにアクセスし、情報の一部を抽出するために完全なページを取得します。2026年3月のCloudflareネットワーク全体のリクエストのうち、エージェント型アクターは総リクエストの10%弱を占め、前年比で約60%増加しました。配信されるすべてのページは昨年より重く、機械によって以前よりも頻繁に読まれています。
しかし、エージェントはウェブを消費しているだけでなく、ウェブの構築を支援しています。AI支援開発により、チームはより速く配信できます。デプロイ、実験、反復の頻度を増やすことは製品の速度向上に優れていますが、キャッシュにとっては悪いことです。エージェントが1行の修正をプッシュすると、バンドラーが再チャンク化し、ファイル名が変わり、地球上のすべてのユーザーがアプリケーション全体を再ダウンロードする可能性があります。コードが実質的に異なるからではなく、ブラウザ/クライアントが具体的に何が変わったかを知る方法がないからです。新しいURLが表示され、ゼロから始まります。
従来の圧縮は各ダウンロードのサイズに役立ちますが、冗長性には対応できません。クライアントがすでにファイルの95%をキャッシュしていることを知りません。したがって、すべてのデプロイ、すべてのユーザー、すべてのボットにおいて、冗長なバイトが何度も送信されます。1日に10個の小さな変更を配信すると、実質的にキャッシュをオプトアウトしたことになります。これはハードウェアが急速にボトルネックになっているウェブで、帯域幅とCPUを浪費します。
より多くのリクエストがより重いページにヒットし、より頻繁に再デプロイされるウェブでスケーリングするために、圧縮はより賢くなる必要があります。
共有辞書とは何か?
圧縮辞書は、サーバーとクライアント間の共有参照で、チートシートのように機能します。ゼロから応答を圧縮する代わりに、サーバーは「以前キャッシュしたため、ファイルのこの部分はすでに知っている」と言い、新しい部分だけを送信します。クライアントは同じ参照を保持し、解凍中に完全な応答を再構築するために使用します。
辞書がファイル内のコンテンツを参照できるほど多いほど、クライアントに転送される圧縮出力は小さくなります。すでに知られているものに対して圧縮するこの原則は、最新の圧縮アルゴリズムが前身より優れている方法です。
- Brotli: HTML属性や一般的なフレーズなどの一般的なウェブパターンの組み込み辞書を搭載しています
- Zstandard: カスタム辞書用に目的別に設計されています。代表的なコンテンツサンプルをフィードでき、提供するコンテンツの種類に最適化された辞書を生成します
- Gzip: どちらもありません。圧縮中にリアルタイムでパターンを見つけることで辞書を構築する必要があります
これらの「従来の圧縮」アルゴリズムは既にCloudflareで利用可能です。
共有辞書はこの原則をさらに一歩進めます。以前キャッシュされたリソースのバージョンが辞書になります。チームが1行の修正を配信し、すべてのユーザーが完全なバンドルを再ダウンロードするデプロイの問題を覚えていますか? 共有辞書を使用すると、ブラウザはすでに古いバージョンをキャッシュしています。サーバーはそれに対して圧縮し、差分だけを送信します。1行の変更を含む500KBバンドルは、ワイヤ上でわずか数キロバイトになります。
100,000人の日次ユーザーと1日10回のデプロイで、これは500GBの転送と数百メガバイトの差です。
デルタ圧縮
デルタ圧縮は、ブラウザが既に持っているバージョンを辞書に変えるものです。プロトコルはサーバーがリソースを最初に提供するときを見て、Use-As-Dictionaryレスポンスヘッダーを添付し、ブラウザに本質的にファイルを保持するよう指示します。これは後で役立つからです。
そのリソースの次のリクエストで、ブラウザはAvailable-Dictionaryヘッダーを送り返し、サーバーに「これが私が持っているものです」と伝えます。サーバーは新しいバージョンを古いバージョンに対して圧縮し、差分だけを送信します。別の辞書ファイルは必要ありません。
これが実際のアプリケーションの見返りが実現する場所です。バージョン管理されたJSバンドル、CSSファイル、フレームワークの更新、およびリリース間で段階的に変わるすべてのもの。ブラウザはapp.bundle.v1.jsをすでにキャッシュしており、開発者が更新を行い、app.bundle.v2.jsをデプロイします。デルタ圧縮はこれらのバージョン間の差分だけを送信します。その後のすべてのバージョンも差分です。バージョン3はバージョン2に対して圧縮されます。バージョン47はバージョン46に対して圧縮されます。節約はリセットされず、リリース履歴全体で持続します。
静的でないコンテンツのカスタムおよび動的辞書についても、コミュニティで活発な議論があります。これは将来の作業ですが、その影響は重大です。
なぜ待つのか?
共有辞書がそれほど強力なら、なぜ誰もがすでに使用していないのでしょうか?
それは、最後に試されたとき、実装がオープンウェブとの接触に耐えられなかったからです。Googleは2008年にChrome内でShared Dictionary Compression for HTTP (SDCH)を配信しました。初期採用者の中には、ページロード時間で2桁の改善を報告する人もいて、うまく機能しました。しかし、SDCHは誰もが修正できるより速く問題を蓄積しました。
最も記憶に残っているのは、圧縮サイドチャネル攻撃のクラス(CRIME、BREACH)でした。研究者は、攻撃者が機密情報(セッションクッキー、トークンなど)と一緒に圧縮されるコンテンツを注入できる場合、圧縮出力のサイズが秘密に関する情報を漏らす可能性があることを示しました。攻撃者は一度に1バイトを推測し、アセットサイズが縮小したかどうかを監視し、秘密全体を抽出するまで繰り返すことができます。
しかし、セキュリティは唯一の問題ではなく、採用が起こらなかった主な理由でもありませんでした。SDCHは同一オリジンポリシーの違反など、いくつかのアーキテクチャ上の問題を浮き彫りにしました(皮肉なことに、これは部分的にそれがそれほどうまく機能した理由です)。クロスオリジン辞書モデルはCORSと調整できず、キャッシュAPIなどのものとの相互作用に関する仕様が不足していました。しばらくして、採用の準備ができていないことが明らかになったため、2017年にChrome(当時唯一サポートしていたブラウザ)はそれをアンシップしました。
ウェブコミュニティがバトンを拾うのに10年かかりましたが、それだけの価値がありました。最新の標準であるRFC 9842: Compression Dictionary Transportは、SDCHを持続不可能にした主要な設計ギャップを閉じます。
例えば、アドバタイズされた辞書は同一オリジンからの応答でのみ使用可能であることを強制し、圧縮サイドチャネル攻撃を可能にした多くの条件を防ぎます。ChromeとEdgeはサポートを配信しており、Firefoxがそれに続くために機能しています。標準は広範な採用に向かっていますが、完全なクロスブラウザサポートはまだ追いついています。
RFCはセキュリティ問題を軽減しますが、辞書転送は常に実装が複雑でした。オリジンは辞書を生成し、正しいヘッダーで提供し、すべてのリクエストでAvailable-Dictionaryマッチをチェックし、応答をその場でデルタ圧縮し、クライアントが辞書を持たない場合は適切にフォールバックする必要があります。
キャッシュも複雑になります。応答はエンコーディングと辞書ハッシュの両方で異なるため、すべての辞書バージョンは個別のキャッシュバリアントを作成します。デプロイの途中で、古い辞書を持つクライアント、新しい辞書を持つクライアント、辞書を持たないクライアントがあります。キャッシュは各クライアント用に個別のコピーを保存しています。ヒット率は低下し、ストレージは増加し、辞書自体は通常のHTTPキャッシュルールの下で新鮮に保つ必要があります。
この複雑さは調整の問題です。そして、エッジに属する正確な種類のものです。CDNはすでにすべてのリクエストの前に位置し、すでに圧縮を管理し、すでにキャッシュバリアントを処理しています(近日公開予定のお知らせブログについてはこのスペースを見てください)。
Cloudflareが共有辞書サポートを構築する方法
共有辞書圧縮は、ブラウザとオリジン間のスタックのすべてのレイヤーに触れます。強い顧客の関心を見てきました。RFC著者Patrick Meenanのdictionary-workerのように、すでに独自の実装を構築した人もいます。これはWASM コンパイルされたZstandard を使用してCloudflare Worker内で完全な辞書ライフサイクルを実行します(例として)。
私たちはこれをすべての人がアクセスでき、実装できるだけ簡単にしたいと考えています。そのため、3つのフェーズでプラットフォーム全体にロールアウトしており、配管から始まります。
フェーズ1: パススルーサポート
現在、積極的に開発中です。Cloudflareは、Use-As-Dictionary、Available-Dictionary、dcbおよびdczコンテンツエンコーディングなど、共有辞書が必要とするヘッダーとエンコーディングを転送し、削除、変更、または再圧縮しません。キャッシュキーはAvailable-DictionaryとAccept-Encodingで異なるように拡張されるため、辞書圧縮応答は正しくキャッシュされます。
このフェーズは、オリジンで独自の辞書を管理する顧客に対応します。
2026年4月30日までにフェーズ1のオープンベータを準備する予定です。
これを使用するには、機能が有効になっているCloudflareゾーン、正しいヘッダー(Use-As-Dictionary、Content-Encoding: dcbまたはdcz)で辞書圧縮応答を提供するオリジン、および訪問者がAccept-Encodingでdcb/dczをアドバタイズし、Available-Dictionaryを送信するブラウザが必要です。
現在、これはChrome 130+とEdge 130+を意味し、Firefoxサポートが進行中です。
この機能が利用可能になったときと使用方法の詳細については、変更ログを注視してください。
初期テスト結果
私たちはすでに内部でパススルーのテストを開始しました。制御されたテストでは、2つのJSバンドルを順番にデプロイしました。それらはほぼ同じでしたが、同じウェブアプリケーションの連続したデプロイを表す、バージョン間のいくつかのローカライズされた変更を除いて。
非圧縮では、アセットは272KBです。Gzipはそれを92.1KBに削減し、66%の堅実な削減です。DCZ上の共有辞書圧縮を使用して、前のバージョンを辞書として使用すると、同じアセットは2.6KBに低下しました。これはすでに圧縮されたアセットに対して97%の削減です。
同じラボテストで、クライアントから2つのタイミングマイルストーンを測定しました。最初のバイトまでの時間(TTFB)と完全なダウンロード完了。
TTFB結果は、表示されていないことで興味深いです。キャッシュミス(DCZがオリジンで辞書に対して圧縮する必要がある場合)では、TTFBはgzipより約20ms遅いだけです。オーバーヘッドは送信に対してほぼ無視できます。
ダウンロード時間は違いがある場所です。
- キャッシュミス: DCZは31msで完了対gzipの166ms(81%改善)
- キャッシュヒット: 16msと143ms(89%改善)
応答がはるかに小さいため、開始時にわずかなペナルティを支払っても、はるかに先に終了します。
初期ラボ結果は最小限のJSバンドル差分をシミュレートしており、結果は辞書とアセット間の実際のデルタに基づいて異なります。
フェーズ2: Cloudflareが作業を行う
これは、Cloudflareがオリジンで辞書ヘッダー、圧縮、フォールバックロジックを処理する代わりに、どのアセットを辞書として使用するかをルール経由でCloudflareに指示し、残りを管理するフェーズです。
Use-As-Dictionaryヘッダーを注入し、辞書バイトを保存し、新しいバージョンをデルタ圧縮します。