Signed Exchange（SXG）

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

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

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

この記事では、SXG の仕組み、ユースケース、ツールに関する包括的な概要を説明します。

ブラウザの互換性

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

概要

SXG の主なユースケースとして、キャッシュを使用して、オリジンによって暗号署名されたコンテンツをプリフェッチして提供します。これにより、参照元サイトからのクロスオリジン ナビゲーションを高速化しながら、ページが変更されず、オリジンに正しく帰属されるようにすることができます。個人を特定できる可能性のある情報は、ユーザーがサイトに移動するまで非表示になり、ユーザーのプライバシーが保護されます。Google 検索は SXG プリフェッチ機能を早期に導入しており、Google 検索からトラフィックの大部分を受け取るサイトにとって、SXG はユーザーにページをより速く読み込むための重要なツールとなります。今後、この影響が他の参照元にも拡大されることを期待しています。

仕組み

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

署名付きエクスチェンジの仕組みを説明する図。ブラウザがキャッシュと通信し、キャッシュがリンク先サイトと通信する

これまで、アトリビューションを維持しながら第三者を使用してコンテンツを配信する唯一の方法は、サイトが 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 Exchanges の仕様をご覧ください。

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

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

ウェブ パッケージング

SXG は、より広範な ウェブ パッケージング仕様案ファミリーの一部です。SXG に加えて、Web Packaging 仕様のもう一つの主要コンポーネントはウェブ バンドル（「バンドルされた HTTP エクスチェンジ」）です。ウェブバンドルは、HTTP リソースと、バンドルを解釈するために必要なメタデータのコレクションです。

SXG とウェブバンドルの関連性は、よく混同される点です。SXG と Web Bundle は、互いに依存しない 2 つの異なるテクノロジーです。Web Bundle は、署名付き交換と署名なし交換の両方で使用できます。SXG とウェブ バンドルの両方で推進されている共通の目標は、サイト全体を共有してオフラインで利用できるようにする「ウェブ パッケージング」形式を作成することです。

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

署名付き交換を有効にすると、ウェブページのパフォーマンスが向上し、サイトの Core Web Vitals（特に Largest Contentful Paint（LCP））に影響する可能性があります。Google 検索は早期導入ユーザーとして、SXG を使用して、検索結果ページから読み込まれるページの読み込みを高速化しています。

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

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

Signed Exchange の影響

過去のテストでは、SXG 対応のプリフェッチにより LCP が平均 300 ～ 400 ミリ秒短縮されました。これにより、サイトがユーザーに与える第一印象が改善され、多くの場合、ビジネス指標にプラスの影響を与えます。

すでに、いくつかのグローバル ブランドとサイトが署名付きエクスチェンジのメリットを享受しています。ケーススタディとして、著名なコンテンツ管理システム（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 コンテンツを AMP URL ではなく正規 URL を使用してプリフェッチして表示できます。AMP には、SXG を生成するための独自のツールがあります。Signed Exchange を使用して AMP を配信する方法については、amp.dev をご覧ください。

Chrome DevTools で SXG をデバッグする

SXG を実際に確認するには、Chromium ブラウザを使用して DevTools を開き、[ネットワーク] パネルを開いて、こちらの検索ページの例にアクセスします。署名付きエクスチェンジは、[タイプ] 列で signed-exchange を探すことにより特定できます。

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

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

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

ツール

SXG の実装は、特定の URL に対応する SXG を生成し、その SXG をリクエスト元（通常はクローラ）に提供することです。

証明書

SXG を生成するには、SXG に署名できる証明書が必要です。ただし、一部のツールでは、証明書が自動的に取得されます。このページでは、このタイプの証明書を発行できる認証局の一覧を示します。証明書は、任意の ACME クライアントを使用して Google 認証局から自動的に取得できます。Web Packager サーバーは ACME クライアントを組み込んでおり、sxg-rs もまもなく組み込まれます。

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

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

汎用 SXG ツール

sxg-rs HTTP サーバー

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

ウェブ パッケージャー サーバー

Web パッケージャ サーバー webpkgserver は、Go で記述された sxg-rs http_server の代替手段です。Web パッケージャ サーバーの設定手順については、Web パッケージャを使用して Signed Exchange を設定する方法をご覧ください。

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 と、より機能豊富なウェブ パッケージャー ツールのベースとして使用されます。

コンテンツのネゴシエーション

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 の例が含まれています。

Update cache API

Google SXG Cache には、サイト所有者が Cache-Control: max-age により期限切れになる前に、キャッシュから SXG を削除するために使用できる API があります。詳細については、update cache 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 は、サイトの Cookie を持つユーザーに表示できます。
  • SXG は、Link ヘッダーを使用して指定された場合、ページのサブリソース（JavaScript、CSS、フォント、画像など）もプリフェッチします。
  • 今後、Google 検索からの SXG プリフェッチは、より多くの検索結果タイプで利用可能になる予定です。

まとめ

署名付きエクスチェンジは、リソースの配信方法に関係なく、リソースの送信元と有効性を確認できる配信メカニズムです。そのため、パブリッシャーの完全なアトリビューションを維持しながら、サードパーティが SXG を配信できます。

関連情報