Speculation Rules API を改善

Barry Pollard

Chrome チームは、Speculation Rules API にいくつかのアップデートを行ってきました。この API は、今後のナビゲーションのプリフェッチや事前レンダリングによってナビゲーションのパフォーマンスを向上させるのに役立っています。これらの改善された機能はすべて Chrome 122 からご利用いただけます（一部の機能は以前のバージョンからご利用いただけます）。

これらの変更により、ページのプリフェッチと事前レンダリングが大幅に容易になり、無駄が少なくなるため、さらなる導入が促進されることを期待しています。

その他の機能

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

ドキュメントのルール

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

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

投機ルールは、新しい投機ルール スクリプトを追加し、古いスクリプトを削除してそれらの投機を破棄することができるという点で、ほぼ動的なものでした（既存の投機ルール スクリプトの urls リストを更新しても、投機の変更はトリガーされません）。しかし、ページのリクエスト時にサーバーから URL を送信するか、クライアント サイドの JavaScript でこのリストを動的に作成するか、サイトの URL の選択が残っています。

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

代わりに、ドキュメントのルールを使用した自動リンク検索の新しいオプションをご紹介します。これは、where 条件に基づいてドキュメント自体から URL をソーシングすることで機能します。リンクそのものに基づいて判断できます。

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

CSS セレクタを代替手段として、または href 一致と併用して、現在のページ内のリンクを検索することもできます。

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

これにより、サイト全体で 1 つの投機ルールセットを使用できるようになり、ページごとに特定のルールセットを使用する必要がなくなり、サイトははるかに簡単に投機ルールを展開できます。

もちろん、ページ上のすべてのリンクを事前レンダリングするのは間違いなく無駄なことになるため、この新しい機能では 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 プリフェッチ 事前レンダリング
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 では、次のような特定の状況で憶測の使用を防ぐこともできます。

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

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

省略可 source

Chrome 122 では、source キーは url キーまたは where キーの有無から推測できるため、省略可能になりました。したがって、これら 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 との相対 URL になります。これは、一部またはすべてのオリジンのリンクを選択する必要がある場合に特に便利です。

キャッシュ再利用の改善

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

また、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 が開き、2 つのリンク（apple.html と orange.html）がすでに正常に事前レンダリングされていることが示されます。
投機ルールのデモ

DevTools を開き、[アプリケーション] パネルをクリックします。次に、[バックグラウンド サービス] セクションで [投機的読み込み]、[投機的読み込み] ペインの順にクリックし、[ステータス] 列を基準に並べ替えます。

果物の上にカーソルを合わせると、ページの事前レンダリングを確認できます。レシピをクリックすると、事前レンダリングされないレシピよりも LCP 時間がはるかに短くなります。このデモは、次の動画でも説明されています。

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

投機ルールのプラットフォーム サポート

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

また、Web Incubator Community Group（WICG）を通じて API の標準化を進め、他のブラウザでもこの API を実装できるように取り組んでいます。

WordPress

WordPress Core Performance チーム（Google のデベロッパーを含む）は、Speculation Rules プラグインを作成しました。このプラグインを使用すると、ドキュメント ルールのサポートを任意の WordPress サイトにワンクリックで追加できます。このプラグインは、WordPress Performance Lab プラグインからインストールすることもできます。このプラグインは、担当チームが配信する関連パフォーマンス プラグインについて常に最新情報を把握できるため、インストールもご検討ください。

[投機モード] と [意欲] の 2 つのグループの設定があります。

Speculation Rules が設定されている WordPress 設定閲覧パネルのスクリーンショット。オプションは 2 つあります。[プリフェッチまたは事前レンダリング] が可能な [投機的] モードと、[控えめ]、[中程度]、または [積極的] 設定の [積極性] 設定です。
WordPress Speculation Rules プラグイン

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

Akamai

Akamai は世界をリードする CDN プロバイダの一つであり、以前から Speculation Rules API を積極的にテストしてきました。Akamai は、お客様が CDN 設定でこの API を有効にする方法に関するドキュメントをリリースしました。同社は以前、この新しい API によって実現した素晴らしい成果についても話しています。

NitroPack

NitroPack は、カスタムの Navigation AI を使用してどのページを投機ルールに追加するかを予測するパフォーマンス最適化ソリューションです。リンクにカーソルを合わせるよりも長いリードタイムを確保しつつ、観察されたすべてのリンクを不必要に推測する無駄を省くことを目的としています。詳しくは、Nitropack Speculation Rules API ドキュメントをご覧ください。この革新的なソリューションは、サイト固有の分析情報と組み合わせることで、古いリストルールで提供できるものがまだたくさんあることを示しています。

Chrome チームはさらに NitroPack と協力して、Speculation Rules API に関するウェブセミナーを開催しました。このウェブセミナーでは、早い段階で推測することと頻繁に行うことや、推測を行うタイミングと頻度を減らすことについて、必要な考慮事項について適切なディスカッションを行っています。

Astro

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

おわりに

Speculation Rules API にこれらの新機能を追加したことで、この優れた新しいパフォーマンス機能をサイトでより簡単に使用できるようになり、使用されていない投機によってリソースを無駄にするリスクが低減されます。すでにプラットフォームがこの API を活用しているのは嬉しいことです。2024 年には、この API の採用が拡大し、最終的にエンドユーザーに対するパフォーマンスの向上が見込まれます。

Speculation Rules API によってパフォーマンスが向上するだけでなく、この機能によってどのような新たな機会が生まれるかも楽しみです。View Transitions は、デベロッパーがナビゲーション間の遷移をより簡単に指定できるようにする新しい API です。この機能は現在、シングルページ アプリケーション（SPA）で利用できますが、マルチページ バージョンは開発中です（Chrome のフラグによって利用可能）。事前レンダリングは、遅延が発生しないようにするための自然なアドオンです。遅延が発生しないようにすると、移行で想定されるユーザー エクスペリエンスの向上が妨げられます。この組み合わせによるテストはすでに実施されています。

Google は、2024 年を通して Speculation Rules API をさらに導入したいと考えており、API のさらなる改善については随時お知らせいたします。

謝辞

Robbie Down さんのサムネイル（Unsplash）