SXG は、リソースの配信方法に関係なくリソースの送信元を認証できる配信メカニズムです。
署名付きエクスチェンジ(SXG)は、リソースの配信方法に関係なくリソースの送信元を認証できる配信メカニズムです。SXG を実装すると、プライバシーを保護するクロスオリジン プリフェッチを有効にして、Largest Contentful Paint(LCP)を改善できます。さらに、この分離により、オフラインのインターネット エクスペリエンスやサードパーティ キャッシュからのサービングなど、さまざまなユースケースが促進されます。
この記事では、SXG の仕組み、ユースケース、ツールなど、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 レスポンスで構成されます。
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="https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE"; date=1597680503;expires=1598285303;integrity="digest/mi-sha256-03";sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>; validity-url="https://example.org/webpkg/validity" header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p> <p>The exchange has a valid signature. payload [1256 bytes]:</p> <pre class="prettyprint"><code><title>SXG example</title> <meta charset="utf-8"> <meta http-equiv="Content-type" content="text/html; charset=utf-8"> <style type="text/css"> body { background-color: #f0f0f2; margin: 0; padding: 0; } </style> </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 と Web Bundle の関係は、よく混乱する点です。SXG と Web Bundle は、相互に依存しない 2 つの異なるテクノロジーです。Web Bundle は、Signed Exchange と UnSigned Exchange の両方で使用できます。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 は、[タイプ] 列で「signed-exchange
」を探すことで識別できます。
[プレビュー] タブには、SXG の内容に関する詳細情報が表示されます。
ツール
SXG の実装は、特定の URL に対応する SXG を生成し、その SXG をリクエスト元(通常はクローラ)に提供することです。
証明書
SXG を生成するには、SXG に署名できる証明書が必要です。ただし、一部のツールでは証明書が自動的に取得されます。このタイプの証明書を発行できる認証局の一覧は、こちらのページに記載されています。証明書は ACME クライアントを使用して Google 認証局から自動的に取得できます。Web Packager サーバーは ACME クライアントを組み込んでおり、sxg-rs もまもなく組み込まれます。
プラットフォーム固有の SXG ツール
これらのツールは、特定の技術スタックをサポートしています。これらのツールでサポートされているプラットフォームをすでに使用している場合は、汎用ツールよりもセットアップが簡単な場合があります。
sxg-rs/cloudflare_worker
は Cloudflare Workers で実行されます。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 Server(webpkgserver
)は、Go で記述された sxg-rs http_server の代替手段です。Web Packager サーバーの設定手順については、Web Packager を使用して署名付き 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
や、より機能性の高い 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 の例が含まれています。
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 を配信できます。