このページは Cloud Translation API によって翻訳されました。

Speculation Rules API を改善

Barry Pollard

Chrome チームは、今後のナビゲーションをプリフェッチまたはプリレンダリングしてナビゲーションのパフォーマンスを向上させるために使用される Speculation Rules API のアップデートに取り組んできました。これらの追加の改善はすべて Chrome 122 で利用可能になりました（一部の機能は以前のバージョンでも利用できます）。

これらの変更により、ページのプリフェッチとプリレンダリングを大幅に簡単にデプロイできるようになり、無駄が減ります。これにより、さらなる導入が促進されることを願っています。

その他の機能

まず、Speculation Rules API に追加された新機能とその使用方法について説明します。その後、デモをご覧いただき、実際に使用方法をご確認ください。

ドキュメントのルール

以前の Speculation Rules API では、プリフェッチまたはプリレンダリングする URL のリストを指定することで動作していました。

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

推測ルールは半動的で、新しい推測ルールスクリプトを追加したり、古いスクリプトを削除して推測を破棄したりできました（既存の推測ルールスクリプトの urls リストを更新しても、推測の変更はトリガーされません）。ただし、URL の選択はサイトに委ねられていました。URL は、ページリクエスト時にサーバーから送信するか、クライアントサイドの JavaScript を使用して動的に作成します。

リストルールは、シンプルなユースケース（次のナビゲーションが明白な少数のページから行われる）や、高度なユースケース（サイト所有者が使用するヒューリスティクスに基づいて URL のリストが動的に計算され、ページに挿入される）では引き続き使用できます。

代わりに、ドキュメントルールを使用してリンクを自動的に検出する新しいオプションもご利用いただけます。これは、where 条件に基づいてドキュメント自体から URL を取得することで機能します。これは、リンク自体に基づく場合があります。

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

CSS セレクタは、href の一致の代替として、または href の一致と組み合わせて、現在のページ内のリンクを検出するために使用することもできます。

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

これにより、ページごとに特定の推測ルールを使用するのではなく、サイト全体で単一の推測ルールを使用できるため、サイトが推測ルールをデプロイしやすくなります。

ページ上のすべてのリンクを事前レンダリングするのは無駄であるため、この新機能には eagerness 設定が導入されています。

熱意

推測には、適合率と再現率とリードタイムのトレードオフがあります。ページの読み込み時にすべてのリンクを事前レンダリングすると、ユーザーがクリックするリンク（ページ上の同一サイトのリンクを想定）を事前レンダリングすることがほぼ確実になり、できるだけ長いリードタイムで事前レンダリングされますが、帯域幅の無駄が非常に大きくなる可能性があります。

一方、ユーザーがリンクをクリックした後にのみプリレンダリングを行うと、無駄を防ぐことができますが、リードタイムが大幅に短縮されます。つまり、ブラウザがそのページに切り替わる前に事前レンダリングが完了することはほとんどありません。

eagerness 設定を使用すると、推測を実行するタイミングを定義できます。推測を実行するタイミングと、推測を実行する URL を分離できます。eagerness 設定は、list ソースルールと document ソースルールの両方で使用できます。4 つの設定があり、Chrome には次のヒューリスティックがあります。

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": [{
    "source": "document",
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Chrome の制限

eagerness を選択した場合でも、Chrome にはこの API の使いすぎを防ぐための上限が設定されています。

`eagerness`	プリフェッチ	Prerender（事前レンダリング）
`immediate` / `eager`	50	10
`moderate` / `conservative`	2（FIFO）	2（FIFO）

Chrome での推測の制限

ユーザー操作に依存する moderate 設定と conservative 設定は、先入れ先出し（FIFO）方式で動作します。上限に達すると、新しい推測によって最も古い推測がキャンセルされ、メモリを節約するために新しい推測に置き換えられます。

moderate と conservative の推測はユーザーによってトリガーされるため、2 という比較的低いしきい値を使用してメモリを節約できます。immediate と eager の設定はユーザー操作によってトリガーされないため、ブラウザがどの設定が必要で、いつ必要かを把握できないため、上限が緩和されています。

FIFO キューから押し出されてキャンセルされた推測は、そのリンクに再度カーソルを合わせるなどして再度トリガーできます。その結果、その URL が再推測されます。その場合、以前の推測により、ブラウザがその URL の HTTP キャッシュに一部のリソースをキャッシュに保存している可能性があります。そのため、推測を繰り返しても、ネットワークコストと時間コストが大幅に削減されます。

immediate と eager の上限も動的です。これらのエアグリスレベルを使用して推測ルールスクリプト要素を削除すると、削除された推測がキャンセルされ、容量が作成されます。これらの URL は、新しい URL スクリプトに含まれており、上限に達していない場合は、再推定することもできます。

また、Chrome では、次のような特定の条件下で推測が使用されないようにします。

[Save-Data] をクリックします。
省エネツール。
メモリの制約。
[ページをプリロードする] 設定がオフになっている場合（uBlock Origin などの Chrome 拡張機能によって明示的にオフになっている場合も同様）。
バックグラウンドタブで開いたページ。

これらの条件はすべて、過剰な投機がユーザーに不利益をもたらす場合に、その影響を軽減することを目的としています。

省略可の `source`

Chrome 122 では、url キーまたは where キーの存在から推測できるため、source キーを省略可能にしました。したがって、次の 2 つの推測ルールは同じです。

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

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

`Speculation-Rules` HTTP ヘッダー

推測ルールは、ドキュメントの 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 を基準とします。これは、同じオリジンのリンクの一部またはすべてを選択する必要がある場合に特に便利です。

キャッシュの再利用の改善

Chrome のキャッシュにいくつかの改善を加えたため、ドキュメントのプリフェッチ（またはプリレンダリング）で HTTP キャッシュにリソースを保存して再利用できるようになります。つまり、その推測が使用されなくても、将来的に利益をもたらす可能性があります。

また、キャッシュに保存可能なリソースに対して Chrome が HTTP キャッシュを使用するため、再推定（moderate の早期取得設定が適用されたドキュメントルールの場合など）の費用が大幅に削減されます。

また、キャッシュの再利用をさらに改善する新しい No-Vary-Search プロポーザルもサポートしています。

`No-Vary-Search` のサポート

ページのプリフェッチまたはプリレンダリングを行う場合、特定の 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 ヘッダーが含まれていることがブラウザに通知され、そのプリフェッチが完了するまで待機できます。

デモ

https://speculative-rules.glitch.me/common-fruits.html にデモを作成しました。このデモでは、moderate の早期実行設定が適用されたドキュメントルールを確認できます。

DevTools を開き、[Application] パネルをクリックします。次に、[バックグラウンドサービス] セクションで [推測読み込み]、[推測] ペインをクリックし、[ステータス] 列で並べ替えます。

フルーツにカーソルを合わせると、ページがプリレンダリングされます。これらのレシピをクリックすると、事前レンダリングされていない他のレシピよりも LCP 時間が大幅に短縮されます。このデモについては、こちらの動画でも説明しています。

DevTools を使用して推測ルールをデバッグする方法については、以前の推測ルールのデバッグに関するブログ投稿もご覧ください。

推測ルールのプラットフォームサポート

推測ルールは、<script type="speculationrules"> 要素にルールを挿入することで比較的簡単に実装できますが、プラットフォームのサポートにより、ワンクリックで実装できます。Google は、さまざまなプラットフォームやパートナーと連携して、憶測に関するルールをより簡単に展開できるように取り組んできました。

また、ウェブインキュベーターコミュニティグループ（WICG）を通じてAPI の標準化にも取り組んでおり、他のブラウザでもこのエキサイティングな API を実装できるようにしています。

WordPress

WordPress コアパフォーマンスチーム（Google のデベロッパーを含む）が Speculation Rules プラグインを作成しました。このプラグインを使用すると、WordPress サイトにドキュメントルールのサポートをワンクリックで簡単に追加できます。このプラグインは、WordPress Performance Lab プラグインからインストールすることもできます。このプラグインは、チームが提供する関連するパフォーマンスプラグインの最新情報を入手できるため、インストールすることをおすすめします。

設定には、推測モードと早期実行の 2 つのグループがあります。

推測ルールの設定が適用された WordPress 設定の読み取りパネルのスクリーンショット。2 つのオプションがあります。プリフェッチまたはプリレンダリングのオプションがある推測モードと、Conservative、Moderate、Eager の設定がある Eagerness 設定です。 — WordPress 投機ルールプラグイン

特定の URL をプリフェッチまたはプリレンダリングから除外するなど、より複雑な設定については、ドキュメントをご覧ください。

Akamai

Akamai は世界をリードする CDN プロバイダの 1 社であり、Speculation Rules API を積極的にテストしています。Akamai は、CDN 設定でこの API を有効にする方法に関するドキュメントを公開しています。また、この新しい API で達成できる優れた結果も以前に共有しています。

NitroPack

NitroPack は、カスタムナビゲーション AI を使用して、推測ルールに追加するページを予測するパフォーマンス最適化ソリューションです。リンクにカーソルを合わせるよりも長いリードタイムを提供することを目的としていますが、検出されたすべてのリンクを無駄に推測することはありません。詳しくは、Nitropack Speculation Rules API のドキュメントをご覧ください。この革新的なソリューションは、古いリストルールをサイト固有のインサイトと組み合わせることで、まだ多くのメリットがあることを示しています。

また、Chrome チームは NitroPack と協力して、Speculation Rules API に関するウェビナーを開催しました。このウェビナーでは、早期かつ頻繁に推測するか、遅くかつ頻繁に推測するかの違いで考慮すべき点について、詳しく説明しています。

天体写真

Astro では、4.2 で Speculation Rules API を使用したページの事前レンダリングが試験運用版として追加されました。これにより、Astro を使用しているデベロッパーは、この機能を簡単に有効にしながら、Speculation Rules API をサポートしていないブラウザでは標準のプリフェッチにフォールバックできます。詳しくは、クライアントの事前レンダリングに関するドキュメントをご覧ください。

まとめ

Speculation Rules API に追加されたこれらの機能により、サイトのパフォーマンスを向上させるこの新しい機能をより簡単に使用できるようになります。また、未使用の推測によってリソースを浪費するリスクも軽減されます。すでにこの API を活用しているプラットフォームが出てきています。2024 年には、この API が広く普及し、最終的にエンドユーザーのパフォーマンスが向上することを願っています。

Speculation Rules API はパフォーマンスの向上につながるだけでなく、新しい機会も開く可能性があります。ビュー遷移は、デベロッパーがナビゲーション間の遷移をより簡単に指定できる新しい API です。現在、シングルページアプリケーション（SPA）で利用できます。マルチページバージョンは現在開発中です（Chrome ではフラグ設定で利用できます）。プリレンドは、遷移が意図するユーザーエクスペリエンスの向上を妨げる遅延を回避するために、その機能に自然に追加されるものです。すでにこの組み合わせをテストしているサイトがあります。

2024 年を通じて Speculation Rules API のさらなる導入を期待しています。API の改善については、随時最新情報をお知らせします。

謝辞

サムネイル: Unsplash の Robbie Down