【WordPress高速化⑧】次のページを先読みして体感速度を上げる｜リンクプリフェッチ

次に見られそうなページを先読みし、クリック後の表示を体感ゼロ秒に近づける手法を解説します。

リンクプリフェッチとは何か：WordPress高速化の隠れた切り札

WordPressサイトのページ表示速度を改善しようとするとき、画像の最適化やキャッシュ設定に注目しがちです。しかし「次にクリックするページ」を事前に読み込むリンクプリフェッチは、訪問者が体感する回遊速度を劇的に改善できる技術です。一方で、使い方を誤るとトップページのload時間が跳ね上がるという副作用もあります。本記事では、リンクプリフェッチの仕組みから、WordPress上での実装方法（Flying Pages等のプラグイン）、実測に基づく功罪、そして副作用への対処法まで、網羅的に解説します。

リンクプリフェッチの仕組みと種類

リンクプリフェッチとは、ユーザーが実際にリンクをクリックする前に、ブラウザがリンク先のリソースを先読みしておく技術です。ユーザーがリンクをクリックした瞬間には既にリソースが手元にあるため、遷移が瞬時に感じられます。

ブラウザ・HTML仕様には、先読みに関するいくつかの異なるメカニズムが存在します。それぞれ動作タイミングと対象が異なるため、混同しないよう整理しておく必要があります。

種類	HTMLの書き方	先読みの対象	タイミング
DNS プリフェッチ	<link rel="dns-prefetch" href="...">	外部ドメインのDNS解決	ページ読み込み中
プリコネクト	<link rel="preconnect" href="...">	TCP/TLSハンドシェイクまで	ページ読み込み中
プリフェッチ（リソース）	<link rel="prefetch" href="...">	次ページのHTML/CSS/JSなど	現ページがアイドル状態になってから
プリレンダー	<link rel="prerender" href="...">	次ページの完全レンダリング	バックグラウンドで全処理
リンクプリフェッチ（ホバー検知）	JavaScriptで動的に付与	ホバー/タッチ開始で次ページをfetch	ユーザー操作の予兆を検知してから

WordPressのプラグインが「リンクプリフェッチ」と呼ぶとき、多くの場合は最下段の「JavaScriptでホバーや画面内への進入を検知し、動的にfetchまたはプリレンダーを起動する」タイプを指します。Flying PagesやInstant.pageが代表例です。

なぜ体感速度が上がるのか

ユーザーがリンクにマウスを乗せてから実際にクリックするまでの平均時間は、デスクトップでは約200〜300ミリ秒と言われています。この短い窓の間に次ページのHTMLをバックグラウンドで取得しておくことで、クリック後の待ち時間がほぼゼロになります。モバイルでは「touchstart（指が触れた瞬間）」を検知することで同様の効果を得られます。

WordPress向けリンクプリフェッチ実装の選択肢

WordPressでリンクプリフェッチを導入する主な方法は、専用プラグインの利用と、テーマやfunctions.phpへの手動実装の2系統です。

主要プラグインの比較

プラグイン名	検知トリガー	delay設定	除外設定	特徴
Flying Pages	ホバー／画面内リンク	0ms〜（設定可）	URL・クエリ文字列単位	軽量・WordPress公式リポジトリ収録
Instant Page（WP版）	ホバー（65ms delay）	65ms固定（標準）	data-no-instant属性	シンプル。instant.pageのWP移植版
Speculative Rules API	ブラウザネイティブ	なし（ブラウザ制御）	JSON設定で除外パス指定	Chrome 109以降で使用可。JSが不要
手動実装（Intersection Observer）	ビューポート内進入	自由に設定	コード次第	プラグイン依存なし・最大の自由度

Flying Pagesの設定詳細

Flying Pagesは設定画面から以下の項目を調整できます。

• Delay（ms）：ホバーしてからプリフェッチを開始するまでの待機時間。0にすると即時取得を開始します。
• Max requests（同時最大リクエスト数）：デフォルト5。サーバー負荷に応じて調整。
• Ignore keywords：特定のURLパターン（例：/wp-admin、/cart、logout）をプリフェッチ対象から外せます。
• Enable for mobile：モバイルはタッチ検知で動作。モバイル通信量に注意。

実測データで見るリンクプリフェッチの功罪

理論上は「速くなる一方」に見えるリンクプリフェッチですが、実際に運用してみると思わぬ副作用が生じることがあります。当サイト（crystal-method.com）での実測を例に、メリットとデメリットを具体的に解説します。

実測で判明した問題：トップページのload時間が跳ねる

Flying Pagesをdelay: 0ms（即時プリフェッチ）に設定してサイト全体に適用したところ、トップページのloadイベント完了時間が時々2,276msまで跳ね上がる現象を確認しました。通常時は1,200ms前後で安定していたため、明らかな異常値です。

原因は次のメカニズムにあります。トップページはリンク数が多く、訪問者がマウスを動かすだけで複数のサブページへのfetchが一斉に起動します。delay: 0の場合、ページ自体の読み込みが完了するwindow loadイベントのタイミングと、プリフェッチのfetchリクエスト群が競合し、loadウィンドウに食い込む形で余分な通信が発生します。

wp_dequeue_scriptによるトップページだけの無効化

この問題への対処として有効なのが、WordPressのwp_dequeue_scriptフックを使い、トップページだけプラグインのスクリプトを読み込まないようにする方法です。

functions.phpに以下のようなコードを追加します。

add_action( 'wp_enqueue_scripts', function() {
    if ( is_front_page() ) {
        // Flying Pages のスクリプトハンドル名を dequeue する
        wp_dequeue_script( 'flying-pages' );
    }
}, 20 );

ポイントは優先度を20（デフォルトの10より後）にすることです。プラグインが優先度10でenqueueした後に実行されるため、確実にdequeueできます。ハンドル名はプラグインによって異なります。Flying Pagesの場合はflying-pagesですが、ブラウザの開発者ツール→ネットワークタブでスクリプトのsrcを確認し、WordPressのスクリプトIDを特定してください。

この功罪をどう捉えるか

リンクプリフェッチはサイト全体の回遊体験を高める技術です。一方で、リンクが集中するハブページ（トップページ・カテゴリーページ等）では、プリフェッチが引き起こすリクエスト増加がそのページ自体の計測指標を悪化させます。

• 改善される指標：内部ページへの遷移後のFCP・LCP・体感速度
• 悪化リスクのある指標：プリフェッチ起動ページ自体のloadイベント時間・TBT（過度な場合）

Google のCore Web Vitalsとの関係では、LCP・INP・CLSがランキング要因です。loadイベント時間そのものはランキング直接要因ではありませんが、プリフェッチによるリクエスト増加がメインスレッドを圧迫すればINPに影響する場合があります。delay: 0の設定はリスクが高いため、最低でも50〜100msのdelayを設けるか、loadイベント完了後にのみ起動するよう制御するのが現実的です。

リンクプリフェッチ導入時の設計指針

実測から得られた知見をもとに、WordPress環境でリンクプリフェッチを安全に運用するための設計指針をまとめます。

ステップ1：除外ページを明確にする

プリフェッチを全ページに適用する前に、次の種類のページは除外対象候補として検討してください。

• トップページ・ランディングページ（リンク数が多くリクエスト爆発リスクあり）
• カートページ・決済ページ（セッション・在庫チェックを誤ってプリフェッチするリスク）
• ログアウトURL・nonce付きURL（意図しないアクションが実行される危険性）
• 管理画面（/wp-admin/）

ステップ2：delayを適切に設定する

delay: 0は「最速のプリフェッチ」を実現しますが、ページロード完了前にリクエストが走るリスクがあります。推奨される設定例は次のとおりです。

サイト特性	推奨delay	理由
リンク数の少ない記事特化サイト	0〜50ms	リクエスト競合が少ない
リンク数の多いポータル・ECサイト	100〜200ms	load完了後に起動しやすくなる
サーバーの同時接続数が限られる共有ホスト	200ms以上＋Max requests: 2〜3	サーバー側の過負荷を防ぐ

ステップ3：モバイルの扱いを慎重に決める

モバイル回線ではプリフェッチによる通信量増加がユーザーのデータ容量を消費します。navigator.connection.saveDataがtrueの場合や、接続タイプがslow-2g/2gの場合はプリフェッチを自動的に無効化するのがベストプラクティスです。Flying Pagesはこの制御を内部で行っていますが、手動実装の場合は明示的に組み込む必要があります。

ステップ4：Speculative Rules APIの活用を検討する

Chrome 109以降ではSpeculative Rules APIが利用可能です。JSONで先読みルールを記述するだけで、JavaScriptのイベント監視なしにブラウザが賢くプリフェッチ・プリレンダーを行います。

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "href_matches": "/*",
        "not": { "href_matches": ["/wp-admin/*", "/cart/*", "/?*"] }
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

eagernessにはimmediate/eager/moderate/conservativeの4段階があります。moderateはホバー時に起動し、conservativeはクリック直前の検知で起動するため、負荷と速度のバランスが取りやすいです。WordPressへの追加はwp_headアクションでecho出力するか、プラグインを経由します。

パフォーマンス計測：効果を正確に確認する方法

リンクプリフェッチの効果と副作用は、適切な計測なしに判断できません。以下のツールと方法で確認してください。

Chrome DevToolsでのloadイベント確認

Networkパネルを開いた状態でページをリロードすると、タイムラインの下部に青い縦線（DOMContentLoaded）と赤い縦線（load）が表示されます。プリフェッチが有効な場合、loadラインの右側にもfetchリクエストが続くことが確認できます。Performanceパネルでは、loadイベント後のネットワークアクティビティをタイムライン上で視覚的に把握できます。

WebPageTest・PageSpeed Insightsによる比較

プリフェッチ有効/無効を切り替えた状態で同じページを複数回テストし、loadイベント時間・FCP・LCP・TBTを比較します。WebPageTestでは「Apply」ボタンで比較ビューが使えます。単一測定では誤差が大きいため、最低3回の平均値で判断してください。

Real User Monitoring（RUM）の活用

ラボテスト（ツールによる計測）だけでなく、実際のユーザーデータ（フィールドデータ）での確認も重要です。Google Search ConsoleのCore Web Vitals、またはCloudflare Web Analytics・Vercel Analytics等のRUMツールを使い、実ユーザーのLCPとINPがプリフェッチ導入前後でどう変化したかを確認します。

サーバー・WordPress設定との組み合わせ

リンクプリフェッチはフロントエンド技術ですが、サーバー側の設定と組み合わせることで最大の効果が得られます。

ページキャッシュとの相性

プリフェッチで取得されるのはHTMLレスポンスです。W3 Total Cache・WP Rocket・LiteSpeed Cache等のページキャッシュが有効であれば、プリフェッチリクエストはPHPを経由せずキャッシュから即座に返却されます。これはサーバー負荷を大幅に低減します。ページキャッシュが無効な状態でdelay: 0を使うと、PHP処理が大量に同時起動するリスクがあるため、プリフェッチ導入前にキャッシュの整備を先行させるべきです。

HTTP/2・HTTP/3の活用

プリフェッチはHTTP/2以降の多重化と相性が良く、1つのTCP接続で複数のfetchを並列処理できます。サーバーがHTTP/1.1のみの場合、同時接続数の制限（ブラウザで通常ドメインあたり6接続）がボトルネックになります。ホスティングがHTTP/2に対応しているか確認してください。

CDNとの組み合わせ

CloudflareやBunny.net等のCDNを使用している場合、プリフェッチされたHTMLがCDNエッジからレスポンスされればRTT（往復遅延）を最小化できます。CDN側のキャッシュルールで記事ページのキャッシュが有効になっているかを確認してください。

よくある問題とトラブルシューティング

プリフェッチが動作していない

ChromeのNetworkパネルでフィルタを「Fetch/XHR」に設定し、ホバー時に対象URLへのリクエストが発生するかを確認します。発生しない場合は①プラグインが正しく有効化されているか、②スクリプトがdequeueされていないか、③対象URLが除外リストに入っていないかを順に確認してください。

管理画面やWooCommerceカートに誤ってアクセスが飛ぶ

Flying PagesのIgnore keywordsにwp-admin、cart、checkout、logout、add-to-cart等を追加してください。nonce付きURLは通常クエリパラメータを含むため、?（クエリ文字列を含むURL全般）を除外するのも有効です。

モバイルでバッテリー・通信量の消費が増えた

Flying Pagesの設定でモバイルプリフェッチを無効化するか、Speculative Rules APIのeagerness: conservativeに切り替えてください。プリフェッチするリンクの対象を同一ドメイン内のみに絞ることも有効です。

実測エビデンス：自社サイトのUbersuggest計測（改善前→改善後）

プリフェッチの最適化を含む一連の表示速度改善により、第三者ツールUbersuggestの「読み込み時間」も実際に改善しました（2026年6月時点・自社サイト crystal-method.com／モバイルは過去28日間の実ユーザー体験ベース）。

まとめ

リンクプリフェッチは、訪問者がリンクをクリックするより前に次ページを先読みすることで、回遊体験を劇的に向上させるWordPress高速化の有力な手法です。Flying PagesはWordPressに手軽に導入できる定番プラグインですが、delay: 0での全ページ適用はトップページのloadイベントを悪化させることを実測で確認しました。

crystal-method.comでの実例では、トップページのload時間が最大2,276msまで跳ねていたところ、wp_dequeue_scriptでトップページのみプリフェッチを無効化することで1,628ms（最速954ms）まで改善しました。内部ページへのプリフェッチは温存しているため、回遊体験の向上は維持されています。

設計の要点を整理すると、①カート・ログアウト等の副作用があるURLは必ず除外する、②delayはサーバー・ページ構造に合わせて50〜200msに調整する、③リンク数の多いハブページはdequeueで個別制御する、④Chrome向けにはSpeculative Rules APIが今後の標準となる、の4点です。プリフェッチを正しく制御することで、ページ単体の計測指標を損なわずに訪問者の回遊体験を高められます。

関連記事

• wordpress 表示速度 改善とは（総合ガイド）
• core web vitals lcp 改善
• wordpress 画像 webp 遅延読み込み
• 未使用css 削除 表示速度
• wordpress gtm 遅延 読み込み