ブラウザのプリレンダリングと投機的ナビゲーション(Speculation Rules)

投機的ナビゲーションとは何か：遷移を先回りする

ユーザーがリンクをクリックしてから次のページが表示されるまでには、本来「URL解決→リクエスト→レスポンス受信→HTMLパース→サブリソース取得→描画」という一連のコストがかかります。投機的ナビゲーション（speculative navigation） は、ユーザーが次にどこへ行くかをあらかじめ推測し、このコストをクリック前に先払いしておく技術です。うまく当たれば、クリックの瞬間に残っているのは「用意済みのものを前面に出す」操作だけになり、体感は即時に近づきます。

この先払いには段階があります。軽い順に prefetch（先行取得） と prerender（プリレンダ） の2つで、どこまで先払いするかが違います。

prefetch は遷移時にネットワーク往復を省きますが、パースと描画はクリック後に行われます。prerender はパースと描画まで済ませて待機させるため、遷移時はほぼ表示だけで済みます。代わりに当たらなかったときの無駄（取得したデータ・消費したCPUとメモリ）が大きいので、確度に応じて使い分けるのが原則です。

Speculation Rules API：宣言的に投機を指定する

かつての <link rel="prefetch"> や非標準の <link rel="prerender"> は、URLを1つずつ静的に書くしかなく、条件や確度を表現できませんでした。Speculation Rules API はこれを置き換えるもので、<script type="speculationrules"> に JSON を書いて「どのURL群を、どの手段で、どの確度（eagerness）で投機するか」を宣言します。

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/articles/*" },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": { "selector_matches": ".nav-link" },
      "eagerness": "conservative"
    }
  ]
}
</script>

where で対象URLを指定します。href_matches はURLパターン、selector_matches はそのセレクタに一致するリンク（href）を対象にする、という具合です。urls で明示列挙もできます。ここで重要なのが eagerness（積極度） で、ブラウザがいつ投機を始めるかを制御します。

conservative はクリック直前（ボタンを押し込んだ瞬間）に投機するため無駄が最小ですが、先払いできる時間も最短です。immediate は確実ですが外れたときの浪費が最大になります。ブラウザはこの宣言をヒントとして受け取り、回線状況・メモリ・省データ設定・同時投機数の上限などを見て、実際に投機するかを最終判断します。宣言は強制ではない点が肝心です。

プリレンダ中の状態：見えていないページの制約

prerender されたページは、ユーザーには見えない非表示の別タブのような環境で構築されます。この間ページは prerendering 状態 に置かれ、document.prerendering が true になります。問題は、まだ誰も見ていない・操作していないページが、勝手に副作用を起こしてはいけない点です。そこでブラウザはプリレンダ中の挙動に多くの制約を課します。

ここで実務上の落とし穴になるのが アクセス解析や広告のビーコン です。プリレンダ段階でページビューを送ってしまうと、実際にはユーザーが来ていない（外れた投機の）ぶんまで計上され、水増しが起こります。これを避けるため、計測タグはプリレンダ中に発火させず、アクティベーション後に送る設計にする必要があります。多くの解析ライブラリは document.prerendering を見て自動で遅延しますが、自作のビーコンは自分で制御しなければなりません。

アクティベーション：凍結を前面へ昇格する瞬間

ユーザーが実際にそのURLへ遷移すると、ブラウザは裏で用意したプリレンダ済みドキュメントを前面に昇格させます。これを アクティベーション（activation） と呼びます。ここで決定的に重要なのは、ページのロードがやり直されないことです。HTML の再取得も、再パースも、スクリプトの再実行もありません。すでに生きているドキュメントが、そのまま「見えるタブ」になります。

この設計のため、初回ロード前提のフックだけでは「表示された瞬間」を捉えられません。アクティベーションを検知する専用のシグナルが用意されています。

if (document.prerendering) {
  // まだ非表示。準備だけ進め、副作用は保留する
  document.addEventListener('prerenderingchange', onActivated, { once: true });
} else {
  // 通常ロード、またはすでにアクティベート済み
  onActivated();
}

function onActivated() {
  // 「ユーザーに見えた」後にだけやるべきこと
  sendPageView();          // 計測ビーコンはここで
  startAutoplayIfNeeded(); // メディア再生もここで
  focusSearchBox();        // フォーカス移動もここで
}

prerenderingchange イベントは、prerendering 状態が解けた（=アクティベートされた）瞬間に document 上で発火します。document.prerendering はこの時点で false になります。プリレンダ中に保留していた副作用は、すべてこのフックの先で解放するのが定石です。

bfcache・プリロードスキャナとの違い

似た「速くする仕組み」と混同しないことが大切です。プリレンダは遷移前に未来のページを新規構築するのに対し、bfcache（Back/Forward Cache） は過去に訪れたページの生きた状態を凍結して戻る/進むで復元します。前者は前向き（これから行く先）、後者は後ろ向き（来た道）の最適化で、復元時のイベントも異なります（プリレンダは prerenderingchange、bfcache は pageshow の event.persisted）。

また prefetch/prerender は「ページ単位で次の遷移先を丸ごと先払いする」のに対し、プリロードスキャナ は「現在のページの中で、これから要るサブリソースを先に取得する」仕組みです。スコープが「次のページ全体」か「今のページの部品」かで層が違います。

セキュリティ・運用上の注意

プリレンダはサーバーから見ると「ユーザーがまだ来ていないのにリクエストが飛んでくる」状況を生みます。Sec-Purpose: prefetch のようなリクエストヘッダでブラウザが投機リクエストであることを示すため、サーバー側は副作用のある GET を投機で叩かれても安全かを点検し、必要なら投機リクエストを識別して扱いを変えられます（破壊的操作を GET に載せない原則がここでも効きます）。

クロスサイト prefetch がプロキシ経由・Cookie なしで行われることも運用上の前提です。ログイン依存のコンテンツはこの匿名取得では正しく取れないため、prerender（same-site・通常の資格情報あり）と prefetch（cross-site・匿名）で取得結果が変わることを理解しておきます。コンテンツの取り扱いは CSP（Content Security Policy） とも関係し、プリレンダされる側のページも自身の CSP に従って評価されます。

まとめ