Prerender Until Script: PrefetchとPrerenderの中間
スクリプトを実行したりアナリティクスを汚染したりすることなく、サブリソースを読み込んでDOMを構築する
Origin Trial: prerender_until_scriptはChrome 144から150までのOrigin Trialとして利用可能です。トークンを登録するか、chrome://flags/#prerender-until-scriptを介してローカルで有効にする必要があります。ShipへのIntent（出荷の意図）はまだ提出されていません。
Last reviewed by Arjen Karel on March 2026
Prerender Until Script: Speculative Loadingの新しいモード
レイテンシがボトルネックです。私は何年にもわたってこれを言い続けてきましたが、Webパフォーマンスにおける単一の最大の問題であり続けています。Critical Rendering Pathをどれだけ最適化しても、バンドルから数キロバイトを削っても、私たちは最終的に物理法則とネットワークのラウンドトリップタイム(RTT)に縛られます。
長い間、私たちはSpeculative Loadingを使用してこれらの法則を回避しようとしてきました。つまり、ユーザーが次にどこに行くかを推測し、それを事前にロードすることです。これまで、私たちには2つの主なツールがありましたが、どちらも完璧ではありませんでした。
- prefetch: 安全で軽量ですが、HTMLのみをフェッチします。ユーザーがクリックした後でも、ブラウザは解析を行い、DOMを構築し、サブリソース（CSS、画像）を発見する必要があります。ネットワークの待機は解決しますが、レンダリング作業は解決しません。
- prerender: 強力な手段です。すべてを読み込み、JavaScriptを実行し、非表示のバックグラウンドタブでページをレンダリングします。即時ですが、コストがかかります。帯域幅を消費し、メモリを消費し、ユーザーが決して見ないかもしれないページのためにアナリティクスのピクセルを発火させ、コードを実行します。
中間地点が必要でした。アプリケーションロジックを実行するコストやリスクなしに、prerenderの視覚的な準備ができる状態です。
prerender_until_scriptの仕組み
prerender_until_scriptは解析と実行を切り離します。このSpeculation Ruleを使用すると、ブラウザに次のことを指示します。
- ドキュメントをフェッチする（prefetchのように）。
- HTMLストリームを解析し、DOMを構築する。
- Preload Scannerを実行する。これが重要な部分です。ブラウザは優先度の高いCSSやLCP画像などのサブリソースを発見し、ダウンロードします。
パーサーがJavaScriptの実行ポイントに遭遇した瞬間、次の2つのことが起こり得ます。
- 同期スクリプト: パーサーは即座に停止します。
- 非同期/遅延スクリプト (Async/defer scripts): ダウンロードされてキューに入れられますが、実行されません。
ブラウザはページの視覚的なシェルを構築します。レイアウト、タイポグラフィ、画像などです。しかし、アプリケーションロジックは凍結されたままです。ページはメモリ内に存在し、完全にレイアウトされ、ユーザーがクリックするのを待っています。
クリックが発生すると、ページは即座に入れ替わります。JavaScriptが実行され、イベントハンドラーがアタッチされ、アナリティクスはまさに期待通りのタイミングで発火します。
Prefetch vs prerender_until_script vs prerender
| アクション | HTMLをフェッチ | HTMLを解析 | サブリソースをフェッチ | スクリプトを実行 | アナリティクス発火 |
|---|---|---|---|---|---|
prefetch | Yes | No | No | No | No |
prerender_until_script | Yes | Yes | Yes | No | No |
prerender | Yes | Yes | Yes | Yes | Yes* |
* 完全なprerenderでは、document.prerenderingを使用して時期尚早なアナリティクスを防ぐことができますが、そのコードは自分自身で追加する必要があります。
これがprerender_until_scriptが重要である理由です。完全なprerenderのサブリソースの読み込みとDOM構築を得られますが、アナリティクスの汚染やJavaScriptを実行するメモリコストはありません。重いサードパーティスクリプトを抱えるコンテンツサイトにとって、これはスイートスポットです。
実装
これをSpeculation Rules APIを使用して実装します。prerender_until_scriptは実験的（Chrome 144から150までのOrigin Trial）であるため、後方互換性が必要です。
prerender_until_scriptキーを認識しないブラウザはそれを無視します。同じURLセットに対してprefetchのfallbackを追加します。Chromeはこれらのルールを重複排除し、利用可能な最も機能的なアクションを適用します。
<script type="speculationrules">
{
"prerender_until_script": [
{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/cart" } }
]
},
"eagerness": "moderate"
}
],
"prefetch": [
{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/cart" } }
]
},
"eagerness": "moderate"
}
]
}
</script>
prefetchブロックはfallbackです。prerender_until_scriptをサポートするブラウザでは、Chromeが自動的に最も機能的なアクションを選択します。そうでないブラウザでは、prefetchルールが引き続き実行されます。ユーザーエージェントスニッフィングを行うことなく、利用可能な最良の動作を得ることができます。
独自のカスタム推測ルールセットを生成したい場合は、speculation rules generatorを使用してください。
prerender_until_scriptを有効にする方法
これはOrigin Trialであるため、2つのオプションがあります。
- Chrome Origin TrialsダッシュボードでOrigin Trialトークンに登録します。
<head>内に<meta>タグとしてトークンを追加します：<meta http-equiv="origin-trial" content="YOUR_TOKEN"> chrome://flags/#prerender-until-scriptに移動し、フラグを有効にしてローカルでテストします。
Origin Trialは、Chrome 144（2026年1月）からChrome 150（2026年半ば頃）まで実行されます。Chromeチームがそれ以降に安定版機能として提供する場合、トークンは必要なくなります。公式のChromeブログ投稿で詳細が網羅されています。
実際のSpeculation Rulesのパフォーマンス
まだ誰もprerender_until_scriptのベンチマークを公開していません（新しすぎるため）。しかし、より広範なSpeculation Rules APIには、主要なデプロイからのハードデータがあります。
- Ray-Banはprerender推測ルールを実装し、モバイルで43%のLCP改善（4.69秒から2.66秒）を確認しました。コンバージョン率は倍増しました。
- Shopifyは、すべてのLiquidストアフロント全体にprefetch推測ルールを展開し、すべてのロード指標にわたってデスクトップで130ミリ秒、モバイルで180ミリ秒の高速化を測定しました。
- Cloudflare Speed BrainはML予測モデルを使用した推測ルールを使用し、成功したprefetchにおいてLCPが45%削減されたと報告しています。
採用は急速に拡大しています。2025 Web Almanacによると、モバイルウェブサイトの35%が現在Speculation Rules APIを使用しています。その成長の大部分は、2025年3月に推測ルールをコアに組み込んだWordPress 6.8からもたらされています。
prerender_until_scriptは、prefetchと完全なprerenderの間の結果をもたらすはずです。サブリソースはすでにキャッシュされており、DOMは構築されています。アクティベーション時に残された唯一の作業は、スクリプトの実行です。CoreDashが監視しているサイト全体で、私は通常、推測ルールが後続のナビゲーションLCPを30〜50%削減するのを目にしています。
考慮事項
Eagerness（積極性）: 私はほぼ例外なくmoderateを推奨します。これにより、ホバー時（ポインターが200ミリ秒間留まったとき）に推測がトリガーされます。immediateはほとんどのサイトにとって攻撃的すぎ、モバイル接続の帯域幅を無駄にするリスクがあります。
除外: ここでは規律を持ってください。/logoutや/add-to-cartのような状態を変更するURLを決して推測しないでください。prerender_until_scriptはスクリプトの実行から保護しますが、これらのエンドポイントを不必要にフェッチするべきではありません。
パーサーのブロック: 同期<script>タグに遭遇すると、パーサーは即座に停止します。DOMの早い段階でインラインスクリプトがある場合（例えば、<script>loadWhileIdle(chat.js)</script>）、prerenderはそこで停止します。スクリプトをページの下部に移動するか、deferを使用して、DOMが事前に構築される割合を最大化します。
インラインハンドラー: prerender_until_scriptは<script>要素のみを一時停止します。ブロッキングスクリプトより前にパーサーが到達した場合、他の要素のインラインイベントハンドラー（<img onload="track()">など）は依然として実行されます。アナリティクスやトラッキングがインラインハンドラーによってトリガーされないようにしてください。
Chrome DevToolsのApplicationパネルで推測ルールをデバッグできます。Chrome DevToolsのNetworkパネルでも、推測的なフェッチが明確なアイコンで表示されます。Real User Monitoringを使用して、本番環境に推測ルールを展開した後の実際のINPとLCPへの影響を検証します。
