指がリンクから離れる前に、次のページはもう届き始めている――Speculation Rules APIという先読みの賭け

公開前の下書きです。事実確認と編集を終えていますが、公開・SNS投稿はまだ行っていません。

ECサイトで商品カードにカーソルを乗せる。指がクリックする前のほんの一瞬、対応ブラウザは既にその商品ページのHTMLを裏側で取りに行き始めている。クリックした瞬間には、ページの一部が既に手元に届いている——これがSpeculation Rules API（投機的読み込みルールAPI）が実現しようとしている体験だ。JSON形式のルール、またはHTTPヘッダで「どのリンクを、どれくらい積極的に」事前取得するかをブラウザに宣言する仕組みで、prefetch（HTMLだけを事前に取得する軽量な先読み）と、prerender(見えない裏タブでページ全体を事前にレンダリングしてしまう重い先読み)の2種類がある。

Shopifyは2025年6月、1年以上の実験を経てプラットフォーム全体にこの仕組みを本番導入し、実訪問者のA/Bテストでデスクトップ平均130ms、モバイル平均180msの読み込み速度改善を計測したと公式ブログで報告した。一方でこの技術は、2026年7月時点でもMDNが「Limited availability」「Experimental」と明記する、Baseline（主要ブラウザで広く使える状態を示すMDN/web.devの基準）に達していない実験的機能でもある。編集部は、この技術を単なる高速化テクニックとしてではなく、「読まれるかどうか分からないページに、通信量とサーバー負荷を先に賭ける」というトレードオフとして議論した。

結論：Speculation Rules APIは、体感速度と引き換えに転送量・サーバー負荷・計測精度というコストを前払いする「賭け」であり、現状、既定で有効なのはChromium系ブラウザのみという実験的機能である（Safariには実装が存在するが既定で無効）。Shopifyの130〜180ms改善は保守的なprefetch設定での実測値であり、prerenderならもっと速いという短絡は成り立たない。副作用のあるページ遷移をprerenderすると計測タグの誤発火などの実害が起き得るため、Chromeは2026年1月から「prerender until script」という折衷策のOrigin Trialを始めている。サイト運営者が安全に始める道筋は、副作用のない軽量なページ・遷移確率の高い主要導線に対象を絞ったprefetchから着手し、通信環境やサーバー負荷に応じて動的に制御することだ。

仕組みと対応状況：恩恵を受けるのは今のところChromium系だけ

ナオ（Webパフォーマンスを取材する技術記者）は議論の冒頭で、「prerenderを使えば瞬時にページが開く」と考えるのは早計だと釘を刺した。

「prerenderを使えば瞬時にページが開く」と考えるのは早計です。Shopifyが2025年6月に発表した数値は、あくまでmousedown等のトリガーによる「prefetch」を用いた保守的な設定での結果であり、デスクトップで130ms、モバイルで180msの改善に留まっています。prerenderならもっと速いと期待するのは、実測値に基づかない推論です。

Speculation Rules APIはWICG（Web Incubator Community Group、ブラウザベンダーが新機能を提案・検証する場）による提案仕様で、対応状況はブラウザごとに大きく異なる。Chrome/Edgeはprerenderキーが105、prefetchキーが110、eagerness（後述する積極度の指定）・whereキーとHTTPヘッダが121、ドキュメントルール（ページ内のリンクを自動収集する書き方）が122と、段階的に機能を積み上げてきた。Firefoxは未対応で、prefetch部分については前向きな標準化姿勢を表明済みだが、まだ出荷されていない。SafariはSafari 26.2に実装自体は存在するものの、デフォルトで無効になっている。

ブラウザ	対応状況
Chrome / Edge	prerender（105〜）、prefetch（110〜）、eagerness・where・HTTPヘッダ（121〜）、ドキュメントルール（122〜）
Firefox	未対応。prefetchには前向きな標準化姿勢を表明済みだが未出荷
Safari	Safari 26.2に実装は存在するが、デフォルトで無効

この表はMDNとcaniuseの記載を基にした編集部の整理である。現状、恩恵を受けられるのはChromium系ブラウザの利用者に限られる。

Shopifyの実測値：130〜180msは何を変えるのか

ハルト（ECサイトのパフォーマンス改善を担う開発者)は、ナオの指摘に同意しつつ、実務者としての手応えを語った。

ナオの指摘通り、この技術は「万能な魔法」ではなく、リソースを投じる「賭け」としての側面が強い。特にモバイル環境では、180msの改善がユーザーの離脱抑制に寄与する一方で、意図しない先読みが従量課金回線のユーザーの負担やバッテリー消費を招くリスクは無視できない。

Shopifyの実測は、mousedown/touchstart相当のトリガーでprefetchを行う保守的な設定によるもので、TTFB(サーバーが最初の応答を返すまでの時間)やFCP・LCP(画面に最初のコンテンツ・最大のコンテンツが表示されるまでの時間)を、実訪問者データのA/Bテストで計測した結果だ。130〜180ミリ秒という数字は、人間が意識的に「速くなった」と気づく境目にはまだ届かないかもしれない。しかし、ECサイトの離脱率は読み込み待ちのわずかな遅延にも敏感に反応することが知られており、特にモバイル回線では通信状況のばらつきそのものが体感速度を左右するため、平均で180ms縮まることの意味は小さくない。

ここで重要なのは、Shopifyの数字が「prefetchという軽い先読み」による結果だという点だ。ページ全体を事前レンダリングするprerenderを使えばもっと速くなるはずだ、という推論は一次情報源のどこにも裏付けがない。編集部の議論も、この短絡を避けることを共通の前提にしている。

反論1：無駄になる転送・サーバー負荷は誰が払うのか

レン（インフラコストを管理するSRE）は、体感速度の裏にあるコスト構造を指摘した。

スクリプト実行を遅延させても、HTMLやリソースの転送量、サーバーのCPU・メモリ負荷という物理的なコストは、ユーザーが遷移しない限り発生し続けるからです。(中略)サーバー側は「読まれないかもしれないリクエスト」のために、全ユーザーに対して予測不能なトラフィック増への備えを強いられます。

先読みは、クリックされて初めて「当たり」になる賭けだ。カーソルを乗せただけで離脱した場合、取得したHTMLはそのまま無駄になる。これはサーバー側の転送量・処理負荷として跳ね返るコストであり、レンはこれを「インフラのキャパシティプランニングにおける不確実性を増大させる行為」と表現した。

反論2：通信費を払うのは常にユーザー側だ

ミサ（デジタル格差を研究する社会学者）は、コストの負担者が誰かという論点を持ち込んだ。

スクリプトの遅延がサーバー負荷を減らしても、HTMLや画像の転送自体は発生します。これは、通信量に制限がある従量課金回線ユーザーにとって、実質的な「見えない課金」を強いる行為です。(中略)富裕層向けブラウザの利便性を、低コストな通信環境のユーザーの資源で肩代わりさせる構造を生んでいます。

この指摘は、Chromium限定という対応状況の偏りとも重なる。恩恵を受けるのは最新のChromium系ブラウザを使う層である一方、先読みで消費される通信量の負担は、モバイル回線や従量課金プランを使うユーザーにも及ぶ。速度と負担が同じ人に紐づくとは限らない、という非対称性が議論の核にあった。

ソラ（ネットショッピングをよく使う生活者代表）も、生活者としての実感を交えて次のように述べている。

この技術がChromium系限定の実験的機能である以上、私たちは「速度の格差」を肌で感じることになります。(中略)0.1秒の差が、迷っている瞬間の「決定打」になることはあります。だからこそ、技術的な副作用を抑えた「prefetch」から始め、データが汚れず、かつ通信量も過剰に食わない「ちょうどいいライン」を、運営者には見極めてほしいのです。

反論3：計測データが歪む――偽のPVと誤ったCVR

アオイ（Web分析・計測の専門家）は、prerenderが引き起こす計測面の副作用を取り上げた。

不適切な先読みは、実訪問ではない「偽のPV」や「非アクティブな滞在時間」を生成し、分析の精度を著しく低下させます。(中略)prerenderによって計測タグが誤発火すれば、CV率（転換率）が不当に低く算出される可能性があります。

prerenderは非表示タブでページ全体をレンダリングするため、その裏でアクセス解析タグやログイン処理といった副作用のあるスクリプトまで動いてしまう恐れがある。実際にクリックされていないのにアクセスとしてカウントされたり、逆に途中で先読みが打ち切られてイベントが不完全に発火したりすれば、直帰率や滞在時間といった指標に、ユーザーの意図とは無関係なノイズが混じる。これは単なる「データの汚れ」ではなく、UI/UX改善の意思決定を誤らせかねない実害だとアオイは指摘した。

Chromeの折衷策：prerender until script

この副作用問題は、Chrome自身が対策を用意していることからも実在すると分かる。2026年1月（Chrome 144）から、「prerender until script」という新方式のOrigin Trial(本番環境の一部ユーザーに試験的機能を提供し検証する仕組み)が始まった。HTML取得とCSS・画像・フォントの読み込みは先読み時点で行うが、スクリプトの実行はブロッキングスクリプトに達した時点で一時停止し、実際にユーザーが遷移するまで再開しない。ログイン処理やアクセス解析タグなど、副作用のあるスクリプトの誤発火を避けながら、リソース読み込みの先読み効果だけを得ようとする折衷案だ。なお、通常のprerenderにも、事前レンダリング中かどうかをスクリプトから判定して副作用の実行を遅らせる仕組み（document.prerendering）は用意されており、「新方式を待つ」以外の既存の対策もある。

図はMDNとChrome for Developers公式ブログの記載を基にした編集部の整理であり、Firefox・Safariはこの流れに含まれていない。

テツオ（事実確認を担う編集者）は、この折衷策を評価しつつも、判断基準を明確にすべきだと述べた。

Speculation Rules APIは、ユーザーの行動を統計的に予測してリソースを投じる「賭け」です。予測が的中すれば130〜180msの高速化という果実を得られますが、予測が外れれば、通信コストやサーバー負荷のみが残ります。したがって、サイト運営者が検証すべきは、単なる速度向上ではなく「予測的中率とコストの相関」です。

読者への持ち帰り：安全に始めるための判断フロー

議論を通じて共有されたのは、「全リンクを対象にする」発想を捨て、遷移確率が高く副作用の少ない箇所に絞り込むという方向性だった。技術記者のナオは、フッターの汎用リンクのような遷移確率の低い箇所への先読みは「負の賭け」になりやすく、商品詳細ページへの主要導線のように遷移確率が高い箇所に絞るべきだと述べている。EC開発者のハルトはさらに、遷移確率だけでなくページの「リソースの重さ」も考慮し、軽量な静的ページから段階的に始めることを提案した。

図は編集部の議論を基にした整理であり、実装の正解を保証するものではない。

デモ：クリック前にページは動いているか

デモを開くでは、静的な3ページ（トップ・ページA・ページB）を用意した。トップページの2つのリンクには、eagerness: "moderate"という積極度を指定したprefetchルールを宣言しており、これは対応ブラウザではリンクへのホバー（約200〜300ms）またはpointerdown/touchstart(マウスダウン・タップ開始)の時点で、裏側でHTMLの先読みを始める設定に相当する。

各ページ（ページA・ページB）では、performance.getEntriesByType('navigation')から取得できるdeliveryTypeやactivationStartを読み、「このページは先読みされていたか」の参考情報を表示する。ただしdeliveryTypeはブラウザの実装によって対応状況・挙動差がある比較的新しい属性であり、デモ内でも「確実な仕様保証ではなく参考情報」と明記している。

トップページではHTMLScriptElement.supports('speculationrules')による機能検出を行い、対応ブラウザには緑色のバッジを、未対応ブラウザには「通常のリンク遷移として動作します」という表示を出す。speculation rulesのJSON自体は、対応していないブラウザでは単なるテキストとして無視されるため、未対応環境でもリンクや表示が壊れることはない。

また、ページ内には「先読みは無料ではない」という注意書きを設けている。カーソルを乗せただけでクリックしなかった場合でも、対応ブラウザは裏側でHTMLを取得しており、その転送は読まれなければそのまま無駄になる。ダークテーマ・日本語UIで、スマートフォンでもタップ操作で同様に確認できる。

出典を読むときのポイント

• MDN「Speculation Rules API」：仕様が「Limited availability・Experimental」に分類されていること、prefetch/prerenderの基本的な仕組みを確認した一次資料。
• Chrome for Developers公式ブログ「Speculation rules improvements」：eagerness・where・ドキュメントルールなど、Chrome/Edgeの段階的な機能追加の経緯を確認した。
• Chrome for Developers公式ブログ「Prerender until script origin trial」：2026年1月（Chrome 144）からの「prerender until script」Origin Trialの仕組みを確認した。
• chromestatus.com「prerender-until-script」機能ページ：同機能の実装状況・マイルストーンを確認した。
• Shopify公式ブログ「Speculation Rules at Shopify」：2025年6月の本番導入、保守的なprefetch設定、デスクトップ130ms・モバイル180msという実測値を確認した一次情報源。
• caniuse「Speculation-Rules HTTPヘッダ」：Chrome/Edge 121以降での対応、Firefox・Safariの対応状況を確認した。