WordPressの表示速度（Core Web Vitals / CWV）を最短で上げるコツは、闇雲にプラグインを入れることではなく、Google公式ツールで計測→原因をLCP/INP/CLSに切り分け→効く順に手当てすることです。とくに初心者がやりがちな「最適化プラグインの重ねがけ」は、表示崩れや真っ白化の原因になりやすいので、1つずつ、必ず再計測しながら進めます。
- 計測に使うツール（PageSpeed Insights / Search Console）の具体手順
- LCP / INP / CLS別：遅い原因の見つけ方と直し方
- 画像圧縮・キャッシュ・テーマ/プラグイン整理の「効く順」チェックリスト
- やりがちな失敗と回避策（サイトを壊さない進め方）
- それでも遅い場合の“限界”の見極め（サーバー・TTFB）
プラグインを入れたのに、なぜPSIが赤いままなのか
「プラグインを言われるがままに入れたのに、PageSpeed Insightsのスコアが赤いまま……」
「スマホで自分のサイトを開くと、画像が出るまで数秒待たされる……」
表示速度の底なし沼は、だいたい“診断せずに治療を始めた”ことが原因です。WordPressの高速化は、根性論ではなく外科手術に近いです。Core Web Vitals（LCP・INP・CLS）のうち、どれが・何によって足を引っ張られているかを特定して、優先度順に潰していきます。
この記事は「最短でスコアを緑に寄せたい」人向けに、作業をチェックリスト化しました。上から順になぞるだけで、速度改善が“再現可能”になります。
LCP / INP / CLS は「何の項目」なのか
Core Web Vitals（CWV）は、Googleが「ユーザー体験として重要」としている3つの指標のセットです。ざっくり言うと、表示の速さ（LCP）・操作の快適さ（INP）・見た目の安定（CLS）を測っています。
LCP（Largest Contentful Paint）
何を測る？：ページを開いてから、画面内の「一番大きな主要コンテンツ（画像や見出しブロックなど）」が表示されるまでの時間です。
読者の体感：「最初に“ちゃんと表示された”と感じるまでの待ち時間」。
よくある原因：ファーストビューの大画像が重い／サーバー応答（TTFB）が遅い／CSSやフォントで表示が止まる。
INP（Interaction to Next Paint）
何を測る？：クリック・タップ・入力などの操作をしてから、画面が次に反応（描画）するまでの遅れです。ページ上の操作体験をまとめて評価します。
読者の体感：「ボタン押したのに反応が遅い」「スクロールはできるけど操作が重い」。
よくある原因：プラグインや広告タグのJavaScriptが重い／外部スクリプトが多い／ページがゴテゴテで処理が重い。
※INPは2024年3月にFIDの後継としてCore Web Vitalsに採用された比較的新しい指標です。
CLS（Cumulative Layout Shift）
何を測る？：ページ読み込み中にレイアウトがどれだけズレたか（ガタついたか）を示す指標です。数値が大きいほど「ズレが多い」状態です。
読者の体感：「読んでいたら急にズレて誤タップ」「広告が出てきて文章が飛ぶ」。
よくある原因：画像や広告枠のサイズ指定がない／Webフォント読み込みで文字幅が変わる／後出しバナーが上部に入る。
まず使うツール：計測はGoogle公式で固める
初心者が迷子にならないために、使う計測ツールはこの2つで十分です。
PageSpeed Insights（PSI）
URLを入れるだけで、スマホ/PC別にLCP・INP・CLSの状況と改善提案が出ます。まずはここから。
Search Console（Core Web Vitalsレポート）
サイト全体の「良好/改善が必要/不良」を、実ユーザーデータ（フィールドデータ）ベースで見られます。改善対象URLの“当たり”を付けるのに便利です。
CWVの基礎：LCP/INP/CLSの目標ライン
- LCP：2.5秒以内が目標（表示の遅さ）
- INP：200ms以内が目標（操作のもたつき）
- CLS：0.1未満が目標（レイアウトのガタつき）
補足（重要）：INPは新しい指標です。INPはFIDの後継として、2024年3月にCore Web Vitalsへ置き換わりました。最近の基準ほど“操作感”にシビアなので、昔より「広告/外部スクリプト/重いJS」の影響が出やすいです。
最短で上げる全体手順（この順番を守る）
- 計測するページを3つに絞る
- LCP/INP/CLSのどれが悪いかを特定
- 効く順に改善（画像→キャッシュ→JS/プラグイン→CLS）
- 再計測→記録（1回に1テーマ）
Step0：計測の準備（直すページを3つに絞る）
全部直そうとすると終わりません。まずはこの3つだけ。
- 集客の主力ページ（PVが多い記事1本）
- 収益ページ（比較/ランキング/レビューのいずれか）
- 代表記事（普段の構成に近い標準記事1本）
この3URLを、PageSpeed Insightsでスマホ/PCそれぞれ測ります。PSIは「ラボデータ（実験環境）」なので、改善の方向性を決めるのに使い、結果の定着はSearch Console（実ユーザー）で追うのがやりやすいです。
Step1：原因の切り分け（犯人はLCP/INP/CLSのどれ？）
LCPが悪い（表示が遅い）ときの典型
- ファーストビューの大画像（ヒーロー画像/アイキャッチ）が重い
- サーバー応答（TTFB）が遅い
- CSS/JSが読み込みを塞いでいる（レンダリングブロック）
- フォント読み込みで表示が止まる
実はこれが一番手間の割に効くのですが、LCPは「最初の大要素」が原因のことが多いです。ここを軽くするだけで体感が変わります。
INPが悪い（操作がもたつく）ときの典型
- プラグイン由来のJSが多い（スライダー/アニメ/目次/ポップアップ）
- 広告タグ・計測タグ・外部スクリプトが多い
- DOMが肥大化（装飾ブロック多用、テーマが重い）
INPは「最初の操作だけ」ではなく、ページ上の操作全体を見ます。昔より“じわっと効く重さ”がバレやすくなりました。
CLSが悪い（ガタつく）ときの典型
- 画像/広告/埋め込みのサイズ指定がなく、読み込み後にズレる
- Webフォントで文字幅が変わる
- 上部に後出しでバナー・お知らせが挿入される
最短改善チェックリスト（効果が大きい順）
時間がない人は、まずここだけ。1つずつやって、PSIで再計測してください。
1）画像（LCPの主犯を潰す）
- ファーストビューの大画像をWebP（可能ならAVIF）にする
- 画像の横幅を「実表示サイズ」へ（無駄に2000pxを置かない）
- アップロード時に自動圧縮（運用で詰まない仕組みに）
- Lazy Loadを使う（ただしLCP画像は遅延しない）
- アイキャッチ多用なら、サムネ生成サイズを整理する
プラグイン例（画像最適化）：EWWW Image Optimizer / ShortPixel / Imagify など（どれか1つでOK）。
2）キャッシュ（TTFBと体感を変える）
- ページキャッシュ（HTMLを作り直さない）を有効化
- ブラウザキャッシュ（静的ファイル再取得を減らす）
- CDNを検討（画像・CSS/JS配信を最適化）
- （余裕があれば）オブジェクトキャッシュでDB負荷を減らす
プラグイン例（キャッシュ）：WP Super Cache / W3 Total Cache / LiteSpeed Cache（サーバー条件あり）など。
私も昔やったのですが、キャッシュ系を2つ以上同時に入れると、CSS/JSが二重に最適化されて表示崩れが起きやすいです。キャッシュ系は基本1つで運用してください。
3）テーマとプラグイン（INPの主犯を削る）
- 使っていないプラグインを削除（停止だけでなく削除）
- 重い機能（スライダー/過剰装飾/ポップアップ）を見直す
- SNS埋め込み・動画埋め込みを減らす（必要なら軽量化）
- 計測タグを棚卸し（増やしすぎない）
4）CLS（ガタつき）即効対策
- 画像・広告・埋め込みの“枠”を先に確保（幅/高さ）
- 上部に後出しで出るバナーや告知を整理する
- フォントの後読みでズレるなら、フォント戦略を軽くする
最短でCWVを上げる具体手順（LCP→INP→CLS）
手順1：LCP改善（最優先）
- PSIで「LCP要素」を確認（だいたい画像か見出しブロック）
- ファーストビュー画像を最適化（形式・サイズ・圧縮）
- LCP画像はLazy Loadしない（ここが罠）
- ページキャッシュを導入（まず1つだけ）
ここでスコアが動かないなら、TTFB（サーバー初期応答）がネックの可能性が上がります。後半の「限界チェック」を見てください。
手順2：INP改善（次に効く）
- 広告・解析・ヒートマップ等の外部スクリプトを棚卸し
- 重いプラグインを1つずつ外して変化を見る（同時に触らない）
- 記事内の埋め込み（SNS・動画）を減らす／軽量化
INPは「正義の最適化」をやりすぎると逆効果になることがあります。とくにJS最適化（遅延/結合/縮小）は、やり方を間違えるとクリック不能・レイアウト崩れが起きます。必ずバックアップしてから。
手順3：CLS改善（最後に仕上げ）
- 画像・広告・埋め込みの枠を確保（高さが決まらない要素が犯人）
- 固定ヘッダーや告知バーの挙動を見直す
- フォントでズレるなら、読み込み方式を見直す（必要ならシステムフォント寄り）
具体例：副業ブロガーの「重いサイト」を1時間で改善する作戦
状況：WordPress、画像多めのレビュー記事が主力。スマホで遅い。プラグイン多め。
作戦（1時間）：
- （15分）代表記事のファーストビュー画像をWebP化＋サイズ調整（LCPを動かす）
- （15分）不要プラグインを3つ削除（INPの土台を軽くする）
- （15分）ページキャッシュ導入（キャッシュ系は1つだけ）
- （15分）広告枠/画像枠のズレを1箇所直す（CLSの体感を改善）
ポイントは「全部やらない」。まず“動くところ”だけ動かして、改善の手応えを作ります。
改善の限界：ここまでやってTTFBが遅いなら、サーバーを疑う
表示速度の改善は、最後に必ず物理的な限界に当たります。画像も軽い、キャッシュも入れた、それでもPSIで「初期サーバー応答が遅い（TTFB）」が強く出るなら、原因はサイトの中よりサーバー側かもしれません。
- 同時アクセスに対してプランが弱い（CPU/メモリ不足）
- 安価プランでリソース制限が厳しい
- DBが肥大化・最適化不足（記事数/プラグイン多い）
この場合、表示速度沼で消耗するより、プラン変更や乗り換えを検討した方が早いケースがあります（特に収益記事が育ってきた段階）。
よくある失敗5選と回避策
失敗1：速度系プラグインの重ねがけで表示崩れ
回避策：キャッシュ/最適化は役割が被りがち。まず1つ→再計測→次、の順。
失敗2：Lazy LoadでLCP画像まで遅延してしまう
回避策：LCP要素（ファーストビューの主役画像）は遅延しない。遅延は下部の画像へ。
失敗3：プラグインを停止だけして放置
回避策：不要なら削除。停止は検証用に限定。
失敗4：外部スクリプトを増やしてINPが悪化
回避策：広告・計測・埋め込みは増やすほど重くなる。優先順位を決める。
失敗5：スコアだけ追って読みにくくなる
回避策：体感（スクロール/クリック）も必ず確認。読者体験が悪い改善はやらない。
すぐできるチェックリスト（WordPress表示速度）
- PageSpeed Insightsで「スマホ/PC」を測った（対象3ページ）
- LCP画像はWebP/AVIF＋適正サイズで、Lazy Loadしていない
- 画像はアップロード時に自動圧縮になっている
- ページキャッシュは“1つだけ”有効化した
- 不要プラグインを削除した（停止だけで放置していない）
- 広告・埋め込みの枠を確保し、CLSを抑えた
- 計測タグを棚卸しした（増やしすぎていない）
- 改善は1回に1テーマで、再計測して記録した
まとめ
表示速度改善の最短ルートは、PSIで計測→LCP/INP/CLSを特定→「LCP→INP→CLS」の順で潰すことです。INPは2024年3月にFIDから置き換わった新基準なので、広告や外部スクリプトの影響が以前より目立ちやすくなっています。
WordPressでは、まず画像最適化とキャッシュが一丁目一番地。次にプラグイン/テーマ由来のJSを減らし、最後にレイアウトのガタつきを整える。この順番を守るだけで、CWVは改善しやすくなります。どうしてもTTFBが遅いなら、サーバーの限界も疑う。ここまでが“沼にハマらない”速度改善です。
次にやること（3ステップ）
- PageSpeed Insightsで3ページを計測（トップ/収益/代表記事）
- LCPから着手（ファーストビュー画像最適化＋ページキャッシュ1つ）
- INP→CLSで仕上げ（不要プラグイン削除→枠確保でズレ防止。改善は1回に1テーマ）
