Compression Dictionary Transport と呼ばれる新しい実験的なウェブ技術が開発者の間で激しい議論を呼んでおり、多くの開発者がその複雑性が約束された帯域幅節約を正当化するかどうかを疑問視している。この技術により、ウェブサイトは共有圧縮辞書を使用して HTTP レスポンスサイズを劇的に削減できるが、コミュニティからのフィードバックでは、実際の利益は宣伝されているほど印象的ではない可能性があることが示唆されている。
印象的な数値が控えめな実用的影響を隠している
宣伝例では JavaScript ファイルサイズの98%削減など劇的な圧縮改善を示しているが、開発者たちはこれらの利益がしばしば最小限の全体的な節約にしか変換されないことを指摘している。ある批評家は CNN の例を分析し、278KB の JavaScript ファイルが（標準的な Brotli で）90KB から辞書圧縮を使用してわずか2KBまで圧縮されたケースを調べた。これは98%の改善を表すが、実際に節約された帯域幅は CNN の総63.7MB ページロードのうちわずか88KB、つまり転送される総データの0.14%未満であった。
パーセンテージ改善と実用的利益の間のこの乖離により、この技術が正しい問題に対処しているかどうかについての議論が巻き起こっている。より効率的な圧縮を可能にするのではなく、一部の開発者は、この技術が単にウェブサイトの肥大化をネットワーク転送から辞書ストレージを通じてユーザーのハードドライブに移すことを促進するだけではないかと懸念している。
圧縮性能の例:
- CNN JavaScript: 278KB → 90KB (Brotli) → 2KB (辞書 + Brotli) = 98%改善
- 実際の帯域幅節約: 総ページ読み込み63.7MBのうち88KB (0.14%)
- 言及された辞書サイズ: 辞書あたり最大1MB
実装の複雑性が懸念を引き起こしている
この技術はサーバーとクライアントの両方に大きな複雑性をもたらす。サーバーは異なる辞書の組み合わせを使用してリソースの複数の圧縮バージョンを管理する必要があり、ストレージ要件が10倍以上増加する可能性がある。現在の静的リソースだけでなく、履歴バージョンや様々な辞書圧縮の組み合わせもキャッシュする必要がある。
「これは限定的な利益に対して多くの複雑性を追加するように思える。gzip と br を最高圧縮レベルで使用しても十分でないケースがあるのだろうか？」
クライアント側の実装には、新しい HTTP ヘッダー、辞書管理、キャッシュ分割ルールが含まれる。ブラウザはアイドル時間中に辞書をダウンロードして保存し、同一オリジンポリシーと CORS 制限を尊重しながら、将来のリクエストでの使用を調整する必要がある。
実装方法:
- 既存リソースを辞書として使用: パターンマッチングで
Available-Dictionaryヘッダーを使用 - 独立した辞書:
<link rel="compression-dictionary">またはLink:ヘッダーを使用 - サーバーストレージへの影響: キャッシュされたリソースの組み合わせが最大10倍に増加する可能性
- ブラウザサポート: 現在の実装が限定的な実験的技術
セキュリティとプライバシーへの影響
コミュニティは新技術に関するいくつかの潜在的リスクを特定している。辞書ベースの圧縮は新しい形のステガノグラフィーを可能にする可能性があり、悪意のある行為者が同じ圧縮ルールを維持しながら異なる辞書を使用して異なるメッセージを隠す可能性がある。これにより、一見無害な辞書ファイルを通じたマルウェア配布の可能性が開かれる。
この技術の追跡可能性からプライバシーの懸念も生じる。辞書はダウンロードしてキャッシュする必要があるため、ユーザー識別のための別のフィンガープリンティングベクターとして機能する可能性があり、プライバシー保護が有効になっている場合に特に問題となる。
技術要件:
- 同一オリジンポリシー：辞書はリソースと同じオリジンから提供される必要がある
- クロスオリジン辞書圧縮リソースには CORS 準拠が必要
- HTTP キャッシュ分割：辞書はオリジン間で共有できない
- 新しい HTTP ヘッダー：
Available-Dictionary、Dictionary-ID、Use-As-Dictionary - サポートされるアルゴリズム： Brotli ( dbr )および Zstandard ( dzd )
限定的な使用ケースが有望性を示している
批判にもかかわらず、一部の開発者は特定のシナリオで価値を見出している。段階的に変更される頻繁に更新される JavaScript バンドルを持つアプリケーションは、以前のバージョンを辞書として使用するデルタ圧縮から大きな恩恵を受ける可能性がある。頻繁で長時間接続される API も意味のある改善を見る可能性がある。
Cloudflare などのクラウドサービスは、この技術を透過的に実装するのに適した位置にあるようで、開発者からの手動設定を必要とせずに、一般的なウェブサイトレスポンスを分析して最適化されたサイト固有の辞書を構築する可能性がある。
この技術は2013年に取り消された失敗した SDCH（Shared Dictionary Compression over HTTP）標準からの進化を表しているが、その前身を悩ませた実用的制限を克服できるかどうかは未だ不明である。ブラウザが実験的実装を開始する中、実世界でのテストが Compression Dictionary Transport がその複雑性を正当化する意味のある利益を提供できるかどうかを決定するだろう。