このページは Cloud Translation API によって翻訳されました。

Signed Exchange（SXG）

SXG は、リソースの配信方法に関係なく送信元を認証できる配信メカニズムです。

Katie Hempenius

Devin Mullins

Signed Exchange（SXG）は、配信方法に関係なく、リソースの送信元を認証するための配信メカニズムです。SXG を実装すると、プライバシー保護のクロスオリジンプリフェッチが有効になり、Largest Contentful Paint（LCP）が改善されます。さらに、この分離により、オフラインインターネットエクスペリエンスやサードパーティキャッシュからのサービングなど、さまざまなユースケースが進展します。

この記事では、SXG の仕組み、ユースケース、ツールなど、SXG の概要を説明します。

ブラウザの互換性

SXG は、Chromium ベースのブラウザ（Chrome 73、Edge 79、Opera 64 以降のバージョン）でサポートされています。

概要

主なユースケースとして、SXG はキャッシュを使用して、送信元によって暗号署名されたコンテンツをプリフェッチして提供します。これにより、リファラーサイトからのクロスオリジンナビゲーションが高速化されると同時に、ページが改ざんされず、オリジンに適切に関連付けられるようになります。個人を特定できる可能性のある情報は、ユーザーがサイトにアクセスするまで非表示になるため、ユーザーのプライバシーが保護されます。 Google 検索は SXG プリフェッチ機能をいち早く採用しており、トラフィックの大部分を Google 検索から受け取っているサイトにとって、SXG はページ読み込みを高速化するための重要なツールとなり得ます。今後、この影響がより多くの参照元に拡大されることを願っております。

仕組み

サイトはリクエストとレスポンスのペア（「HTTP エクスチェンジ」）に署名することで、コンテンツの配信方法に関係なく、ブラウザがコンテンツの送信元と完全性を確認できるようにします。その結果、ブラウザでは、コンテンツを配信したサーバーの URL ではなく、送信元サイトの URL をアドレスバーに表示できます。

Signed Exchange の仕組みを説明する図。ブラウザがキャッシュと通信し、キャッシュがリンク先サイトと通信する

これまで、アトリビューションを維持しながらサードパーティを使用してコンテンツを配信するための唯一の方法は、サイトが配信事業者と SSL 証明書を共有することでした。これにはセキュリティ上の欠点があり、さらに、コンテンツのポータビリティの実現には程遠くなります。

SXG 形式

SXG は、バイナリエンコードファイルにカプセル化されます。このファイルには、HTTP 交換と、その交換をカバーする署名という 2 つの主要コンポーネントがあります。HTTP エクスチェンジは、リクエスト URL、コンテンツネゴシエーション情報、HTTP レスポンスで構成されます。

デコードされた SXG ファイルの例を次に示します。

format version: 1b3
request:
  method: GET
  uri: https://example.org/
  headers:
response:
  status: 200
  headers:
    Cache-Control: max-age=604800
    Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY=
    Expires: Mon, 24 Aug 2020 16:08:24 GMT
    Content-Type: text/html; charset=UTF-8
    Content-Encoding: mi-sha256-03
    Date: Mon, 17 Aug 2020 16:08:24 GMT
    Vary: Accept-Encoding
signature:
    label;cert-sha256=<em>ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=</em>;
    cert-url=&quot;https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE&quot;;
    date=1597680503;expires=1598285303;integrity=&quot;digest/mi-sha256-03&quot;;sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>;
    validity-url=&quot;https://example.org/webpkg/validity&quot;
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p>

<p>The exchange has a valid signature.
payload [1256 bytes]:</p>
<pre class="prettyprint"><code>&lt;title&gt;SXG example&lt;/title&gt;
&lt;meta charset=&#34;utf-8&#34;&gt;
&lt;meta http-equiv=&#34;Content-type&#34; content=&#34;text/html; charset=utf-8&#34;&gt;
&lt;style type=&#34;text/css&#34;&gt;
body {
    background-color: #f0f0f2;
    margin: 0;
    padding: 0;
}
&lt;/style&gt;
</code></pre>
<div>
    <h1>Hello</h1>
</div>

<p>

署名の expires パラメータは SXG の有効期限を示します。SXG の有効期限は最大 7 日間です。署名ヘッダーの詳細については、Signed HTTP Exchange の仕様をご覧ください。

サーバーサイドのパーソナライズのサポート

Vary: Cookie ヘッダーを含む SXG は、署名付きリクエスト URL の Cookie を持たないユーザーにのみ表示されます。サイトでログインしているユーザーに異なる HTML を表示する場合、この機能を使用すれば、エクスペリエンスを変更することなく SXG を活用できます。詳細については、Dynamic SXG を使用したサーバーサイドのパーソナライズをご覧ください。

ウェブパッケージング

SXG は、より広範なウェブパッケージングの仕様提案ファミリーの一部です。SXG に加えて、ウェブパッケージ仕様の主要なコンポーネントはウェブバンドル（バンドルされた HTTP エクスチェンジ）です。ウェブバンドルは、バンドルの解釈に必要な HTTP リソースとメタデータの集合です。

SXG と Web Bundle の関係は、よくある混乱の点です。SXG と Web Bundle は、互いに依存しない 2 つの異なるテクノロジーです。Web Bundle は、署名付きエクスチェンジと署名なしエクスチェンジの両方で使用できます。SXG と Web Bundle の共通目標は、オフラインでの使用のためにサイト全体を共有できるようにする「ウェブパッケージング」形式の作成です。

Signed Exchange によるページ読み込みの高速化

Signed Exchange を有効にすると、ウェブページのパフォーマンスが向上し、特に Largest Contentful Paint（LCP）において、サイトの Core Web Vitals に影響が及びます。Google 検索では、先行ユーザーとして SXG を使用して、検索結果ページから読み込まれたページの読み込み時間を短縮しています。

Google 検索は、利用可能な場合は SXG をクロールしてキャッシュに保存し、ユーザーがアクセスする可能性の高い SXG（最初の検索結果に対応するページなど）をプリフェッチします。

SXG は、CDN の使用やレンダリングブロックサブリソースの削減など、他のパフォーマンス最適化と組み合わせて使用すると最も効果を発揮します。SXG のプリフェッチによる LCP のメリットを最大限に活かせるよう、実装後はこちらの推奨事項に従ってください。多くの場合、このような最適化により、Google 検索からほぼ瞬時にページが読み込まれるようになります。

Signed Exchange の影響

過去のテストでは、SXG 対応のプリフェッチによって LCP が平均 300 ～ 400 ミリ秒減少することが確認されています。これにより、サイトはユーザーにより良い第一印象を与えることができ、多くの場合、ビジネス指標にプラスの影響を与えます。

すでにいくつかのグローバルブランドやサイトが Signed Exchange の恩恵を受けています。Signed Exchange の実装が、著名なコンテンツマネジメントシステム（CMS）である RebelMouse の顧客のパフォーマンスとビジネス指標の向上にどのように役立ったかについて、事例として紹介します。

Narcity: LCP を 41%改善
Paper Magazine、ユーザーあたりのセッション数が 27% 増加
MLT ブログ、ページの読み込み時間を 21%短縮

Cloudflare は、SXG がテストしたサイトの 98% で TTFB を改善し、85% のサイトで LCP を改善し、SXG 対応ページ読み込みの平均改善率が 20% を超えていることを確認しました。

インデックス登録

ページの SXG 表現と SXG 以外の表現は、Google 検索によるランク付けやインデックス登録が異なることはありません。SXG は究極的には配信メカニズムであり、基盤となるコンテンツを変更するものではありません。

AMP

AMP コンテンツは SXG を使用して配信できます。SXG では、AMP URL ではなく正規 URL を使用して AMP コンテンツをプリフェッチして表示できます。AMP には、SXG を生成するための独自のツールが用意されています。Signed Exchange を使用して AMP を配信する方法については、amp.dev をご覧ください。

Chrome DevTools を使用した SXG のデバッグ

SXG を直接見るには、Chromium ブラウザで DevTools を開き、[ネットワーク] パネルを開いて、こちらの検索例のページにアクセスします。Signed Exchange は、[Type] 列で signed-exchange を探すことで識別できます。

DevTools の [Network] パネル内の SXG リクエストを示すスクリーンショット — DevTools の [**Network**] パネル

[プレビュー] タブには、SXG のコンテンツに関する詳細情報が表示されます。

SXG の [プレビュー] タブのスクリーンショット — DevTools の [**プレビュー**] タブ

ツール

SXG の実装には、特定の URL に対応する SXG を生成し、その SXG をリクエスト元（通常はクローラー）に配信する作業が含まれます。

証明書

SXG を生成するには、SXG に署名できる証明書が必要ですが、ツールによっては、証明書が自動的に取得されます。このページには、このタイプの証明書を発行できる認証局の一覧が記載されています。証明書は、ACME クライアントを使用して Google の認証局から自動的に取得できます。Web Packager Server には ACME クライアントが組み込まれており、sxg-rs もまもなく提供される予定です。

注: 本番環境で SXG を使用するには、CanSignHttpExchanges 拡張機能をサポートする証明書が必要です。specに基づき、この延長による証明書の有効期間は 90 日以内にする必要があります。また、要求元のドメインで DNS CAA レコードが設定されている必要があります。

プラットフォーム固有の SXG ツール

これらのツールは、特定の技術スタックをサポートしています。これらのツールのいずれかでサポートされているプラットフォームをすでに使用している場合は、汎用ツールよりも設定が簡単な場合があります。

sxg-rs/cloudflare_worker は、Cloudflare ワーカーで実行されます。
sxg-rs/fastly_compute は Fastly Compute@Edge で実行されます。
自動 Signed Exchange は、証明書を自動的に取得して Signed Exchange を生成する Cloudflare の機能です。
NGINX SXG モジュールは、nginx を使用するサイト用に SXG を生成して提供します。設定手順については、こちらをご覧ください。
Envoy SXG フィルタは、Envoy を使用するサイトの SXG を生成して提供します。

汎用 SXG ツール

sxg-rs HTTP サーバー

sxg-rs http_server は、SXG を提供するためのリバースプロキシとして機能します。SXG クローラーからのリクエストの場合、http_server はバックエンドからのレスポンスに署名し、SXG を返します。インストール手順については、README をご覧ください。

Web Packager サーバー

Web Packager サーバー（webpkgserver）は、Go で作成された sxg-rs http_server に代わるものです。Web Packager サーバーの設定手順については、Web Packager を使用して署名付きエクスチェンジを設定する方法をご覧ください。

Web Packager CLI

Web Packager CLI は、指定された URL に対応する SXG を生成します。

webpackager \
    --private\_key=private.key \
    --cert\_url=https://example.com/certificate.cbor \
    --url=https://example.com

SXG ファイルが生成されたら、サーバーにアップロードし、application/signed-exchange;v=b3 MIME タイプを指定して提供します。また、SXG 証明書を application/cert-chain+cbor として提供する必要があります。

SXG ライブラリ

次のライブラリを使用して、独自の SXG 生成ツールを構築できます。

sxg_rs は、SXG を生成するための Rust ライブラリです。これは最も機能的な SXG ライブラリであり、cloudflare_worker ツールと fastly_compute ツールのベースとして使用されます。
libsxg は、SXG を生成するための最小限の C ライブラリです。これは、NGINX SXG モジュールと Envoy SXG フィルタの基礎として使用されます。
go/signed-exchange は、SXG を生成するためのリファレンス実装として webpackage 仕様で提供されている最小限の Go ライブラリです。これは、リファレンス CLI ツール gen-signedexchange や、より機能的な Web Packager ツールの基礎として使用されます。

コンテンツ交渉

Accept ヘッダーが application/signed-exchange の q 値が text/html の q 値以上であることを示す場合、サーバーは SXG を配信します。つまり、配信元サーバーからクローラには SXG が配信されますが、ブラウザには配信されません。上記のツールの多くはデフォルトでこれを行いますが、他のツールでは、次の正規表現を使用して、SXG として提供されるリクエストの Accept ヘッダーを照合できます。 http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

この推奨事項には、Apache と nginx の例が含まれています。

キャッシュ API の更新

Google SXG Cache には、サイト所有者が Cache-Control: max-age によって期限切れになる前に SXG をキャッシュから削除できる API があります。詳しくは、キャッシュの更新 API リファレンスをご覧ください。

SXG へのリンク

どのサイトでも、タグとタグを使用して、可能な場合はリンク先のページの SXG をキャッシュに保存、配信、プリフェッチできます。 html <a href="https://example.com/article.html.sxg"> <link rel="prefetch" as="document" href="https://example.com/article.html.sxg"> こちらの記事では、nginx を使用して SXG を配布する方法について説明しています。

固有のメリット

SXG は、クロスオリジンプリフェッチを可能にする多くの技術の一つです。使用するテクノロジーを決定する際、さまざまな側面を最適化する間のトレードオフが必要になる場合があります。次のセクションでは、考えられる解決策の領域で SXG が提供する固有の値をいくつか説明します。これらの要因は、利用可能なソリューションのスペースが進化するにつれて変化する可能性があります。

処理するリクエストが少なくなる

クロスサイトプリフェッチでは、サーバーが追加のリクエストを処理する必要が生じる場合があります。これは、ページがプリフェッチされたものの、ユーザーがページにアクセスしなかったか、プリフェッチされたバイトをユーザーに表示できなかったケースに該当します。SXG では、次のような追加の未使用リクエストを大幅に削減できます。

SXG はキャッシュに保存され、有効期限が切れるまでユーザーに送信される可能性があります。したがって、多くのプリフェッチはキャッシュサーバーだけで処理できます。
SXG は、サイトで Cookie の有無にかかわらずユーザーに表示できます。そのため、ナビゲーション後にページを再度取得する必要がある回数が少なくなります。

ページの読み込み速度の改善

プリフェッチが現在サポートしているサーフェスと機能によって、ページの読み込み速度がさらに向上する可能性があります。

サイトの Cookie を使用してユーザーに SXG を表示できます。
Link ヘッダーを使用して指定された場合、SXG はページのサブリソース（JavaScript、CSS、フォント、画像など）もプリフェッチします。
近い将来、Google 検索からの SXG プリフェッチは、より多くの検索結果タイプで利用できるようになります。

おわりに

Signed Exchange は、リソースの配信方法とは別に、リソースの送信元と有効性を確認できるようにする配信メカニズムです。そのため、SXG は、完全なパブリッシャーの帰属を維持しながら、第三者によって配布できます。

Signed Exchange（SXG）

ブラウザの互換性

概要

仕組み

SXG 形式

サーバーサイドのパーソナライズのサポート

ウェブ パッケージング

Signed Exchange によるページ読み込みの高速化

Signed Exchange の影響

インデックス登録

AMP

Chrome DevTools を使用した SXG のデバッグ

ツール

証明書

プラットフォーム固有の SXG ツール

汎用 SXG ツール

sxg-rs HTTP サーバー

Web Packager サーバー

Web Packager CLI

SXG ライブラリ

コンテンツ交渉

キャッシュ API の更新

SXG へのリンク

固有のメリット

処理するリクエストが少なくなる

ページの読み込み速度の改善

おわりに

関連情報

ウェブパッケージング