Speculation Rules APIでWebサイトを高速化！新しい事前読み込みの仕組みと注意点

快適なユーザー体験を提供するうえでは、SEOやAIO、GEOの観点からもWebサイト全体の表示速度向上はとても重要な要素です。

サイトのパフォーマンスを高めるには、ページ移動時の表示遅延を抑える必要がありますが、この遅延を解決する仕組みとして登場したのがSpeculation Rules API（スペキュレーション・ルールズ API）です。

Speculation Rules APIとは、ユーザーが次に移動するページをブラウザが事前に予測して、バックグラウンドで読み込みと描画（プリレンダリング）まで完了しておく技術です。そのため、リンクをクリックした際に待ち時間なく次の画面が表示されるようになります。

これまでも <link rel="prefetch"> や <link rel="prerender"> といった事前読み込みの手法はありましたが、リソース管理の複雑さやJavaScriptの誤作動など、実運用で使うには扱いづらいところがありました。
Speculation Rules APIでは、JSON形式でルールを記述するだけで「どのページを」「どのタイミングで」処理するかを安全にコントロールできます。

ここでは、Speculation Rules APIの基本的な概念から、具体的な記述方法や導入時の注意点について詳しく解説していきます。

Speculation Rules APIの基本とできること

先ほどお話しした通り、Speculation Rules APIは閲覧中のページから次に遷移するページを予測して、バックグラウンドで読み込みから描画まで済ませておく技術です。

HTML内にJSON形式でルールを書くだけで、「どのページを」「いつ」「どこまで」事前処理させるかをシンプルに指定できます。

従来のページ遷移との仕組みの違い

従来のWebブラウジングでは、ユーザーがリンクをクリックした後に【サーバーへリクエストを送り、HTMLやCSS、JavaScriptを読み込んで描画する】という一連の処理が走るため、どうしても一定の待ち時間が発生していました。

Speculation Rules APIを利用した場合は、ユーザーがリンクにマウスを乗せた（ホバーした）瞬間や、画面内にリンクが入ってきた段階で、ブラウザがバックグラウンドでページの読み込みと描画処理をあらかじめ終わらせておきます。そのため、実際にクリックされた時点ではすでに準備が完了しており、一瞬で次の画面が表示されます。ユーザーからすると、読み込み待ちそのものがなくなったかのようなスムーズな操作感になります。

UXとCore Web Vitalsに与える影響

この仕組みは、ユーザーの利便性だけでなくアクセス解析や評価指標の面でも大きなメリットがあります。
画面切り替えの遅延がなくなることで、サイト内を快適に移動できるようになり、離脱の防止や回遊率・コンバージョン率の改善が期待できます。また、Googleの評価指標であるCore Web Vitals（表示速度や応答性の指標）の改善にも直結します。

PageSpeed Insightsなどで測定するラボデータ（自動テストのスコア）自体は変わりませんが、Googleが検索順位の評価で重視しているフィールドデータ（実際にアクセスしたユーザーの測定値）が大きく改善されます。アクセスした瞬間に描画が終わっているため、LCP（最大コンテンツ描画）やINP（応答性）といった数値が良い結果として計測されるようになります。

従来の prefetch / prerender との違い

事前読み込みの仕組み自体は以前からあり、prefetchやprerenderといった手法が使われていました。しかし、従来の仕様とSpeculation Rules APIとでは、次のように処理の仕組みやコントロール性能に大きな違いがあります。

※横にスクロールして確認できます

事前読み込み方法の比較：従来の方式とSpeculation Rules APIの違い
項目	prefetch (従来)	prerender (従来)	Speculation Rules API
読み込み範囲	リソース単体（HTMLや画像など）	ページ全体	ページ全体
JavaScriptの実行	実行しない	実行される（制御が難しい）	制限された安全な状態で実行・描画
指定方式	<link> タグ	<link> タグ	<script type=”speculationrules”> (JSON)
制御性	静的のみ	静的のみ	ホバー、スクロール、正規表現など動的制御

以前のprefetchはHTMLファイルや画像などのリソース単位でしか取得できず、prerenderはページ全体を読み込めるものの、JavaScriptが意図しないタイミングで実行されてアクセス解析の数値がおかしくなる問題がありました。

Speculation Rules APIでは、CSSやJavaScriptの実行を含めた表示状態を安全にメモリ上へ用意できるうえ、ユーザーの操作（リンクへのホバーやスクロール）に合わせてタイミングを細かく調整できます。これまでの課題をクリアしたかたちで、安全にページ遷移を高速化できるよう設計されています。

先読みが実行される4つのタイミング

事前にどのタイミングで読み込みを開始させるかは、通信量やサーバー負荷のバランスに応じて4つのレベルから選択できます。

コンテンツの性質やサイトのトラフィックに合わせて、適切なトリガーレベルを指定する形になります。

事前読み込みを発動させる4つのタイミング

基本となる発動レベルは、即時実行する「immediate」から、クリック直前まで待つ「conservative」までの4段階が用意されています。

immediate（即時）: ページが表示された直後に処理を開始します。ユーザーの操作を待たずに読み込むため、お問い合わせフォームの確認画面など、次に遷移するページがあらかじめ決まっている場合に適しています。
eager（積極的）: ユーザーがリンクに近づくようにカーソルを動かしたタイミングや、画面内にリンクが入ってきた段階で読み込みを開始します。遷移率の高いリンクに適していますが、通信量はやや増える傾向にあります。
moderate（中程度）: リンクにマウスを乗せた（ホバーした）瞬間や、タッチ操作を始めたタイミングで開始します。無駄な通信を抑えながらしっかり表示速度を早められるため、基本的にはこのmoderateを選んでおけば間違いありません。
conservative（保守的）: マウスボタンを押し込んだ瞬間（mousedown）に処理を開始します。クリックして指を離すまでのわずかな隙間時間を利用して読み込むため、サーバーへの負荷を最小限に抑えられます。

スマートフォン（タッチデバイス）での挙動

マウス操作がないスマートフォンでの閲覧時も、設定をスマホ用に変更する必要はありません。ブラウザ側が自動的にタッチデバイスであると判断し、画面タッチに合わせた最適な先読み処理を行ってくれます。

例えばmoderateに設定している場合、ユーザーが画面上のリンクに指を触れた瞬間（pointerdownやtouchstart）にバックグラウンド処理が走り、指を離してページ移動が確定するまでの数十ミリ秒を使って読み込みを完了させます。

また、画面のスクロールが止まったタイミングや、リンクを長押しした瞬間にも自動的に処理が実行されるため、モバイル環境でも違和感のないスムーズなページ遷移が可能です。

安全性とブラウザの自動制御

ここで気になるのは、「事前に読み込んでおいて本当に大丈夫なのか？」というところでしょう。

Speculation Rules APIにはブラウザレベルで厳格な安全機構が最初から組み込まれています。サイト運営者にとってもユーザーにとっても不利益が生じないよう、ブラウザが状況を自動で判断してコントロールしてくれます。

サイドエフェクト（副作用）のあるJavaScriptの実行停止

プリレンダリング中にバックグラウンドでJavaScriptが動いてしまい、まだ画面を開いていないのに音声が鳴ったり、位置情報の許可ポップアップが出たりすると困りますよね。

そのため、ユーザーの操作や確認を伴うJavaScript APIは、実際にページが表示されるまで実行が一時停止（ブロック）される仕様になっています。カメラやマイクへのアクセス、音声・動画の自動再生、通知リクエストなどは表示されるまで動かないため、予期せぬ誤作動を起こす心配はありません。

端末スペックや通信環境に応じた自動リクエスト制限

ユーザーの端末やネットワーク環境が厳しい状況にある場合、ブラウザは無理に事前読み込みを行いません。

例えば、スマートフォンのバッテリー残量が少なくなっている場合や、OS側でデータセーバー（通信節約モード）が有効になっている場合は、ルールが記述されていてもブラウザが自動的に処理をスキップまたは制限します。低スペックな環境下で余計な負荷や通信コストをかけないよう、配慮された挙動をとってくれます。

セキュリティとプライバシーの保護

別ドメイン（クロスドメイン）へのリンクをプリレンダリングするケースにおいても、セキュリティ面での配慮がなされています。

ユーザーの意図しない第三者サイトへのトラッキングやデータ送信を防ぐため、サードパーティCookieの取り扱いや認証情報の送信には厳格な制限がかかります。悪意のあるサイトがバックグラウンドで不要な通信を発生させないよう、安全性が担保された状態で処理が行われる点も安心できるポイントです。

このように、ブラウザ側でパフォーマンスと安全性のバランスがしっかり考慮されているため、サイト側は複雑な制御ロジックを自作することなく、安心して導入を進めることができます。

基本的な書き方と指定方法

導入方法はとてもシンプルで、HTMLの <head> 内に <script type="speculationrules"> という専用のタグを置いて、その中にJSON形式でルールを記述するだけです。

大きく分けて「URLを直接指定する方法」と「ページ内のリンクを自動で判別させる方法」の2パターンがあります。

基本コード（特定URLを直接指定する場合）

あらかじめ特定のページ（問い合わせ完了画面や固定の主要ページなど）へ事前読み込みを行いたい場合は、対象のURLを配列で直接リスト化します。

HTML

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/products", "/about"]
    }
  ]
}
</script>

コードの最も外側にある “prerender” は、処理の動作レベルを指定する記述です。ここではHTMLを取得するだけでなく、画面の描画まで終わらせるプリレンダリングを行う指示を出しています。

その中の “source”: “list” は、読み込み対象をURLのリスト指定で行うという宣言です。これとセットで “urls” の部分に [“/products”, “/about”] といった対象ページのパス（またはフルURL）を直接記述することで、指定したページだけをピンポイントで事前に読み込ませることができます。

サイト規模が小さく、あらかじめ遷移先のページが決まっている場合などは、このシンプルな書き方で十分機能します。

実用コード（ドキュメントルールで自動判定させる場合）

記事数の多いブログや大型ECサイトなどでリンクを1つずつ手書き指定するのは現実的ではありません。

そこで実務上よく使われるのが、ページ内にある <a> タグをブラウザに自動判別させる「ドキュメントルール」という記述方法です。お問い合わせフォームなどの除外したいページだけを指定しつつ、サイト全体を効率よく高速化できます。

HTML

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "and": [
          { "not": { "selector_matches": "a[href*='contact']" } },
          { "not": { "selector_matches": ".no-prerender, .no-prerender *" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

実用的な設定を行うためのポイントは以下の通りです。

“source”: “document”: ページ内に存在する同一ドメインのリンク（<a> タグ）をブラウザが自動で検出して処理対象にします。
“where” と “and” / “not”: プリレンダリングの対象とするリンクの条件を指定します。ここでは “not” を使うことで、「特定の条件に当てはまるリンクだけを事前に読み込み対象から外す」という除外設定を行っています。
“selector_matches”: CSSの属性セレクターを使って条件を指定します。例えば a[href*=’contact’] と書くことで、URL内に「contact」という文字列を含むリンク（問い合わせフォームなど）をまとめて除外できます。こうしておけば、相対パスか絶対パスかといった表記の違いを気にせず柔軟に制御できます。
.no-prerender による個別除外: HTML側で <a class="no-prerender"> のようにクラスを付与するだけで、特定のリンクだけピンポイントで先読みを停止できるようにしています。
“eagerness”: “moderate”: 発動タイミングの設定です。moderateを指定しておくことで、ホバー時やタップ開始時に処理が走るため、サーバーへの負荷を抑えながら体感速度を最大限高めることができます。

このように、基本形を押さえたうえで「除外ルール」と「eagerness」を組み合わせるのが、実際の運用において安全かつ効果的な書き方になります。

広告を掲載しているサイトでの注意点と対策

アフィリエイト広告やGoogle AdSenseを掲載しているブログやメディアサイトに導入する場合、広告の誤カウントやインプレッションの低下を防ぐための対策を行っておくと安心です。

適切な設定をしておけば、収益機会を損なうことなく安全にページ遷移を高速化できます。

アフィリエイト広告への影響と対策

アフィリエイトリンクへの影響については、通常の運用範囲であれば過度に心配する必要はありません。

“source”: “document” を指定したドキュメントルールは、デフォルトで同一ドメイン（自サイト）のリンクのみを対象とするため、別ドメインであるアフィリエイトASPのリンク（px.a8.net など）が勝手に事前読み込みされることは原則ありません。

ただし、次のようなケースでは意図しない事前アクセスが発生する可能性があるため、個別に除外設定を行っておくのが安全です。

リダイレクト用の内部URLを使っている場合
プラグインなどを利用して /go/xxx や /out/xxx といった自サイトのURLを経由させて外部広告へ転送している場合、同一ドメインと判定されてプリレンダリングの対象になってしまいます。
この場合は、JSONの除外ルール（where）に { “not”: { “selector_matches”: “a[href*=’/go/’]” } } といった記述を追加して除外します。

クリック計測を行っているリンクがある場合
サイドバーのバナーやランキングボタンなど、クリック数をカウントするプログラムを挟んでいるリンクは、ホバー時の事前読み込みによってカウントが走ってしまうリスクがあります。そうしたリンクには、HTML側で <a class="no-prerender"> のようにクラスを付与し、個別に除外しておくのが確実です。

例えば、HTML側で以下のようにclassを付与しておけば、先ほど指定したドキュメントルールによってこのリンクだけが自動的にプリレンダリングの対象から外れます。

HTML（HTML側で個別除外を指定する例）

<a href="/go/item" class="no-prerender">
  <img src="banner.png" alt="おすすめ商品">
</a>

JSON側の条件指定とHTML側のclass付与を組み合わせておけば、複雑な構成のサイトでも安全に運用できます。

Google AdSense（インプレッション計測）への影響と対策

Google AdSenseなどのインプレッション報酬型広告を掲載している場合、「裏でページが事前読み込みされた際に、広告の表示回数としてカウントされてしまうのではないか」と懸念される方もいるでしょう。

これについても、先ほど紹介した “eagerness”: “moderate” を設定していれば心配いりません。

プリレンダリング実行中、ブラウザは画面を非表示（hidden）として扱います。AdSenseなどの主要な広告タグは、実際にユーザーがリンクをクリックして画面が表示されてから処理を行うため、裏読み込みによって不正なカウントが発生したり、規約違反になったりするリスクはありません。

注意が必要なのは、最も強い設定である “eagerness”: “immediate”（即時読み込み）を使用する場合です。ページが開いた瞬間にリンク先を無差別に裏読み込みしてしまうため、クリックされなかったページの広告リクエストや計測処理が無駄に走り、広告の表示率（Active View）や単価評価に悪影響を与える可能性があります。

広告を掲載しているサイトでは、無駄なリクエストを発生させないためにも、クリックの可能性が高いタイミングで発動する “moderate” を選択しておくのが確実です。

WordPressへの組み込み方

WordPressで運用しているサイトに導入する場合は、HTMLへタグを配置するだけでなく、管理画面やログイン中の動作、WordPress本体の機能とのバッティングに配慮する必要があります。

トラブルを防ぎながら安全に動かすための実装手順を解説します。

header.php（または wp_head）への組み込み

まずは基本となるルールの記述です。テーマのheader.phpやwp_headフックを使ってルールを出力させますが、ここではPHPの条件分岐とJSONの除外ルールを組み合わせて指定するのが安全です。

PHP（header.php）

<?php 
// お問い合わせ・プライバシーポリシー・管理画面を開いている時はルール自体を出力しない
if ( ! is_page( array( 'contact', 'privacy' ) ) && ! is_admin() ) : 
?>
<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "and": [
          { "not": { "selector_matches": "a[href*='contact']" } },
          { "not": { "selector_matches": "a[href*='privacy']" } },
          { "not": { "selector_matches": "a[href*='wp-admin']" } },
          { "not": { "selector_matches": "a[href*='wp-login']" } },
          { "not": { "selector_matches": ".no-prerender, .no-prerender *" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>
<?php endif; ?>

上記のコードでは、二重の安全策をとっています。

1つ目は、PHP側の if ( ! is_page(…) ) による制御です。
お問い合わせやプライバシーポリシーのページを開いている最中は、スクリプトタグそのものをHTMLに出力させないようにしています。開いているページ内で不要な事前読み込み処理が発生するのを防ぐためです。

2つ目は、JSON内の selector_matches による指定です。
トップページや記事ページを見ているときに、ヘッダーやフッターなどにあるお問い合わせやプライバシーポリシーへのリンクが裏で読み込まれないようブロックしています。

また、wp-adminやwp-loginを除外条件に入れているのも重要です。
ログイン中に画面上部へ表示されるツールバー内のリンクが誤って事前読み込みされるのを防ぎ、管理セッションのトラブルや不要な負荷を防止できます。

WordPress標準機能との重複を防ぐ設定（functions.php）

WordPress6.8以降（あるいは関連するプラグインが有効化されている場合）では、コア機能としてSpeculation Rules（デフォルトはprefetch）が自動で出力される仕組みが導入されています。

そのまま上記コードを追加すると、WordPress標準のprefetchと独自に追加したprerenderのルールが二重で出力されてしまい、処理が競合して狙い通りの効果が出ないことがあります。

テーマやプラグインの仕様の影響をうけず、この標準タグだけを確実に消去するには、functions.phpに以下の記述を追加してHTMLの最終出力バッファから直接取り除きます。

PHP（functions.php）

/**
 * HTML出力バッファからWordPress標準のspeculationrulesを除去する
 */
add_action( 'template_redirect', function() {
    ob_start( function( $buffer ) {
        // WordPress標準のprefetch用scriptタグを検索して削除
        $pattern = '/<script type="speculationrules">\s*\{\s*"prefetch":.*?<\/script>/s';
        return preg_replace( $pattern, '', $buffer );
    });
}, 0 );

このコードでは、ページ全体のHTMLが生成される最速のタイミング（template_redirectの優先度0）で出力バッファリング（ob_start）を開始しています。

生成されたHTMLの中から、WordPress本体が出力する “prefetch” を含んだ<script>タグだけを正規表現でピンポイントで特定して切り取っています。

フックの書き換え漏れなどのリスクを完全に排除できるため、header.phpに記述した自作のprerenderルールのみを意図通りに機能させることができます。