WordPress Speculative Loadingの使い方と最適化【6.8対応】

WordPress 6.8では、ページ遷移を高速化するSpeculative Loading（投機的読み込み）がコアに搭載されました。設定不要で使い始められる反面、仕組みや注意点を知らないまま使うと、「どこまで効くのか」「GA4に影響しないのか」が分かりにくい機能でもあります。

• Speculative Loadingの仕組みと、Core Web Vitalsで主にどこに効きやすいかが分かります。
• WordPress 6.8の標準設定、prefetchとprerenderの違い、eagernessの考え方が分かります。
• GA4への影響、除外すべきURL、実際のカスタマイズ方法まで確認できます。

本記事では、WordPress Speculative Loadingの仕組み、標準設定、注意点、カスタマイズ方法をわかりやすく解説します。

Speculative Loading（投機的読み込み）とは何か

Speculative Loadingは、ユーザーがクリックする前から、次に開きそうなURLの読み込みを始める仕組みです。WordPress 6.8では、この機能がWordPressコア機能として導入されたことが案内されています。

内部的には、ブラウザのSpeculation Rules APIを利用します。これは、どのリンクを事前に読み込むか、どの程度早いタイミングで準備するかをルールとして定義できる仕組みです。

Core Web Vitalsでは主にLCP改善に効きやすい

結論から言うと、Speculative Loadingは「別ページへ移動したあと」の表示を速くしやすく、特にLCP改善に寄与しやすい施策です。web.devでも、LCP改善の文脈でinstant navigationsの重要性が説明されています。

一方で、INPについては「この機能だけで大きく改善する」とまでは言えません。INPはJavaScriptの重さやメインスレッドの詰まりなど、別の要因にも強く左右されるためです。詳しい考え方はINPの公式解説が参考になります。

WordPressサイトと相性がよい理由

WordPressは、記事一覧から記事詳細へ、関連記事から次の記事へ、といった複数ページ間の移動が多い構成になりやすいです。そのため、次のページを先回りして準備するSpeculative Loadingと相性がよいと言えます。

WordPress 6.8ではSpeculative Loadingは標準で有効

結論から言うと、非ログイン状態でpretty permalinkが有効なサイトでは、Speculative Loadingは原則デフォルトで有効です。

WordPress 6.8では、別プラグインを入れなくても条件を満たせばフロントエンドで動作します。ただし、ログイン中のユーザーやpretty permalinkが無効な環境では、標準では無効になります。

コア実装のデフォルトは prefetch + conservative

WordPressのコア実装では、既定で prefetch と conservative が使われます。つまり、まずは「安全寄り」に動く設計です。

無効になる条件はログイン中とpretty permalink無効時

管理画面でログインしたまま速度を見て「効いていない」と感じる場合は、この条件に当てはまっている可能性があります。クエリパラメータの扱いが増えるpretty permalink無効環境も、標準では慎重側に倒されています。

prefetchとprerenderの違いと選び方

結論から言うと、安全性を優先するならprefetch、速度効果を強めたいならprerenderです。まずは prefetch + conservative から確認する進め方が無難でしょう。

ここが最も迷いやすいポイントです。簡単に言うと、prefetch は先にデータを取りに行く方法、prerender はさらに進んで、次のページをほぼ開ける状態まで先に準備する方法です。

prefetchは安全寄り、prerenderは効果寄り

prefetch は比較的安全で、まず試しやすい選択肢です。一方の prerender は、遷移後の体感速度をより高めやすい反面、計測や一部機能との相性に注意が必要です。Chrome公式の実装ガイドでも、サイトの複雑さに応じた慎重な判断が推奨されています。詳しくはChrome Developersの解説をご確認ください。

eagernessは conservative・moderate・eager をどう使い分けるか

eagerness は、どのくらい早い段階で先読みを始めるかを表します。一般的には、conservative は安全寄り、moderate はバランス型、eager はより積極的です。WordPressコアが conservative を既定にしているのは、まず広いサイトで無理なく動くことを重視しているためです。

まずどの設定から試すべきか

多くのWordPressサイトでは、いきなり prerender に変えるよりも、まず標準設定のまま体感と指標を確認し、その後で moderate を検討する流れが現実的です。特に広告タグや独自計測が多いサイトでは、段階的に進めるほうが失敗しにくくなります。

Speculative Loadingの注意点と影響

注意点を先に言うと、analyticsや状態変更URL、対応ブラウザの範囲は事前に把握しておいたほうが安全です。

Google Analyticsや広告タグへの影響

analyticsの影響は気になるポイントですが、Chrome系の公式解説では、Google Analyticsはactivationまで処理を遅延して扱うと案内されています。詳しくはweb.devのSpeculative Prerendering解説をご覧ください。

そのため、Google Analytics系では大きな問題が出にくいケースが多いと考えられます。ただし、自作イベント計測や独自スクリプトを入れている場合は別です。ページが実際に表示される前に実行されると困る処理は、個別の確認が必要です。

除外すべきURLの考え方

除外パスの考え方では、WordPressの関数リファレンスが参考になります。WordPressは /wp-*.php や /wp-admin/* を自動で除外し、pretty permalinkが有効なときはクエリパラメータ付きURLも自動除外します。さらに、rel=”nofollow” のリンクや no-prefetch / no-prerender クラスで除外されたリンクも対象外です。

特に注意したいのは、GETリクエストで状態が変わるURLです。たとえば、ログアウト、カート追加、お気に入り登録、会員系操作、検索パラメータ付きURLなどは、先読み対象から外したほうが安全な場合があります。

ブラウザ対応状況と“効くユーザー層”

Speculation Rules APIは、現時点では主にChromium系ブラウザで恩恵を受けやすい機能です。MDNでもExperimental / Limited availabilityとして案内されています。

また、日本のブラウザ市場では、2026年2月時点で Chrome が 55.68%、Edge が 12.86% でした。少なくともこの範囲のユーザーには効果が期待しやすい一方、SafariやFirefoxでは恩恵が限定的な場合があります。数値はStatCounterの日本市場データで確認できます。

WordPressでの設定変更・カスタマイズ方法

カスタマイズはフィルタで可能です。まずは設定全体の変更と除外パスの追加、その2点を押さえると実務では十分対応しやすくなります。

動作確認では、ChromeのApplicationパネルからSpeculation Rulesを確認できます。確認手順はChrome DevToolsの公式ガイドが参考になります。

mode と eagerness を変えるフィルタ例

設定全体の変更には wp_speculation_rules_configuration フィルタを使います。フック名や引数の仕様はWordPress公式の関数リファレンスで確認できます。

add_filter( 'wp_speculation_rules_configuration', function( $config ) {
    $config['mode'] = 'prefetch';
    $config['eagerness'] = 'moderate';
    return $config;
} );

まずは mode をそのまま prefetch にしつつ、eagerness だけを moderate に上げる形が試しやすいでしょう。より積極的な prerender を使う場合は、analyticsや状態変更URLへの影響を先に確認してください。

除外パスを設定するフィルタ例

先読み対象から外したいURLには、wp_speculation_rules_href_exclude_paths フィルタを使えます。

add_filter( 'wp_speculation_rules_href_exclude_paths', function( $paths ) {
    $paths[] = '/cart/*';
    $paths[] = '/my-account/*';
    $paths[] = '/search/*';
    return $paths;
} );

この設定は、会員系やEC系のように、すべての内部リンクをそのまま先読み対象にしにくいサイトで有効です。

特定URLだけ強めに最適化する方法

一部の導線だけを強く最適化したい場合は、wp_load_speculation_rules を使った個別ルール追加も検討できます。

たとえば、記事一覧から記事詳細への遷移だけを強化し、検索や会員ページは除外する、といった考え方です。全ページ一律で強くするより、読者の主要導線に絞って調整するほうが安全なこともあります。

既存の高速化施策とどう組み合わせるか

Speculative Loadingは、主に「次のページへ移動するとき」の体感改善を狙う機能です。そのため、初回表示の軽量化を担う施策とは役割が異なります。

Speculative Loadingは“ページ遷移”最適化

初回アクセス時のCSSやJavaScriptを減らす施策とは別に、2ページ目以降を速く見せるのがSpeculative Loadingの強みです。つまり、初回表示の改善と、ページ遷移の改善は分けて考えると整理しやすくなります。

AutoptimizeやFlying Scriptsとの役割分担

すでに高速化施策を入れている場合でも、役割が重なりにくいケースは多いです。たとえば、CSSやJavaScriptの整理はAutoptimizeの設定方法、JavaScript遅延の考え方はFlying Scriptsの使い方、併用全体の整理はAutoptimizeとFlying Scriptsの併用方法が参考になります。

効果検証の見方

Speculative Loadingの効果は、対応ブラウザの比率や、内部リンクをどれだけ読者がたどるかによって見え方が変わります。PageSpeed Insightsだけで判断するのではなく、実際の回遊導線や実ユーザーの挙動も踏まえて評価するのが現実的です。

よくある質問（FAQ）