「PageSpeed Insightsの点数は見ているけど、売上や問い合わせには直結していない気がする」

この感覚は半分正しく、半分危険です。Core Web Vitals（以下CWV）は“点数ゲーム”ではありませんが、実ユーザー体験の悪化は、離脱率・CVR・検索流入に連鎖します。実際にweb.devの公開事例では、LCP/CLS改善でバウンス率43%改善（The Economic Times）、LCP改善で売上8%増（Vodafone Italy）といった成果が報告されています。

さらに2024年3月12日、GoogleはFIDをINPへ正式置換しました。つまり今は、「初回クリックの遅さ」だけでなく「サイト滞在中の操作全体のもたつき」まで評価対象です。WordPressサイト運用では、画像・JS・テーマ・プラグイン・外部タグの設計が、そのままCWVに跳ね返ります。

本記事では、2026年4月時点の公開情報に基づき、SEO担当者/Web担当者が「今日から実装できる順番」で整理します。

先に全体像：LCP / INP / CLS 早見表（最重要）

指標 Good Needs Improvement Poor まず効く改善策
LCP（最大コンテンツ表示） 2.5秒以下 2.5〜4.0秒 4.0秒超 LCP画像最適化、fetchpriority="high"、preload、TTFB短縮、キャッシュ/CDN
INP（操作応答性） 200ms以下 200〜500ms 500ms超 JS削減、長時間タスク分割、不要プラグイン削除、サードパーティ制御
CLS（視覚安定性） 0.1以下 0.1〜0.25 0.25超 width/height 指定、広告枠確保、フォント最適化、動的挿入設計

この閾値は、Google/web.devが示す現行基準です。評価は原則として75パーセンタイルの実測データ（フィールドデータ）で判断されます。

Googleの最新動向：INP置換とランキングの現実

1) FIDはすでに終了、INP時代に移行済み

INPは2024年3月12日にCore Web Vitalsへ正式昇格し、FIDを置き換えました。現在のCWVは LCP / INP / CLS の3指標です。

INPはページ滞在中のほぼ全操作を対象にするため、単発の初回入力だけを測るFIDより実態に近い指標です。WordPressでは「初期表示は速いのに、メニュー操作・検索・フォーム入力が重い」サイトがこの変更で悪化しやすくなりました。

2) ランキングシグナルとしての扱い

Google Search Centralは「Core Web Vitalsはランキングシステムで使われる」と明記しています。一方で、同時に「それだけで上位表示は保証されない」とも明示しています。

要するに、Googleは「多くのクエリで役立つコンテンツが多数ある中では、ページエクスペリエンスが評価要因の一つになり得る」と示しており、CWV改善は競合との差別化要因として機能し得る、という位置づけです。コンテンツ品質と技術品質を分けずに改善するのが実務上の最適解です。

LCP対策：まず「ヒーロー画像」と「初動レスポンス」を直す

LCPの多くは、ファーストビューの大きな画像か見出しブロックです。WordPressでは特にアイキャッチ画像、スライダー1枚目、ヒーロー背景画像が該当しやすくなります。

すぐ効く実装順

  1. LCP候補画像を特定（PSI/LighthouseのLCP要素）
  2. LCP画像を絶対にlazy-loadしない（loading="lazy"を外す）
  3. fetchpriority="high" を付与
  4. 必要なら <link rel="preload" as="image"> を追加
  5. 画像はWebP/AVIF化、過剰解像度を削減
  6. TTFB改善（ページキャッシュ、オブジェクトキャッシュ、CDN）

web.devは「LCP画像のlazy-loadは避けるべき」と明確に案内しています。WordPress 6.3以降は、コア側でもWordPressがLCPの有力候補と判定した画像に fetchpriority="high" を付与する最適化が導入されています（すべての画像に一律付与されるわけではありません）。

WordPressで詰まりやすいポイント

  • スライダープラグインが1枚目以外まで先読みして帯域を圧迫
  • ヒーロー画像をCSS背景で出していて発見が遅れる
  • キャッシュはあるが、未ログイン時だけで会員/EC導線が遅い
  • 画像圧縮はしているが、配信サイズ（表示サイズ）設計が甘い

INP対策：JavaScriptの“重さ”より“詰まり方”を見る

INP悪化の典型は、長時間タスク（Long Task）でメインスレッドが詰まり、クリック後の反応が遅れる状態です。広告タグ、ヒートマップ、チャット、巨大テーマJS、多機能プラグインで起きます。

実務で効く改善手順

  1. まず「遅い操作」を特定（DevTools Performance、INPデバッグ）
  2. 不要プラグイン停止、重複機能統合
  3. 不要JSをページ単位で読み込まない
  4. 長時間タスクを分割（50ms超を細かく分ける）
  5. defer / async 戦略を適用
  6. サードパーティタグの発火条件を見直し

WordPress 6.3以降は wp_enqueue_script() で strategy => 'defer' / 'async' を扱いやすくなっています。テーマや独自プラグイン側で正しく適用すると、INP改善に直結します。

INPで見落としがちな原因

  • 管理画面では速いのに、公開側でタグマネージャー配下のJSが肥大
  • 1つ1つは軽いプラグインが積み上がって長時間タスク化
  • フォーム送信前バリデーションが同期的で固まる
  • チャットウィジェットが全ページ初期ロードで展開される

CLS対策：レイアウトシフトは“予約席”で防ぐ

CLSは「読み込み中に要素がずれる」問題です。問い合わせボタンやCTAがズレると、誤タップ・離脱・機会損失に直結します。

優先して実装する項目

  1. すべての画像・動画に width/height か aspect-ratio を指定
  2. 広告・埋め込みの表示枠を事前確保
  3. 上部に動的バナーを後出ししない
  4. Webフォントは font-display と preload を適切化
  5. ファーストビュー内のDOM後挿入を最小化

web.devのCLS最適化ガイドでも、最優先は画像サイズ指定と動的要素のプレースホルダー確保です。WordPressでは「ブロックエディタ上で見た目が整っているのに、本番で広告や外部埋め込みでズレる」ケースが多いので、実URLでの確認が必須です。

計測・モニタリング：4つを役割分担で使う

ツール 何を見るか 使うタイミング
PageSpeed Insights フィールドデータ（CrUX）+ ラボデータ（Lighthouse） 改修前後の比較、URL単位の初期診断
Search Console「Core Web Vitals」 サイト全体のURL群ステータス（Good/NI/Poor） 優先度付け、改善進捗の管理
Chrome UX Report (CrUX) 実ユーザー体験データの母集団 経営報告・中長期トレンド監視
Lighthouse（DevTools） ローカル再現と原因調査 開発中のデバッグ、リリース前確認

補足として、web.dev/measure は現在 PageSpeed Insights（pagespeed.web.dev）へリダイレクトされます。現場運用では「PSIで仮説」「Search Consoleで面の確認」「Lighthouseで原因特定」の3段構えが最も回しやすいです。

WordPress特有の落とし穴

1) プラグイン過多

機能追加のたびにプラグインを積むと、JS/CSSの読み込み、DBクエリ、フック処理が増えます。“有効化中プラグイン数”より“フロントで読み込まれる資産量”を監視してください。

2) 多機能テーマ依存

高機能テーマは便利ですが、使わない機能の資産まで配信しがちです。テーマ更新のたびにCWVが悪化する構造なら、子テーマでの読み込み制御かテーマ見直しを検討すべきです。

3) 画像の未最適化

「圧縮済み」でも、表示サイズ不一致や無駄な高解像度配信でLCPを悪化させます。アップロード運用ルール（最大辺、フォーマット、自動変換）を先に決める方が再発防止に効きます。

4) スライダーとサードパーティ

スライダー、チャット、ヒートマップ、広告、ABテストはINP/CLSの悪化要因になりやすい領域です。全ページ常時読込ではなく、ページ条件で遅延・限定読込に切り替えるだけで改善するケースが多いです。

実用プラグイン比較（2026年4月時点）

プラグイン 価格帯 強み 注意点 向いているケース
WP Rocket 有料（定価: Single $59/年、Plus $119/年、Multi $299/年 ※セール価格になることあり） 導入直後から効く総合最適化。Delay JS、LazyLoad、キャッシュ設定が比較的容易 無料版なし。細かな例外調整は検証が必要 人手が限られ、短期で成果を出したい中小企業
LiteSpeed Cache プラグイン自体は無料 LiteSpeed/QUIC.cloud環境で強力。サーバーレベルキャッシュと相性が良い サーバー条件で実力差が出る。QUIC.cloud機能は利用量課金あり LiteSpeedサーバー運用、またはQUIC.cloud活用前提
W3 Total Cache 無料版あり（Proは$99/年〜） 設定自由度が高く、細かいチューニングが可能 設定難度が高く、誤設定で逆効果になりやすい 技術者が継続運用できるチーム
Autoptimize 無料版あり（Proは月額/年額） CSS/JS最適化に強い。既存キャッシュ系プラグインと併用しやすい これ単体ではページキャッシュが弱い構成もある 既存キャッシュ基盤にフロント最適化を足したい場合
EWWW Image Optimizer / ShortPixel 無料枠+有料プラン 画像最適化の運用を自動化しやすい。WebP/AVIF対応 プランは配信量・クレジットで変動。運用前に月間画像量の試算が必要 画像点数が多く、更新頻度の高いサイト

自社対応 vs 専門家依頼の判断基準

状況 推奨判断
LCP/INP/CLSのどれか1つが軽度悪化、改修権限あり まず内製で2〜4週間の改善スプリント
複数指標がPoor、原因がテーマ/サーバー/タグにまたがる 早めに専門家を入れて設計から再整理
改善しても1〜2か月で再悪化する 運用設計（監視・リリース基準）を外部支援で再構築
売上影響が大きいLP/EC/資料請求導線 最初から計測設計込みで専門家併走が安全

判断ポイントは「修正可否」ではなく「再現性」です。単発でスコアを上げても、更新のたびに崩れるなら事業KPIには寄与しません。

まとめ

WordPressのCWV対策は、次の順で進めると失敗しにくくなります。

  1. 主要URLの実測を取得（PSI + Search Console）
  2. LCPを先に改善（画像とTTFB）
  3. INPを次に改善（JSと長時間タスク）
  4. CLSを最後に潰す（寸法指定と枠確保）
  5. プラグインと外部タグを定期棚卸し

「点数を上げる施策」ではなく「ユーザーが離脱しない速度設計」に置き換えると、SEO・CV・運用効率が同時に改善します。

WP Axisでは、WordPressの復旧・高速化・運用保守の現場知見をもとに、計測 → ボトルネック特定 → 実装 → 再発防止運用 まで一気通貫で支援しています。自社での切り分けが難しい場合は、影響の大きいページから優先してご相談ください。

参考情報（公式・一次情報）

※本記事は2026年4月時点の公開情報を基に作成しています。料金や機能は変更されるため、導入前に各公式ページの最新表記を確認してください。