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 を送信するか、クライアントサイドの 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>

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

もちろん、ページ上のすべてのリンクを事前レンダリングするのは明らかに無駄なので、この新しい機能では eagerness 設定を導入しました。

熱意

どのような根拠であれ、適合率と再現率とリードタイムの間にはトレードオフがあります。ページの読み込み時にすべてのリンクを事前レンダリングすると、ユーザーがクリックしたリンク（ページ内の同じサイトリンクがクリックされたと仮定）はほぼ確実に事前レンダリングされます。また、リードタイムも可能な限り余裕を持って行われますが、帯域幅が大量に浪費される可能性があります。

一方、ユーザーがリンクをクリックした後にのみ事前レンダリングを行うと無駄はなくなりますが、リードタイムは大幅に短縮されます。つまり、ブラウザがページに切り替える前に事前レンダリングが完了する可能性は低くなります。

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

  • immediate: 可能な限り早く、つまり投機ルールが遵守され次第、推測に使用されます。
  • eager: 現時点では immediate の設定と同じように動作しますが、将来的には immediate から moderate の間に配置する予定です。
  • moderate: リンクを 200 ミリ秒間（それより早く、hover イベントがないモバイルでは pointerdown イベントで）カーソルを合わせると推測が実行されます。
  • 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 では、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 によるデプロイが簡単になります。

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

Speculation-Rules: "/speculationrules.json"

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

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

相対 URL を使用する場合は、推測ルールに "relative_to": "document" キーを含めることができます。それ以外の場合、相対 URL は投機ルールの JSON ファイルの URL の相対 URL になります。この方法は、一部（またはすべて）の同一オリジンのリンクを選択する必要がある場合に特に便利です。

キャッシュの再利用性の向上

ドキュメントのプリフェッチ（または事前レンダリング）によって 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 ベースのブラウザ）でのみ、プリフェッチによるナビゲーションの推測のためにサポートされています。

推測ルールでは、No-Vary-Search HTTP ヘッダーが返される場所を示すために expects_no_vary_search を使用できます。これにより、不要なダウンロードをさらに防ぐことができます。

<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>

この例では、商品 ID 123 と 124 の両方で、/products の最初のページの HTML は同じです。ただし、最終的には、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 の先行度設定が動作しているドキュメント ルールの動作を確認できます。

<ph type="x-smartling-placeholder">
</ph> 果物のラベルが付いた複数のリンクを一覧表示するデモサイトのスクリーンショット。DevTools が開き、2 つのリンク（apple.html と Orange.html）がすでに正常に事前レンダリングされていることがわかります。
投機ルールのデモ

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

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

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

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

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

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

WordPress

WordPress Core Performance チーム（Google のデベロッパーを含む）は、投機ルール プラグインを作成しました。このプラグインを使用すると、ワンクリックで任意の WordPress サイトにドキュメント ルールのサポートを追加できます。このプラグインは、WordPress Performance Lab プラグインからインストールすることもできます。チームから、関連するパフォーマンス プラグインの最新情報を入手できるよう、インストールを検討することをおすすめします。

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

<ph type="x-smartling-placeholder">
</ph> WordPress 設定の読み取りパネルと投機ルールの設定のスクリーンショット。選択肢は 2 つあります。[Prefetch] または [Prerender] を選択できる [Speculation] モードと、[Eagerness] 設定で [Conservative]、[Moderate]、[Eager] のいずれかです。
WordPress の投機ルール プラグイン

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

まとめ

Speculation Rules API が新たに追加されることで、この優れた新しいパフォーマンス機能をサイトで使用することがはるかに容易になり、未使用の投機付けでリソースを浪費するリスクが軽減されます。多くのプラットフォームがすでにこの API を利用しているのは喜ばしいことです。2024 年にはこの API の導入が拡大し、最終的にエンドユーザーのパフォーマンス向上が見込まれています。

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

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

謝辞

Robbie Down のサムネイル、Unsplash より