Chrome でページを事前レンダリングしてページ ナビゲーションを即時に行う

Barry Pollard

対応ブラウザ

  • 109
  • 109
  • x
  • x

Chrome チームは、ユーザーがアクセスする可能性の高い今後のページを完全に事前レンダリングするオプションの開発に取り組んできました。

事前レンダリングの略歴

以前は、Chrome は <link rel="prerender" href="/next-page"> リソースヒントをサポートしていましたが、Chrome を超えて広くサポートされていたわけではありません。また、表現力の高い API でもありませんでした。

リンク rel=prerender ヒントを使用した以前の事前レンダリングは非推奨となりました。代わりに NoState Prefetch に置き換えられました。NoState Prefetch は今後のページで必要となるリソースを取得していましたが、ページの事前レンダリングや JavaScript の実行は完全には行われませんでした。NoState のプリフェッチは、リソースの読み込みを改善することでページのパフォーマンスを向上させますが、完全な事前レンダリングのような即時のページ読み込みは配信しません。

Chrome チームはこのたび、完全な事前レンダリング機能を Chrome に再び導入しました。既存の使用方法に伴う複雑さを回避し、将来の事前レンダリングの拡張を可能にするために、この新しい事前レンダリング メカニズムでは <link rel="prerender"...> 構文を使用しません。これは、将来的に廃止するという観点から、NoState Prefetch 用に残っています。

ページの事前レンダリングはどのように行われますか？

ページは、次の 4 つの方法のいずれかで事前レンダリングできます。いずれの方法も、ナビゲーションを高速化することを目的としています。

  1. Chrome のアドレスバー（アドレスバー）に URL を入力すると、そのページにアクセスすることが確実であれば、Chrome でそのページが自動的に事前レンダリングされます。
  2. Chrome のアドレスバーに検索キーワードを入力すると、検索エンジンからの指示に基づいて、検索結果ページが自動的に事前レンダリングされる場合があります。
  3. サイトでは、Speculation Rules API を使用して、事前レンダリングするページを Chrome にプログラムで指示できます。これは、<link rel="prerender"...> が従来の処理に取って代わるもので、サイトがページの投機ルールに基づいて事前にページを事前レンダリングできるようにします。アノテーションは、ページに静的に配置することも、ページの所有者が必要に応じて JavaScript によって動的に挿入することもできます。

いずれの場合も、事前レンダリングは非表示の背景タブでページが開かれたかのように動作し、フォアグラウンド タブをその事前レンダリングされたページに置き換えることで「アクティブ」になります。事前レンダリングが完了する前にページが有効化されると、現在の状態は「フォアグラウンド化」され、引き続き読み込まれるため、スムーズに開始できます。

事前レンダリングされたページは非表示の状態で開かれるため、煩わしい動作を引き起こす多くの API（プロンプトなど）がこの状態では有効化されず、ページが有効化されるまで遅延します。まだこの処理が不可能な少数のケースでは、事前レンダリングはキャンセルされます。Chrome チームは、事前レンダリングのキャンセル理由を API として公開する取り組みと、こうしたエッジケースを簡単に特定できるように DevTools の機能を強化しています。

事前レンダリングの影響

次の動画に示すように、事前レンダリングにより、ページをほぼ瞬時に読み込むことができます。

事前レンダリングの影響の例

サンプルサイトはすでに高速のサイトですが、事前レンダリングによってユーザー エクスペリエンスがどのように向上するかがおわかりいただけると思います。したがって、サイトの Core Web Vitals にも直接的な影響があり、LCP がほぼゼロになり、CLS が削減され（読み込みは最初のビューより前に行われるため）、INP が改善されます（読み込みはユーザーの操作前に完了するため）。

ページが完全に読み込まれる前に有効化される場合でも、ページの読み込みを早く開始することで、読み込みエクスペリエンスが改善されます。事前レンダリングが行われている間にリンクを有効にすると、事前レンダリング ページはメインフレームに移動し、読み込みが続行されます。

ただし、事前レンダリングでは追加のメモリとネットワーク帯域幅が使用されます。過剰な事前レンダリング（ユーザー リソースを犠牲にする可能性があります）に注意する必要があります。事前レンダリングは、移動先のページに移動する可能性が高い場合にのみ行います。

分析で実際のパフォーマンスへの影響を測定する方法について詳しくは、パフォーマンスの測定セクションをご覧ください。

Chrome のアドレスバーの予測候補を表示する

最初のユースケースでは、Chrome の URL 予測を chrome://predictors ページで確認できます。

入力したテキストに基づいて低（グレー）、中（黄色）、高（緑色）の予測を表示するためにフィルタされた Chrome の予測ページのスクリーンショット。
Chrome の予測機能のページ

緑色の線は、事前レンダリングをトリガーできる十分な信頼度を示しています。この例では、「s」と入力すると妥当な信頼度（黄色）になりますが、「sh」と入力すると、Chrome によりほぼ必ず https://sheets.google.com に移動できるようになります。

このスクリーンショットは、比較的新しい Chrome インストールで撮影されたものです。信頼度ゼロの予測はフィルタで除外されていますが、独自の予測子を表示すると、かなり多くのエントリが表示され、十分な信頼度に到達するために必要な文字数が増える可能性があります。

これらの予測子は、アドレスバーへの推奨オプションを制御する要素でもあります。

アドレスバーの「Typeahead」機能のスクリーンショット
アドレスバーの「Typeahead」機能

Chrome では、ユーザーの入力や選択に基づいて予測子が継続的に更新されます。

  • 信頼度が 50% を超える場合（黄色で表示）は、Chrome はドメインに事前に接続しますが、ページは事前レンダリングされません。
  • 信頼度（緑色で表示）が 80% を超える場合、Chrome は URL を事前レンダリングします。

Speculation Rules API

3 つ目の事前レンダリング オプションでは、JSON 命令をページに挿入して、事前レンダリングする URL をブラウザに伝えることができます。

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

または、ドキュメント ルール（Chrome 121 から利用可能）を使用して、ドキュメント内のリンクを href または CSS セレクタに基づいて事前レンダリングします。

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

意欲

対応ブラウザ

  • 121
  • 121
  • x
  • x

eagerness 設定は、投機を開始するタイミングを示すために使用されます。これは、ドキュメントのルールに特に役立ちます。

  • immediate: 可能な限り早く、つまり投機ルールが確認され次第、推測を行う場合に使用します。
  • eager: これは immediate 設定と同じように動作しますが、将来的には immediate と moderate の間のどこかに配置する予定です。
  • moderate: リンクに 200 ミリ秒カーソルを合わせると推測が実行されます（その時間が短い場合は pointerdown イベント、hover イベントが発生していないモバイル イベントの場合）。
  • conservative: ポインタまたはタッチダウンを推測します。

list ルールのデフォルトの eagerness は immediate です。moderate オプションと conservative オプションを使用すると、list ルールをユーザーが操作する URL を特定のリストに制限できます。ただし、多くの場合は、適切な where 条件が定義された document ルールのほうが適切です。

document ルールのデフォルトの eagerness は conservative です。ドキュメントは多数の URL で構成されている可能性があるため、document ルールに immediate または eager を使用する場合は注意が必要です（次の Chrome の制限もご覧ください）。

どちらの eagerness 設定を使用するかは、サイトによって異なります。軽量で静的なサイトの場合、より積極的に憶測することはほとんど費用がかからず、ユーザーにとって有益です。アーキテクチャが複雑でページのペイロードが重いサイトでは、推測する頻度を下げることで無駄を削減する傾向があります。無駄を省くという意図について、ユーザーからより肯定的な兆候が得られるまでです。

moderate オプションは中立的であり、多くのサイトは、ホバーまたはポインタダウン時にすべてのリンクを事前レンダリングする次の投機ルールを、基本的かつ強力な投機ルールの実装として活用できます。

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

プリフェッチ

投機ルールは、完全な事前レンダリングを行わずに、ページをプリフェッチするためだけにも使用できます。これは多くの場合、事前レンダリングへの最初のステップとして最適です。

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Chrome の制限

Chrome では、Speculation Rules API の過剰使用を防ぐために次の制限を設けています。

熱意 プリフェッチ 事前レンダリング
immediate / eager 50 10
moderate / conservative 2（FIFO） 2（FIFO）
Chrome の推測の制限。

ユーザーの操作に依存する moderate と conservative の設定は、先入れ先出し（FIFO）方式で機能します。上限に達すると、新たな投機により最も古い投機がキャンセルされ、新しい投機に置き換えられてメモリを節約します。リンクをもう一度カーソルを合わせるなどして、キャンセルされた投機的処理を再度トリガーできます。その結果、その URL の投機的処理が行われ、最も古い投機的処理がプッシュされます。この場合、以前の投機によってその URL の HTTP キャッシュにキャッシュ可能なリソースがキャッシュされているので、さらに時間投機することでコストを削減できるはずです。上限が中程度のしきい値 2 に設定されているのはそのためです。静的リストルールは、ユーザーの操作によってトリガーされるわけではないため、ブラウザではどれがいつ必要かを判断できないため、上限を引き上げます。

immediate と eager の制限も動的であるため、list URL スクリプト要素を削除すると、削除された投機的処理がキャンセルされ、容量が発生します。

また、Chrome では、次のような特定の状況で憶測の使用を防ぐこともできます。

  • データの保存。
  • 省エネツール: 有効でバッテリー残量が少ない場合。
  • メモリ制約。
  • [ページをプリロードする] 設定がオフになっている場合（uBlock Origin などの Chrome 拡張機能でも明示的にオフになっています）。
  • バックグラウンドのタブで開いたページです。

また、Chrome では、有効にするまで事前レンダリングされたページでクロスオリジンの iframe はレンダリングされません。

これらすべての条件は、ユーザーに害を及ぼす可能性がある場合に過剰な憶測による影響を軽減することを目的としています。

ページに投機ルールを含める方法

投機ルールは、ページの HTML に静的に挿入することも、JavaScript を使用して動的に挿入することもできます。

  • 静的に追加された投機ルール: たとえば、ニュース メディア サイトやブログが最新記事を事前レンダリングすることが多い場合、その記事が多くのユーザーの次のナビゲーションになることが多い場合、moderate または conservative を含むドキュメント ルールを使用して、ユーザーがリンクを操作するのを推測できます。
  • 動的に挿入される投機ルール: アプリケーション ロジック、ユーザーに合わせてパーソナライズされる、その他のヒューリスティックに基づいて行われます。

これまで多くのライブラリが <link rel=prefetch> を使用して行ってきたように、リンクにカーソルを合わせたり、クリックしたりするなどのアクションに基づいて動的挿入を好む場合は、ドキュメント ルールを確認することをおすすめします。ドキュメント ルールにより、ブラウザは多くのユースケースに対応できます。

投機ルールは、メインフレームの <head> または <body> のいずれかに追加できます。サブフレーム内の投機ルールは動作せず、事前レンダリングされたページの投機ルールは、そのページが有効になったときにのみ実行されます。

Speculation-Rules HTTP ヘッダー

対応ブラウザ

  • 121
  • 121
  • x
  • x

ソース

ドキュメントの HTML に直接ルールを含めるのではなく、Speculation-Rules HTTP ヘッダーを使用して投機ルールを配信することもできます。これにより、CDN によるデプロイが簡単になり、ドキュメントの内容自体を変更する必要がなくなります。

Speculation-Rules HTTP ヘッダーがドキュメントとともに返され、投機ルールを含む JSON ファイルの場所が示されます。

Speculation-Rules: "/speculationrules.json"

このリソースは正しい MIME タイプを使用し、クロスオリジン リソースの場合は CORS チェックに合格する必要があります。

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

相対 URL を使用する場合は、投機ルールに "relative_to": "document" キーを含めることができます。指定しない場合、相対 URL は投機ルール JSON ファイルの URL を基準とします。これは、一部またはすべてのオリジンのリンクを選択する必要がある場合に特に便利です。

投機ルールと SPA

投機ルールは、ブラウザで管理されるフルページ ナビゲーションでのみサポートされています。Single Page Apps（SPA）ページや App Shell ページではサポートされていません。このアーキテクチャでは、ドキュメントの取得を使用せず、代わりにデータやページの API 取得または部分取得を行います。取得されたデータは、現在のページで処理されて表示されます。こうしたいわゆる「ソフト ナビゲーション」に必要なデータは、投機ルールの範囲外でアプリによってプリフェッチされる可能性がありますが、事前レンダリングはできません。

投機ルールを使用すると、前のページからアプリケーション自体を事前にレンダリングできます。これにより、一部の SPA で発生する追加の初期読み込みコストの一部を相殺できます。ただし、アプリ内のルート変更は事前レンダリングできません。

投機ルールをデバッグする

この新しい API の表示とデバッグに役立つ Chrome DevTools の新機能については、投機ルールのデバッグに関する投稿をご覧ください。

複数の投機ルール

複数の投機ルールを同じページに追加して、既存のルールに追加することもできます。したがって、次のような方法ではいずれも one.html と two.html の両方の事前レンダリングを行います。

URL のリスト:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

複数の speculationrules:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

1 つの speculationrules セット内の複数のリスト

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

対応ブラウザ

  • 121
  • 121
  • x
  • x

ソース

ページのプリフェッチや事前レンダリングを行う際、特定の URL パラメータ（厳密には検索パラメータ）は、サーバーによって実際に配信されるページにとって重要ではなく、クライアント側の JavaScript でのみ使用されます。

たとえば UTM パラメータは、Google アナリティクスでキャンペーンの測定に使用されますが、通常、サーバーから異なるページが配信されることはありません。つまり、page1.html?utm_content=123 と page1.html?utm_content=456 はサーバーから同じページを配信するため、同じページをキャッシュから再利用できます。

同様に、アプリケーションは、クライアント側でのみ処理される他の URL パラメータを使用することがあります。

No-Vary-Search の提案では、配信されるリソースに違いがないパラメータをサーバーで指定できるため、以前にキャッシュされたドキュメントのバージョンのうち、これらのパラメータだけが異なるバージョンをブラウザで再利用できます。この機能は、プリフェッチ ナビゲーションの推測についてのみ Chrome（および Chromium ベースのブラウザ）でサポートされています。

投機ルールでは、expects_no_vary_search を使用して、No-Vary-Search HTTP ヘッダーが返される場所を指定できます。これにより、不必要なダウンロードをさらに回避できます。

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

この例では、/products の最初のページの HTML は、商品 ID 123 と 124 で同じです。ただし、JavaScript を使用して商品データを取得するクライアント側のレンダリング（id 検索パラメータ）によって、ページのコンテンツは最終的に異なります。そのため、その URL を積極的にプリフェッチすると、任意の id 検索パラメータにページが使用できることを示す No-Vary-Search HTTP ヘッダーが返されます。

ただし、プリフェッチが完了する前にユーザーがリンクのいずれかをクリックした場合、ブラウザは /products ページを受け取っていない可能性があります。この場合、ブラウザは No-Vary-Search HTTP ヘッダーを含めるかどうかを認識しません。その後、ブラウザはリンクを再度取得するか、プリフェッチが完了するのを待ってから、No-Vary-Search HTTP ヘッダーが含まれているかどうかを確認するかを選択できます。expects_no_vary_search 設定により、ブラウザはページ レスポンスに No-Vary-Search HTTP ヘッダーが含まれていると認識し、プリフェッチが完了するまで待機できます。

投機ルールに関する制限と今後の機能強化

推測ルールを適用できるのは、同じタブ内で開いたページに限られますが、Google では制限を減らすよう取り組んでいます。デフォルトでは、事前レンダリングは同一オリジン ページに限定されています。

同一サイトのクロスオリジン ページの事前レンダリング（例: https://a.example.com により https://b.example.com でページを事前レンダリングできます）。これを使用するには、事前レンダリングされたページ（この例では https://b.example.com）で Supports-Loading-Mode: credentialed-prerender HTTP ヘッダーを含めることでオプトインする必要があります。オプトインしない場合、事前レンダリングは Chrome によってキャンセルされます。

今後のバージョンでは、クロスオリジン ページ（同様の Supports-Loading-Mode: uncredentialed-prerender HTTP ヘッダーでオプトインするサイト）での事前レンダリングを許可し、新しいタブで事前レンダリングを有効にすることもできます。

Speculation Rules API サポートを検出する

Speculation Rules API をサポートするには、標準の HTML チェックを使用します。

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

JavaScript を使用して投機ルールを動的に追加する

以下は、JavaScript で prerender 投機ルールを追加する例です。

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

こちらの事前レンダリングのデモページで、JavaScript 挿入を使用した Speculation Rules API 事前レンダリングのデモを見ることができます。

投機ルールをキャンセルする

投機ルールを削除すると事前レンダリングはキャンセルされますが、事前レンダリングを開始するまでにリソースがすでに費やされている可能性が高いため、事前レンダリングをキャンセルする必要がある可能性がある場合は、事前レンダリングを行わないことをおすすめします。

推測ルールとコンテンツ セキュリティ ポリシー

投機ルールは <script> 要素を使用するため、JSON しか含まれていませんが、サイトでハッシュまたはノンスを使用してこれを使用する場合は、script-src Content-Security-Policy に要素を含める必要があります。

新しい inline-speculation-rules を script-src に追加して、ハッシュまたはノンスクリプトから挿入された <script type="speculationrules"> 要素をサポートできるようになりました。最初の HTML に含まれるルールはサポートされていないため、厳格な CSP を使用しているサイトの場合、JavaScript によってルールを挿入する必要があります。

事前レンダリングを検出して無効にする

事前レンダリングでは、ページをすばやく（多くの場合は瞬時に）レンダリングできるため、通常はユーザーにとってポジティブなエクスペリエンスです。事前レンダリングされたページは、他の方法では実現が難しいユーザー エクスペリエンスの向上に役立つため、ユーザーとサイト所有者の双方にメリットがあります。

ただし、最初のリクエストに基づいて、またはページで実行中の JavaScript に基づいてページの状態が変更された場合など、ページの事前レンダリングを行わない場合もあります。

Chrome で事前レンダリングを有効または無効にする

事前レンダリングは、chrome://settings/performance/ で [ページをプリロードする] 設定を有効にしている Chrome ユーザーに対してのみ有効になります。また、メモリの少ないデバイスや、オペレーティング システムがデータ保存モードや省エネモードの場合も、事前レンダリングは無効になります。詳しくは、Chrome の制限事項をご覧ください。

サーバーサイドの事前レンダリングを検出して無効にする

事前レンダリングされたページは、Sec-Purpose HTTP ヘッダーとともに送信されます。

Sec-Purpose: prefetch;prerender

Speculation Rules API を使用してプリフェッチされたページでは、このヘッダーは prefetch のみに設定されます。

Sec-Purpose: prefetch

サーバーはこのヘッダーに基づいて応答し、投機リクエストをログに記録したり、別のコンテンツを返したり、事前レンダリングが行われないようにしたりできます。失敗のレスポンス コード（200 や 304 以外）が返された場合、ページは事前レンダリングされず、プリフェッチ ページはすべて破棄されます。

特定のページが事前レンダリングされないようにするには、この方法が最善の方法です。ただし、最適なエクスペリエンスを提供するには、代わりに事前レンダリングを許可し、JavaScript を使用して、ページが実際に表示された後にのみ行われるべきアクションを遅らせることをおすすめします。

JavaScript で事前レンダリングを検出する

ページが事前レンダリングされている間、document.prerendering API は true を返します。これにより、事前レンダリング中にページが実際にアクティブになるまでの特定のアクティビティを防止（遅延）させることができます。

事前レンダリングされたドキュメントが有効になると、PerformanceNavigationTiming の activationStart も、事前レンダリングが開始されてからドキュメントが実際に有効になるまでの時間を表すゼロ以外の時間に設定されます。

次のように、事前レンダリングされたページと事前レンダリングされたページを確認する関数を用意できます。

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

ページが事前レンダリングされたかどうかを確認する最も簡単な方法は、事前レンダリングが行われた後に DevTools を開き、コンソールに「performance.getEntriesByType('navigation')[0].activationStart」と入力することです。ゼロ以外の値が返された場合は、ページが事前レンダリングされたことを意味します。

ページが事前レンダリングされたことを示すアクティベーションスタートを示す Chrome DevTools のコンソール
コンソールで事前レンダリングをテストする

ページを表示しているユーザーがページを有効にすると、document で prerenderingchange イベントがディスパッチされます。これにより、以前はページの読み込み時にデフォルトで開始されていたが、ユーザーが実際にページを表示するまで遅延させたいアクティビティを有効にできます。

フロントエンド JavaScript はこれらの API を使用することで、事前レンダリングされたページを適切に検出して処理できます。

分析への影響

アナリティクスは、Google アナリティクスを使用してページビューやイベントを測定するなど、ウェブサイトの使用状況を測定するために使用されます。または、リアルユーザー モニタリング（RUM）を使用してページのパフォーマンス指標を測定することもできます。

ページが事前レンダリングされるのは、ユーザーがそのページを読み込む可能性が高い場合のみです。そのため、Chrome のアドレスバーの事前レンダリング オプションは、確率が非常に高い場合にのみ（80% を超える確率で）発生します。

ただし、特に Speculation Rules API を使用している場合、事前レンダリングされたページは分析に影響を及ぼす可能性があります。また、すべての分析プロバイダがデフォルトでこの処理を行っているわけではないため、サイト所有者は、有効化時に事前レンダリングされたページの分析のみを有効にするためにコードを追加する必要がある場合があります。

これは、ドキュメントが事前レンダリング中の場合は prerenderingchange イベントを待機し、事前レンダリングが開始された場合はすぐに解決する Promise を使用することで実現できます。

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve);
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

パフォーマンスの測定

アナリティクスでパフォーマンス指標を測定する場合、ブラウザ API が報告するページ読み込み時間ではなく、有効化日時を基準とした測定が適しているかどうかを検討する必要があります。

Chrome ユーザー エクスペリエンス レポートを通じて Chrome が測定する Core Web Vitals は、ユーザー エクスペリエンスを測定することを目的としています。そのため、これらは有効化日時に基づいて測定されます。たとえば、多くの場合、LCP は 0 秒になります。これは、Core Web Vitals を改善する優れた方法であることを示しています。

バージョン 3.1.0 以降、Chrome が Core Web Vitals を測定するのと同じ方法で事前レンダリングされたナビゲーションを処理するように、web-vitals ライブラリが更新されました。このバージョンでは、Metric.navigationType 属性で、これらの指標の事前レンダリングされたナビゲーションにもフラグを設定します。

事前レンダリングを測定する

ページが事前レンダリングされているかどうかは、ゼロ以外の activationStart エントリ PerformanceNavigationTiming で確認できます。これは、ページビューをログに記録するときに、カスタム ディメンションなどを使用してログに記録できます。たとえば、前述の pagePrerendered 関数を使用します。

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

これにより、他のタイプのナビゲーションと比較して事前レンダリングされたナビゲーションの数を分析で把握できるほか、パフォーマンス指標やビジネス指標をこれらのナビゲーション タイプに関連付けることもできます。ページの読み込みが速いほどユーザーの満足度が高くなり、事例紹介が示すように、多くの場合、ビジネス指標に実質的な効果をもたらします。

ページの事前レンダリングによるビジネスへの影響を測定する際に、この技術を使用して事前レンダリングできるナビゲーションを増やしたり、ページが事前レンダリングされない理由を調査したりすることにもっと労力を費やす価値があるかどうかを見極めることができます。

ヒット率を測定する

事前レンダリング後にアクセスしたページの影響を測定するだけでなく、事前レンダリングされた後でアクセスされなかったページも測定することが重要です。これは、事前レンダリングを多くし、ユーザーの貴重なリソースをほとんど使い果たしていることを示唆しています。

これは、ブラウザで HTMLScriptElement.supports('speculationrules') を使用した事前レンダリングをサポートしていることを確認した後、投機ルールが挿入されたときに分析イベントを発生させて、事前レンダリングがリクエストされたことを示すことで測定できます。（事前レンダリングがリクエストされたからといって、事前レンダリングの開始または完了を示すものではありません。前述のとおり、事前レンダリングはブラウザに対するヒントであり、ユーザー設定、現在のメモリ使用量、その他のヒューリスティックに基づいてページを事前レンダリングしない場合があります）。

これらのイベントの数と実際の事前レンダリングのページビューを比較できます。あるいは、比較しやすい場合は、アクティベーション時に別のイベントを発生させます。

これら 2 つの数値の差を確認することで、「成功したヒット率」を近似できます。Speculation Rules API を使用してページを事前レンダリングしているページでは、ルールを適切に調整して高いヒット率を維持することで、ユーザーの支援のためにリソースを使い果たしたり、不必要に使用したりするバランスを維持できます。

事前レンダリングは、推測ルールに限らず、アドレスバーの事前レンダリングによって発生することもあります。これらを区別する場合は、document.referrer（事前レンダリングされたアドレスバー ナビゲーションを含め、アドレスバー ナビゲーションでは空白になります）をチェックします。

事前レンダリングが行われていないページも忘れずに確認しましょう。事前レンダリングが行われないページは、アドレスバーからでも事前レンダリングの対象ではない可能性があるからです。このパフォーマンスの強化によるメリットが得られていない可能性があります。Chrome チームは、bfcache テストツールに似た、事前レンダリングの適格性をテストするためのツールを追加することを検討しています。また、事前レンダリングが失敗した理由を明らかにする API を追加する可能性もあります。

拡張機能への影響

Chrome 拡張機能: API を拡張してインスタント ナビゲーションをサポートする記事をご覧ください。拡張機能の作成者が事前レンダリングするページで考慮すべきその他の考慮事項について詳しく説明しています。

フィードバック

事前レンダリングは Chrome チームによって積極的に開発されており、Chrome 108 リリースで利用できる範囲を拡大する多くの計画が存在します。GitHub リポジトリや Google の Issue Tracker を使用してフィードバックをお寄せください。また、この新しい API の事例紹介もぜひお寄せください。

謝辞

Marc-Olivier Jodoin 氏によるサムネイル画像（Unsplash）