Signed Exchange を使用した LCP の最適化

Signed Exchange の効果を最大限に引き出すために、Signed Exchange を測定および最適化する方法

Signed Exchange（SXG）は、ページの読み込み速度を改善する手段であり、主に Largest Contentful Paint（LCP）です。参照元サイト（現在は Google 検索）がページにリンクしている場合、ユーザーがリンクをクリックする前にブラウザのキャッシュにそのページをプリフェッチできます。

プリフェッチされたときに、ページをレンダリングするためのクリティカル パス上にネットワークを必要としないウェブページを作成できます。4G 接続の場合、このページの読み込み時間は 2.8 秒から 0.9 秒になります（残りの 0.9 秒は主に CPU 使用率によるものです）。

現在 SXG を公開しているほとんどの人は、Cloudflare の使いやすい Automatic Signed Exchange（ASX）機能を使用しています（ただし、オープンソースのオプションもあります）。

多くの場合、この機能を有効にするためのチェックボックスをオンにするだけで、上記のような大幅な改善を実現できます。場合によっては、これらの SXG がパイプラインの各ステージで意図したとおりに動作していることを確認し、プリフェッチを最大限に活用するためにページを最適化するために、さらにいくつかのステップがあります。

Cloudflare がリリースされてからこの数か月の間、私はさまざまな フォーラムで質問を読んで回答し、SXG デプロイメントを最大限に活用するためのアドバイスをサイトに掲載してきました。この投稿は、私のアドバイスをまとめたものです。以下の手順をご案内します。

• WebPageTest を使用して SXG パフォーマンスを分析します。
• 分析ステップで機能していないことが判明した場合は、SXG パイプラインをデバッグします。
• 最適な max-age の設定やレンダリング ブロック サブリソースのプリロードなど、SXG プリフェッチ用にページを最適化します。
• Google アナリティクスを使用して、適切なテストグループとコントロール グループを選択して、SXG の向上を測定します。

はじめに

SXG は、URL、一連の HTTP レスポンス ヘッダー、レスポンス本文を含むファイルで、すべて Web PKI 証明書によって暗号署名されています。ブラウザで SXG を読み込むと、次のすべてを検証します。

• SXG の有効期限が切れていないこと。
• 署名は URL、ヘッダー、本文、証明書と一致します。
• 証明書が有効で、URL と一致しています。

検証に失敗した場合、ブラウザは SXG を放棄し、署名付き URL を取得します。検証が成功すると、ブラウザは署名付きレスポンスを読み込み、署名付き URL から直接送信されたものとして扱います。これにより、署名後に SXG が期限切れまたは変更されていない限り、任意のサーバーで再ホストできます。

Google 検索の場合、SXG は検索結果のページのプリフェッチを有効にします。SXG をサポートしているページの場合、Google 検索は、webpkgcache.com でホストされているページのキャッシュ コピーをプリフェッチできます。これらの webpkgcache.com の URL は、ページの表示や動作には影響しません。ブラウザは元の署名付き URL を尊重するためです。プリフェッチを使用すると、ページの読み込み時間を大幅に短縮できます。

分析

SXG のメリットを確認するには、まずラボツールを使用して、再現可能な条件下で SXG のパフォーマンスを分析します。WebPageTest を使用すると、SXG プリフェッチの有無にかかわらず、ウォーターフォールと LCP を比較できます。

次のように、SXG を使用せずにテストを生成します。

• WebPageTest にアクセスしてログインします。ログインするとテスト履歴が保存され、後で簡単に比較できます。
• テストする URL を入力します。
• [詳細設定] に移動します。（SXG テストには詳細構成が必要なため、ここで使用すると、テスト オプションは同じになります）。
• [Test Settings] タブで、[Connection] を 4G に設定し、[Number of Tests to Run] を 7 に増やすことをおすすめします。
• [Start Test] をクリックします。

上記と同じ手順で SXG を使用してテストを生成しますが、[テストを開始] をクリックする前に、[スクリプト] タブに移動して、次の WebPageTest スクリプトを貼り付け、2 つの navigate URL を指示どおりに変更します。

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

最初の navigate URL で、ページがまだ Google 検索の検索結果に表示されない場合は、こちらのプリフェッチ ページを使用して、この目的のためにふりをした検索結果ページを生成できます。

2 つ目の navigate の URL を確認するには、Chrome 拡張機能の SXG Validator を使用してページにアクセスし、拡張機能アイコンをクリックしてキャッシュ URL を表示します。

これらのテストが完了したら、[テスト履歴] に移動し、2 つのテストを選択して [比較] をクリックします。

比較 URL に &medianMetric=LCP を追加して、WebPageTest が比較の両側で LCP の中央値の実行を選択するようにします。（デフォルトは、Speed Index による中央値です）。

ウォーターフォールを比較するには、[ウォーターフォールの不透明度] セクションを開いてスライダーをドラッグします。動画を表示するには、[フィルムストリップの設定を調整] をクリックし、ダイアログ内を下にスクロールして [動画を見る] をクリックします。

SXG プリフェッチが成功すると、「with SXG」ウォーターフォールに HTML の行が含まれず、サブリソースの取得が早く開始されます。たとえば、以下の例では「変更前」と「変更後」を比較します。

デバッグ

WebPageTest で SXG がプリフェッチされていることが示された場合は、パイプラインのすべてのステップで成功しています。LCP をさらに改善する方法については、[Optimize] セクションにスキップしてください。それ以外の場合は、パイプラインのどこで、なぜ失敗したかを特定する必要があります。ここでは、その方法について説明します。

公開中

ページが SXG として生成されていることを確認してください。そのためには、クローラーになりすます必要があります。最も簡単な方法は、Chrome 拡張機能の SXG Validator を使用することです。

この拡張機能は、SXG バージョンを優先する Accept リクエスト ヘッダーを使用して現在の URL を取得します。Origin の横にチェックマーク（✅）が表示されている場合は、SXG が返されたことを意味します。インデックス登録セクションまでスキップできます。

バツマーク（❌）が表示されている場合は、SXG が返されなかったことを意味します。

Cloudflare ASX が有効になっている場合、クロスマーク（❌）の原因として最も可能性が高いのは、キャッシュ制御レスポンス ヘッダーで許可されていないからです。ASX は、次の名前のヘッダーを調べます。

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

これらのヘッダーのいずれかに次のいずれかのヘッダー値が含まれている場合、SXG は生成されません。

• private
• no-store
• no-cache
• max-age は 120 未満（120 以上の s-maxage でオーバーライドされない限り）

このような場合、ASX は SXG を作成しません。SXG は、複数回の訪問や複数の訪問者に対してキャッシュに保存され、再利用される可能性があるためです。

バツマーク（❌）のもう 1 つの原因として、Set-Cookie 以外のステートフル レスポンス ヘッダーのいずれかが存在することが考えられます。ASX は、SXG 仕様に準拠するために Set-Cookie ヘッダーを削除します。

また、Vary: Cookie レスポンス ヘッダーが存在することも考えられます。Googlebot はユーザー認証情報なしで SXG を取得し、複数のサイト訪問者に配信することがあります。Cookie に基づいてユーザーごとに異なる HTML を配信すると、表示がログアウトされるなど、ユーザー エクスペリエンスが不正確になる可能性があります。

Chrome 拡張機能の代わりに、curl などのツールを使用することもできます。

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

または dump-signedexchange:

dump-signedexchange -verify -uri $URL

SXG が存在し、有効であれば、SXG が人が読める形式で出力されます。そうしないと、エラー メッセージが表示されます。

インデックス登録

SXG が Google 検索に正常にインデックス登録されていることを確認します。Chrome DevTools を開き、Google でページを検索します。そのページが SXG としてインデックス登録されている場合、Google のページへのリンクには webpkgcache.com のコピーを指す data-sxg-url が含まれます。

ユーザーが検索結果をクリックする可能性が高いと Google 検索が判断した場合は、次のようにプリフェッチも行います。

<link> 要素は、SXG をプリフェッチ キャッシュにダウンロードするようブラウザに指示します。ユーザーが <a> 要素をクリックすると、ブラウザはキャッシュされた SXG を使用してページをレンダリングします。

また、DevTools の [Network] タブに移動し、webpkgcache を含む URL を検索して、プリフェッチの証拠を確認することもできます。

<a> が webpkgcache.com を参照している場合、Signed Exchange の Google 検索のインデックス登録は機能しています。「取り込み」セクションまでスキップできます。

それ以外の場合は、SXG を有効にしてから Google がまだページを再クロールしていない可能性があります。Google Search Console の URL 検査ツールをお試しください。

digest: mi-sha256-03=... ヘッダーが存在する場合は、Google が SXG バージョンを正常にクロールしたことを示します。

digest ヘッダーが存在しない場合は、SXG が Googlebot に配信されていないか、SXG を有効にしてからインデックスが更新されていない可能性があります。

SXG が正常にクロールされたにもかかわらず、まだリンクされない場合は、SXG のキャッシュ要件を満たしていない可能性があります。これらについては次のセクションで説明します。

取り込み

Google 検索が SXG をインデックスに登録すると、そのコピーが Google SXG Cache に送信され、キャッシュ要件に照らして検証されます。Chrome 拡張機能に結果が表示されます。

チェックマーク（✅）が表示されている場合は、最適化に進んでください。

要件を満たしていない場合は、バツマーク（❌）と、その理由を示す警告メッセージが表示されます。

その場合、このページは SXG を有効にする前と同じように動作します。Google は、SXG プリフェッチなしで元のホストのページにリンクします。

キャッシュ コピーの有効期限が切れ、バックグラウンドで再取得されている場合は、砂時計（⌛）が表示されます。

SXG に関する Google のデベロッパー向けドキュメントにも、キャッシュを手動でクエリする手順が記載されています。

最適化

Chrome 拡張機能の SXG Validator にすべてのチェックマーク（✅）が表示されていれば、ユーザーに配信可能な SXG があるということです。ここでは、ウェブページを最適化して SXG で LCP を最大限改善する方法をご紹介します。

max-age

SXG の有効期限が切れると、Google SXG のキャッシュがバックグラウンドで新しいコピーを取得します。フェッチを待つ間、ユーザーはプリフェッチされない元のホストのページにリダイレクトされます。Cache-Control: max-age を長く設定するほど、このバックグラウンド フェッチの頻度は少なくなるため、プリフェッチによって LCP を低減できる可能性が高くなります。

これはパフォーマンスと鮮度のトレードオフの関係です。また、サイト所有者は、キャッシュを使用することで、各ページの特定のニーズに合わせて max-age を 2 分～ 7 日の間で SXG に指定できます。事例から、次のことがわかりました。

• max-age=86400（1 日）以上がパフォーマンスの向上につながります
• max-age=120（2 分）が一致しない

データをさらに調査しながら、この 2 つの間にある値についてさらに学習していきたいと考えています。

user-agent

プリフェッチされた SXG を使用すると LCP が増加したことがあります。WebPageTest を実行して、SXG プリフェッチありとなしの場合とで結果の中央値を比較しました。以下の [変更後] をクリックします。

プリフェッチが機能していることを確認しました。HTML がクリティカル パスから削除されるため、すべてのサブリソースを早めに読み込むことができます。しかし、LCP（緑色の破線）は 2 秒から 2.1 秒に増加しました。

これを診断するため、フィルム ストリップを観察しました。SXG でページの表示が異なることがわかりました。Chrome は、プレーン HTML では LCP の「最大の要素」が見出しであると判断しました。しかし、SXG バージョンでは遅延読み込みのバナーが追加され、スクロールしなければ見えない位置に見出しが押しやられ、Cookie 使用の同意ダイアログが遅延読み込みの大きな要素になっていました。すべては以前よりも早くレンダリングされましたが、レイアウトの変更により、指標のレポート作成が遅くなりました。

詳しく調べると、レイアウトの違いの原因は、ページが User-Agent によって異なり、ロジックにエラーがあることが判明しました。SXG クロール ヘッダーでモバイルと示されているにもかかわらず、PC 用ページが配信されていました。この事象が修正された後、ブラウザはページの見出しを最大の要素として再び正しく認識しました。

[After] をクリックすると、プリフェッチされた LCP が 1.3 秒に低下しました。

SXG はすべてのフォーム ファクタで有効になっています。それに備えるには、次のいずれかに該当することを確認してください。

• ページが User-Agent によってVaryされていない（レスポンシブ デザインやモバイル用とパソコン用の別々の URL が使用されているなど）。
• ページで動的な配信を使用している場合は、<meta name=supported-media content=...> を使用して、モバイル専用またはパソコン専用であることを示すアノテーションが付けられます。

サブリソース

SXG を使用すると、HTML とともにサブリソース（画像を含む）をプリフェッチできます。Cloudflare ASX は、HTML から同一オリジン（ファースト パーティ）の <link rel=preload> 要素をスキャンし、SXG 互換の Link ヘッダーに変換します。ソースコードの詳細は、こちらとこちらをご覧ください。

正常に機能している場合は、Google 検索からさらにプリフェッチが表示されます。

LCP を最適化するには、ウォーターフォールをよく確認し、最大の要素をレンダリングするためのクリティカル パス上にあるリソースを特定します。プリフェッチできない場合は、クリティカル パスから削除できるかどうかを検討してください。読み込みが完了するまでページを非表示にするスクリプトに注意してください。

Google SXG Cache では、最大 20 個のサブリソースのプリロードが可能で、ASX はこの上限を超えないようにします。ただし、サブリソースのプリロードが多すぎることにはリスクがあります。クロスサイト トラッキングを防止するために、ブラウザはすべてのサブリソースの取得を完了した場合のみ、プリロードされたサブリソースを使用します。サブリソースが多いほど、ユーザーがクリックしてページにアクセスする前にすべてのプリフェッチが完了する可能性は低くなります。

現在、SXG Validator はサブリソースをチェックしません。当面は、curl または dump-signedexchange を使用してデバッグしてください。

測定

WebPageTest で LCP の改善を最適化した後、サイトの全体的なパフォーマンスに対する SXG プリフェッチの影響を測定すると便利です。

サーバーサイドの指標

サーバーサイドの指標（最初のバイトまでの時間（TTFB）など）を測定する際は、この形式に対応しているクローラにのみ SXG が配信されることに注意が必要です。TTFB の測定は、bot ではなく実際のユーザーからのリクエストに限定します。SXG を生成すると、クローラー リクエストの TTFB は増加する場合がありますが、それによるサイト訪問者のエクスペリエンスには影響しません。

クライアントサイドの指標

SXG は、クライアントサイドの指標、特に LCP において速度面で最も大きなメリットをもたらします。影響を測定する際は、Cloudflare ASX を有効にして Googlebot が再クロールされるのを待ち、Core Web Vitals（CWV）の集計が完了してからさらに 28 日間待ってから、新しい CWV の数値を確認するだけです。ただし、この期間に他のすべての変更と混ざっていると、その変化を特定するのが難しくなる可能性があります。

代わりに、「SXG はページビューの X% に影響し、75 パーセンタイルで LCP を Y ミリ秒改善する」という形で、影響を受ける可能性のあるページ読み込みを「拡大」すると役立ちます。

現在、SXG プリフェッチは特定の条件下でのみ実行されます。

• Chromium ブラウザ（例: Chrome または Edge（iOS を除く））、バージョン M98 以降
• Referer: google.com または他の Google 検索ドメイン。（Google アナリティクスでは、参照タグはセッション内のすべてのページビューに適用されますが、SXG プリフェッチは Google 検索から直接リンクされた最初のページビューにのみ適用されます）。

「ページビューの X%」と「LCP を Y ミリ秒改善」を測定する方法については、最新の調査のセクションをご覧ください。

現代研究

実際のユーザー モニタリング（RUM）データを確認する場合は、ページ読み込みを SXG と SXG 以外に分割する必要があります。その際、選択バイアスを避けるため、SXG 以外の側も SXG の利用条件を満たすように、閲覧するページ読み込みを制限することが重要です。それ以外の場合、次のすべてが SXG 以外のページ読み込みにのみ存在し、LCP は本質的に異なる可能性があります。

• iOS デバイス: デバイスを使用しているユーザー間で、ハードウェアやネットワークの速度が異なることが原因です。
• 古い Chromium ブラウザ: 同じ理由があります。
• デスクトップ デバイス: 同じ理由、またはページ レイアウトによって別の「最大の要素」が選択されるため。
• 同一サイト ナビゲーション（サイト内でリンクをたどるユーザー）: 前回のページの読み込み時にキャッシュされたサブリソースを再利用できるため。

Google アナリティクス（UA）で、スコープが「Hit」の 2 つのカスタム ディメンションを作成します。1 つは「isSXG」、もう 1 つは「referrer」という名前のディメンションです。（組み込みの「参照元」ディメンションにはセッション スコープが設定されているため、同一サイトのナビゲーションは除外されません）。

次のフィルタを AND 結合して、「SXGcounterfactual」という名前のカスタム セグメントを作成します。

• 「referrer」の先頭が「https://www.google.」と一致
• Browser は Chrome と完全一致します
• Browser バージョンが正規表現に一致 ^(9[8-9]|[0-9]{3})
• isSXG は false と完全一致します

このセグメントのコピーを「SXG」という名前で作成します。ただし、isSXG は true と完全に一致します。

サイト テンプレートで、次のスニペットを Google アナリティクス スニペットの上に追加します。これは、SXG の生成時に ASX が false を true に変更する特別な構文です。

<script data-issxg-var>window.isSXG=false</script>

Google アナリティクスのレポート スクリプトを推奨どおりにカスタマイズし、LCP を記録します。gtag.js を使用している場合は、'config' コマンドを変更してカスタム ディメンションを設定します（'dimension1' と 'dimension2' は、Google アナリティクスが指定する名前に置き換えます）。

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

analytics.js を使用している場合は、こちらに記載されているように 'create' コマンドを変更します。

数日待ってデータを収集したら、Google アナリティクスのイベント レポートに移動して、SXG セグメントのドリルダウンを追加します。「SXG はページビューの X% に影響する」の X を入力します。

最後に、ウェブに関する指標レポートに移動し、[セグメントの選択] を選択して、[SXG 反事実] と [SXG] を選択します。

[送信] をクリックすると、2 つのセグメントの LCP 分布が表示されます。これは、「75 パーセンタイルで LCP を Y ミリ秒改善する」ことに対する Y を入力します。

注意点

上記のフィルタをすべて適用すると、SXG の反事実的条件のページの読み込みは次のようになります。

• キャッシュミス: Google SXG のキャッシュに、指定された URL の SXG の新しいコピーがない場合、サイトの元の URL にリダイレクトされます。
• その他の検索結果タイプ: Google 検索は現在、標準のウェブ検索結果とその他いくつかのタイプのウェブ検索結果についてのみ、SXG をサポートしています。また、強調スニペットやトップニュース カルーセルなどは、サイトの元の URL にリンクします。
• 不適格な URL: サイト内の一部のページが SXG に対応していない場合（キャッシュできないなど）、このセットに表示される可能性があります。

SXG のページ読み込みと上記の SXG 以外のページ読み込みの間にはバイアスが残っている可能性がありますが、「現代的な調査」セクションの冒頭で説明したバイアスよりも小さい値であるはずです。たとえば、キャッシュできないページが、キャッシュ可能なページより遅い、または速いといったケースです。これが問題であると思われる場合は、特定の SXG 対象 URL に限定したデータを調べて、結果が研究全体と一致するかどうかを確認することを検討してください。

サイトにいくつかの AMP ページがある場合、SXG を有効にしてもパフォーマンスは向上しないでしょう。SXG は Google 検索からプリフェッチ済みであるためです。そのようなページを除外するフィルタを追加して、関連する変更をさらに「拡大」することを検討してください。

最後に、すべての選択バイアスに対処したとしても、生存バイアスによって LCP の改善が RUM 統計における劣化のように見えるというリスクがあります。この記事では、このリスクについて詳しく説明しており、なんらかの形で放棄指標を調べて、この問題が発生しているかどうかを確認することをおすすめします。

調査前後

現代の研究から得られた結果を裏付けるため、SXG を有効にする前と後で LCP を比較すると役に立つ場合があります。上記のバイアスを排除するため、SXG ページビューに限定しないでください。代わりに、SXG 対象となる結果（isSXG 制約がない上記のセグメント定義）を確認します。

Google 検索がサイト上のすべてのページを再クロールし、そのページで SXG が有効になっていることを確認するには、数週間かかる場合があります。この数週間は、他にも次のようなバイアスが発生する可能性があります。

• ブラウザの新しいリリースやユーザーのハードウェアの改善により、ページの読み込み速度が向上する場合があります。
• 休日などの重要なイベントでは、トラフィックが通常とは異なる場合があります。

また、上記の調査を確認するために、前後の 75 パーセンタイルの LCP 全体を見ることも役に立ちます。母集団の特定の部分について学習したからといって、必ずしも母集団全体を把握できるとは限りません。たとえば、SXG によってページ読み込みの 10% が 800 ミリ秒改善されたとします。

• これらがすでに 10% 高速のページ読み込みであった場合は、75 パーセンタイルには影響しません。
• もしページ読み込みが 10% 最も遅いものの、最初の 75 パーセンタイルの LCP より 800 ミリ秒以上遅かった場合、75 パーセンタイルにはまったく影響しません。

これらは極端な例であり、現実を反映していない可能性がありますが、問題を示していることを願っています。実際には、SXG はほとんどのサイトで 75 パーセンタイルに影響を与えます。クロスサイト ナビゲーションは最も遅い傾向があり、プリフェッチによる改善は著しい傾向があります。

一部の URL をオプトアウトする

最後に、SXG のパフォーマンスを比較する 1 つの方法は、サイト上の一部の URL に対して SXG を無効にすることです。たとえば、CDN-Cache-Control: no-store ヘッダーを設定すると、Cloudflare ASX が SXG を生成しないようにできます。この方法はおすすめしません。

他の調査方法に比べて選択バイアスのリスクが大きいと考えられます。たとえば、サイトのホームページや人気のある URL をコントロール グループとテストグループのどちらにするかによって、大きな違いが生じることがあります。

ホールドバック調査

効果を測定する理想的な方法は、ホールドバック調査を実施することです。申し訳ございませんが、現在、このようなテストは行えません。今後、このようなテストもサポートする予定です。

ホールドバック スタディには次の特性があります。

• テストグループでは、SXG になると思われるページビューの一部が「保留」され、代わりに SXG 以外の広告が配信されます。これにより、同等のユーザー、デバイス、シナリオ、ページ間で「同一条件」比較が可能になります。
• 保留された（反事実的）ページビューには、アナリティクスではそのようにラベル付けされます。これにより、データを「拡大」して表示し、コントロールの SXG ページの読み込みをテストの SXG の反事実と比較できます。これにより、SXG プリフェッチの影響を受けない他のページ読み込みのノイズが削減されます。

これにより、前述の選択バイアスの原因となり得るものがなくなりますが、LCP のサバイバーシップ バイアスのリスクは排除されません。どちらのプロパティも有効にするには、ブラウザまたは参照 URL が必要です。

おわりに

これでかなりの量でした。ラボテストで SXG のパフォーマンスをテストする方法、ラボテストでタイトなフィードバック ループ内でパフォーマンスを最適化する方法、最終的に実際のパフォーマンスでパフォーマンスを測定する方法についての全体像をつかむことができれば幸いです。これらすべてを組み合わせることで、SXG を最大限に活用し、SXG がサイトとユーザーに利益をもたらします。

SXG のパフォーマンスを把握する方法について、他にもアドバイスがございましたら、ぜひお聞かせください。改善案とともに developer.chrome.com にバグを報告します。

Signed Exchange について詳しくは、web.dev のドキュメントと Google 検索のドキュメントをご覧ください。