すぐに利用できるテクノロジーの概要です。
ページの読み込み速度が重要な理由
ほとんどのユーザーは、ページの読み込みが遅いことが主な不満の要因として日常的に挙げています（Google が実施したユーザー調査では 54%）。したがって、ページの読み込みが速くなるほど、ビジネスの成果が向上するとしても、当然のことではありません。実際、ウェブサイトにアクセスする前から訪問者がイライラすると、その価値を実感できるほど長く滞在する可能性は低くなります。実際、254 の e コマース、金融、旅行サイトを対象とした別の Google 調査では、読み込み時間が 2 秒以下のサイトではコンバージョン率が 15% 高いことが示されています。
Largest Contentful Paint（LCP）の高速化
ことわざにもあるように、測定なくして改善を図ることはできません。ウェブのユーザー エクスペリエンスについては、Core Web Vitals が、ユーザー エクスペリエンスの基本的な側面を捉えるために設計されたユーザー中心の指標セットであると考えています。特に、Largest Contentful Paint（LCP）は、ユーザーが目にする最大のテキストまたは画像ブロックを表示するのにかかる時間を報告することにより、ページの読み込みパフォーマンスを測定します。優れたユーザー エクスペリエンスを提供するため、LCP はページの読み込み開始から 2.5 秒以内（つまり、良好な LCP の基準値）である必要があります。
一般的なページの LCP に影響する要因を見てみましょう。
ユーザーがページにアクセスすると、ブラウザはサーバーに HTML をリクエストします。サーバーは HTML で応答します。この HTML は、CSS、JavaScript、フォント、画像など、次に取得するコンテンツに関するヒントをブラウザに提供します。レスポンスが返されると、ブラウザもレスポンスを評価し、最終的にページ上にコンポーネントをレイアウトしてペイントする必要があります。しかし、パケットがデバイスからサーバーに到達し、その後デバイスに戻るのを待つ時間の大半が費やされます。実際、Google のデータ（Chrome for Android、中央値）によれば、ユーザーが感じるレイテンシの約 40% は、通常、サーバーからの最初のバイトの応答をブラウザが待つことに費やされています。
プリフェッチの利点
これらのファイルをすべてプリフェッチできる、つまり、ユーザーがページにアクセスする前にフェッチできれば、ページを表示する前に、評価、レイアウトの計算、ペイントといったいくつかのタスクを残すだけで、大幅な高速化が可能になります。
先ほど共有されたデータを考慮すると、メインリソースをプリフェッチするだけでも、ページ読み込みを大幅に高速化できます。同一サイトの場合、このタイプの手法は rel=prefetch などのプリミティブで簡単に利用できます。しかし、クロスサイト シナリオはそれほど単純ではありません。
クロスサイト ナビゲーション
プリフェッチは以前から存在していますが、ユーザーが別のサイトにアクセスしているときにページをプリフェッチする場合は、追加の考慮事項があります。
参照サイトからブラウザに別のサイトからのページをプリフェッチするよう指示したとします。明らかに、プリフェッチされたページへのリンクをユーザーがクリックすると、ページ読み込みがはるかに速くなり、ユーザー エクスペリエンスが向上します。しかし、ユーザーがこのリンクをクリックしなかった場合は、どうなるでしょうか。リンク先ウェブサイトは、参照元サイトでそのトピックを閲覧しているときに、そのトピックに興味を持っている可能性があると気付くことを期待しません。ただし、プリフェッチ リクエストには、他の通常のリクエストと同様に、ユーザーの IP アドレスと Cookie（存在する場合）が含まれるため、これは大きなリスクとなります。
ソリューション
プライバシーに配慮したクロスサイト プリフェッチを可能にするために、Google は過去 3 年間にわたり Private Prefetch Proxy と Signed Exchange（SXG）という 2 つのソリューションを開発してきました。また、クロスオリジン プリフェッチが速度面で大きなメリットをもたらすことを確認するため、大規模なテストを実施しました。具体的には、Google がユーザーの次のナビゲーション用にメイン HTML を安全にプリフェッチできた事例を見ると、LCP が「良好」なページ読み込みの割合が 14% 増加したことがわかりました。
考慮すべきポイント
Private Prefetch Proxy と Signed Exchange は同じユースケースを解決しますが、それぞれのテクノロジーには異なるトレードオフがあります。そのため、最適な選択はサイト固有のニーズによって異なります。関連するトレードオフを理解できるように、次のセクションでは、クロスサイト プリフェッチの有効化と、利用可能な 2 つのテクノロジーの選択に関する 2 つの重要な考慮事項について説明します。また、各テクノロジーの詳細記事でも詳細をご確認いただけます。
リピーター
クロスサイト プリフェッチは、サイトに初めてアクセスするユーザーにとっては簡単に有効にできます。リピーターの場合は、サイトをどの程度パーソナライズするかによって異なります。つまり、プライバシー上の理由から、クロスサイト プリフェッチ リクエストに Cookie を含めることはできません。
- 初回のビジターには Cookie がないため、この制限によって何の問題も生じません。したがって、サイトに変更を加えることなく、これらのユーザーに対してクロスサイト プリフェッチを有効にできます。
- クロスサイト プリフェッチを有効にして、サイトを Cookie に基づいてパーソナライズする場合は、ユーザーの移動後にこれらのパーソナライズされた要素を遅延読み込みする必要があります。なぜなら、ユーザーがウェブサイトへのアクセスを明示的に選択したため、ナビゲーション時に Cookie の制限が不要になるためです。したがって、ナビゲーション時に、サイトは通常どおりに Cookie にアクセスできます。具体的なガイダンスについては、遅延読み込みのベスト プラクティスをご覧ください。
- 現在、パーソナライズを HTML に直接エンコードしている場合でも、Cookie があれば引き続きエンコードを継続できます。また、プリフェッチされたページのフォールバック戦略として遅延読み込みを使用できます。
- サイトが Cookie に基づいてパーソナライズされていない場合や、パーソナライズが重要でない場合は、新規ユーザーに対して、初回訪問者と同じコンテンツを配信するよう選択できます。
現時点では、Private Prefetch Proxy は初回訪問者（Cookie のないリンク）に対してのみ有効になっており、範囲をリピーター（Cookie のあるリンク）に拡大するための継続的な取り組みが行われています。一方、Signed Exchange では、新規訪問者とリピーターの両方を対象として、すでにクロスサイト プリフェッチをサポートしています（上述のアプローチを使用）。
プリフェッチによる追加データの提供
クロスサイト プリフェッチを有効にすると、余分なデータが提供される可能性があります。実際には、リファラーがページをプリフェッチしても、ユーザーがリンクをクリックしなかった場合は、トラフィックが増加することになります。
- これを軽減するために、プリフェッチ リクエストでリファラーが積極的に使用されないようにリクエストすることもできます。同様に、リファラー（ブラウザ）も、比較的軽量でありながら重要なリソース（メインリソース、クリティカル CSS、JavaScript サブリソースなど）に重点を置くことで、この問題を軽減できます。これは基本的に、速度のメリットとトラフィックの増加とのトレードオフです。
- または、追加のキャッシュ保存を有効にすることで、このトラフィックを相殺することもできます（詳しくは、Signed Exchange に関するこちらのセクションをご覧ください）。この方法の欠点は、コンテンツを長期間キャッシュに保存すると、ユーザーに古い情報が表示される可能性があることです。これは基本的に、追加のデータ配信とコンテンツの更新頻度とのトレードオフです。
ここで最善の判断を下すには、サイトのどの部分が「更新頻度」が「最大」なのか、それとも「追加リクエスト数が最小限」なのかを自問する必要があります。この質問に対する答えは、最終的にはビジネスとユーザーの具体的なニーズによって異なります。
ご利用にあたって
これらの技術は Google 検索に組み込まれたため、サイトの LCP はすぐに改善される可能性があります。これにより、他の人気参照元もフォローし、全体的なウェブの高速化につながることを願っています。
これらのテクノロジーはどちらも同じユースケースを解決しますが、前述の重要な考慮事項に関して異なるトレードオフがあります。ニーズやメリットへの理解が進展するにつれ、一方のテクノロジーから始めて、もう一方のテクノロジーに移行することも考えられます。お客様の状況に最適なテクノロジーを見極めるために、以下の詳細をご覧ください。