圧縮辞書による Google 検索の改善

Carlos Mateo Muñoz

Barry Pollard

公開日: 2025 年 5 月 14 日

圧縮辞書転送は、リクエスト間で繰り返されるコンテンツを圧縮できる新しい標準で、2024 年後半に Chrome 130 でリリースされました。Google 検索は、この新しいテクノロジーを採用し、大幅な改善を実現しました。

YouTube が提供する機会

アクセスするウェブページには重複が多くあります。同じウェブサイトの多くのページは、HTML、CSS、JavaScript のいずれであっても、同じコードの大部分で構成されており、これらのコードの間のコンテンツのみが変更されています。各結果は、数百の機能の独自の組み合わせで、完全に一意のコンテンツになりますが、それらを生成するためにブラウザに送信されるコードには、多くの共通点があります。

視覚的には、入力された検索語句に関係なく、ほとんどの検索結果ページは多少似ています。上部には Google ロゴ、検索バー、いくつかのコントロールがあります。中央には、検索タイプ用のタブがあり、左側には検索結果のリストが、ユーザーを支援するさまざまなウィジェットと、右側には「概要」パネルの追加のコンテキストが配置されています。

最後に、下部にはページネーション オプションと標準のフッターがあります。これは視覚的に利用できるものにすぎません。このページを生成するために、多くのコード（HTML、CSS、JavaScript）が舞台裏で実行されています。このコードの多くは、パフォーマンスの最適化としてページの HTML に直接インライン化されています。これにより、ページ読み込みをすばやく行うことができますが、外部でキャッシュに保存されたリソースのように、異なる結果ページ間でコードを共有できないというデメリットがあります。

ウェブ上の圧縮

圧縮は、ウェブで広く使用されているテクノロジーです。gzip や、Brotli や Zstandard などの新しいアルゴリズムでリソースを圧縮すると、ファイル内の繰り返しを回避し、可逆圧縮を使用して、送信前にすべての情報をサーバーにできるだけコンパクトに格納できます。ブラウザは、圧縮されたバイトを解凍してオリジナル コンテンツを復元できます。画像の場合、不可逆圧縮では、ユーザーが認識できない可能性のある余分なバイトを削除することで、同様のメリットが得られます。

最近まで、ウェブ上の圧縮はリソース内の圧縮に限定されていました。異なるリソース間、ましてや異なるページ間で圧縮することはできませんでした。これは、ウェブ エンジニアが修正しようとしていた制限として、長らく認識されてきました。

圧縮辞書転送が救世主となる

圧縮辞書転送は、共有「辞書」を使用してリソース間で圧縮を可能にする新しい標準です。この辞書を使用すると、共通のバイト シーケンスをその共有辞書からの参照に置き換えることができます。

Brotli や Zstandard などの最新の圧縮アルゴリズムは、共通の用語の辞書の使用をサポートしています。これにより、これらの用語を辞書への小さな参照に置き換えることで、圧縮率を高めることができます。Brotli には、一般的なウェブ用語の組み込み辞書も付属しています。圧縮辞書転送は、サーバーとブラウザがカスタム辞書を共有する方法を提供することで、これを基盤として構築されています。

カスタム辞書は、サイトですでに使用されているリソースにすることもできます。たとえば、app.v2.js をダウンロードするときに app.v1.js を辞書として使用すると、基本的には差分のみをダウンロードできます（「デルタ圧縮」とも呼ばれます）。または、<link rel="compression-dictionary"> タグ（または同等の Link HTTP ヘッダー）を使用して、別の辞書リソースを指定することもできます。

これにより、前述の検索結果ページなど、共有コンテンツやコードが多いリソースのダウンロード サイズを大幅に削減できます。

Google 検索での圧縮辞書の使用

Google 検索チームは、検索のパフォーマンスの改善に継続的に取り組んでいます。このテクノロジーの可能性を見出し、圧縮辞書をいち早く採用しました。

検索では、検索結果の代表サンプルから作成された個別の辞書ファイルを使用して、結果ページに共有 Brotli 圧縮を使用します。堅牢な自動パイプラインにより、辞書は最新の状態に保たれ、1 日に複数回リリースされる SRP コンテンツの頻繁な変更に対応できます。DevTools を使用すると、これがどのように機能するかを正確に確認できます。

クライアントが最初に検索結果ページを読み込むと、サーバーは rel=compression-dictionary タイプの Link: HTTP ヘッダーを使用して辞書へのリンクを提供します。

クライアントが Brotli 辞書圧縮をサポートしているが、共有辞書をまだキャッシュしていない場合、ブラウザはアイドル時にこの辞書をダウンロードします。辞書レスポンスには、ブラウザがこの辞書を使用できるリソースを示す Use-As-Dictionary レスポンス ヘッダーが含まれています。

辞書は標準の cache-control セマンティクスを使用し、そのヘッダーで定義されたルールに一致するリソース（この例では /search で始まるページ）で使用できます。

今後の検索結果ページの読み込みでは、ブラウザは Available-Dictionary HTTP リクエスト ヘッダーを使用して、辞書があることをサーバーに通知できます。ページを再読み込みすると、実際の動作を確認できます。

[ログを保持] チェックボックスをオンにしてフィルタリングすると、2 つのレスポンスを比較できます。

[]

この例では、最初のリクエストは 107 kB の完全なレスポンスで、Brotli（br）圧縮を使用しています。一方、2 回目の再読み込みリクエストは 60 kB とほぼ半分のサイズで、辞書圧縮 Brotli（dcb）圧縮を使用しているため、ダウンロード時間が短縮されています。

Chrome で chrome://net-internals/#sharedDictionary ページを表示して、共有辞書を表示し、この例を最初から繰り返す場合はクリアできます。

結果

この変更は、2025 年の春に検索ユーザーにリリースされました。最初は Chrome ユーザー向けでした。これにより、すべての Chrome ユーザーの HTML ペイロードの平均サイズが、標準の Brotli 圧縮と比較して 23% 削減されました。この全回答の平均値には、辞書圧縮されていない結果（辞書のない初回ユーザーなど）と、辞書圧縮された検索結果の両方が含まれます。辞書圧縮された結果の場合、前の例で見たように、ほぼ 50% の改善が見られたため、削減量はさらに大きくなります。

これにより、Largest Contentful Paint（LCP）が全体で 1.7% 改善され、レイテンシの高いネットワークでは最大 9% 改善されました。これは小さいように見えるかもしれませんが、Google 検索は高度に最適化されたサイトであるため、この程度の改善でも大きな効果があります。他のサイトでは、このテクノロジーによりさらに大きな改善が見られる可能性があります。

サイトで試してみる

圧縮辞書転送は、すべての Chromium ベースのブラウザ（Chrome、Edge、Opera など）ですぐに使用できます。これはプログレッシブ エンハンスメントであり、サポートされていないブラウザでは無視されますが、この機能をサポートするブラウザが増えるにつれて、メリットも増えます。

このテクノロジーが解決する課題は、Google 検索に固有のものではありません。多くのサイトで、検索で使用されているような個別の辞書を使用する場合でも、既存のリソースを辞書として使用する場合（新しいバージョンをリリースする際のアプリの以前のバージョンなど）でも、圧縮辞書転送のメリットを享受できます。

このテクノロジーの仕組みと、サイトに実装する方法について詳しくは、MDN のガイドをご覧ください。

辞書ベースの圧縮リソースを作成して適切に提供するには、サーバーまたはビルドプロセスで設定が必要ですが、パフォーマンスの面では非常に大きな効果が得られます。