この記事でわかること
- Core Web Vitals（LCP・INP・CLS）の合格基準と、表示速度がSEO・CVに効く理由を最短で把握する
- WordPressが遅くなる主因の切り分け方（画像・プラグイン・テーマ・サーバー・コード）
- 多くの記事が薄い「どの順で手をつけるか」を、効果×手間×リスクの3軸で並べた着手手順
- 指標別（LCP/INP/CLS）の具体施策と、推奨プラグイン＋事故を防ぐ使い方
- 計測で迷わないためのフィールドデータとラボデータの違い（スコアに振り回されない見方）
公的情報源: Google web.dev「Core Web Vitals」（参照）／Google 検索セントラル「ページ エクスペリエンス」（参照）
サーバーの選び方から見直すと改善の天井が上がります。あわせてWordPressにおすすめのサーバーとPHP・キャッシュ設定も読むと、本記事の手順がつながります。
結論を先に書きます
WordPressの表示速度改善は、施策を片端から試すより「壊れにくく・効果が大きい順」に着手するのが最短ルートです。具体的には、サーバーとPHPの見直し → 画像の最適化 → キャッシュ → 不要プラグイン削除 → コード最適化、の順で進めます。
判断の物差しになるのがCore Web Vitals（LCP・INP・CLS）です。体感の「速い・遅い」ではなく、Googleが定義した3指標の合格基準で測ると、どこが足を引っ張っているかが数字で見えます。
この記事は、サイトを作る側（制作会社・フリーランス）と運用する側（中小企業のWeb担当者）の両方を想定し、原因の切り分け・計測・着手順・指標別施策を、ひとつずつ整理します。
- 速度改善は着手順がすべて。効果が大きく壊れにくい「サーバー・画像・キャッシュ」から手をつける
- 目標はCore Web Vitalsの3指標。LCP 2.5秒以下／INP 200ms以下／CLS 0.1以下が合格ライン
- WordPressが遅い主因は画像・プラグイン肥大・低速サーバー・重いテーマの4つにほぼ集約される
- キャッシュ・最適化プラグインは事故りやすい。必ずバックアップを取り、1つずつ入れて検証する
Core Web Vitalsとは表示速度の合格ライン
まず結論です。Core Web Vitalsとは、Googleがユーザー体験を数値化した3つの指標で、表示速度改善の「ゴール」になります。体感ではなくこの基準で測ると、改善の優先度が決まります。
Google 検索セントラルでは、ページ エクスペリエンスの中核としてこの3指標が位置づけられています。順位を一発で上げる魔法ではありませんが、同程度の品質のページが並んだとき、速いほうが有利という形で効いてきます。
Core Web Vitals 3指標と合格基準
| 指標 | 何を測るか | 良好（合格） | 要改善の目安 |
|---|---|---|---|
| LCP（最大コンテンツの描画） | 表示の速さ | 2.5秒以下 | 4.0秒超で不合格 |
| INP（次の描画までの応答） | 操作への反応 | 200ms以下 | 500ms超で不合格 |
| CLS（レイアウトのずれ） | 表示の安定 | 0.1以下 | 0.25超で不合格 |
INPは、かつての指標FID（初回入力遅延）に代わって採用された応答性の指標です。クリックやタップへの反応の鈍さを測るため、JavaScriptや重いプラグインが多いサイトほど悪化しやすい特徴があります。
3指標は性質が違うので、対策も分かれます。LCPは「速く出す」、INPは「軽く反応させる」、CLSは「ガタつかせない」と整理すると、後の施策がつながります。
WordPressが遅くなる主な原因
WordPressの表示が遅いとき、原因は無数にあるように見えて、実際は4つの主因にほぼ集約されます。手を動かす前に、どこが重いのかを切り分けます。
- 画像が重い ── 未圧縮・原寸のまま・次世代フォーマット未対応。LCPを直接悪化させる最大要因。
- プラグインの入れすぎ ── 読み込むCSS/JSが増え、INPとページ全体が重くなる。
- サーバーが遅い ── 共用の格安プラン・古いPHP。応答（TTFB）が遅いと全施策の天井が下がる。
- テーマが重い ── 多機能テーマや無駄なスクリプト。表示と操作の両方を引きずる。
切り分けの順番は「サーバー（土台）→ 画像（最大の重り）→ プラグイン・テーマ（積み重なった負荷）」です。土台が弱いまま小手先の最適化をしても、効果が頭打ちになります。
たとえば画像を完璧に圧縮しても、サーバーの初動（最初の1バイトが返るまでの時間）が遅ければ、表示は速くなりません。だからこそ着手順が重要になります。
改善の前に必ず現状を計測する
速度改善は、計測なしで始めないのが鉄則です。どこが遅いかを数字で押さえてから、効く施策だけに絞ります。主な計測ツールは2つです。
主な速度計測ツール
| ツール | 見られること | 使いどころ |
|---|---|---|
| PageSpeed Insights | スコア・指標・改善提案 | 最初の現状把握（無料・公式） |
| GTmetrix | 読み込みの内訳・ウォーターフォール | どのファイルが重いかの深掘り |
ここで初心者がつまずくのが、「フィールドデータ」と「ラボデータ」の違いです。Google web.dev でも区別されている、性質の異なる2種類です。
- フィールドデータ：実際のユーザーの計測値（Chromeの利用統計＝CrUX由来）。直近28日間の集計で、改善が反映されるまで時間がかかる。
- ラボデータ：その場での擬似計測（Lighthouse）。条件をそろえた検証用で、改善の確認に向く。
改善直後にフィールドデータが動かなくても焦らないのがコツです。ラボデータ（Lighthouse）で効果を確認し、フィールドの数値は数週間かけて追います。スコアの上下に一喜一憂せず、3指標の実測値を基準にします。
WordPress表示速度を改善する着手手順
ここからが本題です。施策を「効果×手間×リスク」で並べ、壊れにくく効果が大きい順に進めます。多くの記事が施策を羅列するだけで終わる部分を、順序として示します。
- サーバーとPHPバージョンを見直す（土台）
- 画像を最適化する（最大の重り）
- キャッシュを導入する（効果が大きい）
- 不要なプラグインを削る（負荷の引き算）
- コード（CSS/JS）を最適化する（仕上げ）
施策の効果×手間×リスク早見表
| 施策 | 効果 | 手間 | リスク（壊れやすさ） |
|---|---|---|---|
| サーバー・PHP見直し | 大 | 中 | 低〜中 |
| 画像の最適化（WebP等） | 大 | 小 | 低 |
| キャッシュ導入 | 大 | 小 | 中（表示崩れ注意） |
| 不要プラグイン削除 | 中 | 小 | 中（機能消失注意） |
| CSS/JS最適化 | 中 | 中 | 高（崩れやすい） |
ステップ1 サーバーとPHPを見直す
最も効果が大きく見落とされやすいのが、サーバーとPHPバージョンです。古いPHP 7系から最新の安定版（8.2/8.3など）へ上げるだけで、処理速度が大きく改善するケースがあります。
最新の高速サーバーは、NVMe SSDや新しい通信プロトコルに対応しており、初動（応答速度）の天井そのものが上がります。土台を整えてから上に積むのが効率的です。具体的な選び方はWordPressのおすすめサーバー・PHP・キャッシュ設定でまとめています。
ステップ2 画像を最適化する
LCPを最も直接的に改善するのが画像です。やることは3つに整理できます。
- 次世代フォーマットに変換：WebPやAVIFにして、見た目を保ったままファイルを軽くする。
- 遅延読み込み（lazyload）：画面外の画像を後回しにし、最初の表示を速くする。
- サイズの最適化：表示する大きさに合わせ、原寸の巨大画像を貼らない。
画像最適化は手間が小さくリスクも低いので、費用対効果が最も高い施策です。EWWW Image Optimizerなどのプラグインで一括変換できます。
ステップ3 キャッシュを導入する
キャッシュは、生成済みのページを使い回して表示を速くする仕組みで、効果が大きい施策です。一方で、設定を誤ると表示崩れや更新が反映されない事故が起きやすい領域でもあります。
導入の鉄則は「バックアップを取ってから、1つずつ入れて毎回確認する」こと。キャッシュ・最適化系プラグインを複数同時に有効化すると、原因の切り分けができなくなります。
ステップ4以降 プラグイン整理とコード最適化
使っていないプラグインは停止ではなく削除します。読み込むCSS/JSが減り、INPと全体の重さが軽くなります。最後にコード（CSS/JS）の圧縮・結合・遅延に進みますが、ここはリスクが高いので、表示崩れを必ず確認しながら少しずつ進めます。
Core Web Vitals 指標別の具体施策
着手手順とは別に、特定の指標が悪いときの打ち手を整理します。PageSpeed Insightsで指摘された指標から逆引きで使ってください。
指標別の主な改善施策
| 指標 | 主な原因 | 具体施策 |
|---|---|---|
| LCP | 画像・サーバー応答・読み込み順 | 画像最適化・高速サーバー・主要画像のpreload |
| INP | JS・プラグインの重さ | 重いプラグイン整理・JS遅延・テーマ軽量化 |
| CLS | 画像/広告の領域未確保 | 画像にwidth/height指定・広告枠の予約・フォント最適化 |
特にCLS（レイアウトのずれ）は、画像にサイズ属性を入れるだけで大きく改善することがあります。読み込み中に枠が確保され、後からガクッと動かなくなるためです。手間に対して効果が出やすい施策です。
INPは即効薬が少なく、プラグインとJavaScriptの引き算が基本です。多機能テーマを軽量テーマへ替えるのも有効で、テーマ選びはSWELL・Cocoon・Lightningの比較が参考になります。
推奨プラグインと事故を防ぐ使い方
速度改善を支えるプラグインを目的別に整理します。多くは無料で使えますが、入れれば速くなる魔法ではない点に注意します。
目的別の代表プラグイン
| 目的 | 代表プラグイン | 役割 |
|---|---|---|
| 画像最適化 | EWWW Image Optimizer | 圧縮・WebP変換 |
| キャッシュ | WP Fastest Cache / LiteSpeed Cache | ページ生成の高速化 |
| コード最適化 | Autoptimize | CSS/JSの圧縮・結合 |
使うときの鉄則は3つです。第一にバックアップを取ってから入れる。第二に1つずつ有効化して毎回計測する。第三に役割が重複するプラグインを併用しない。キャッシュ系を2つ同時に動かすと、原因不明の崩れにつながります。
プラグインの選定全般はWordPressのおすすめプラグインでも整理しています。「入れすぎが遅さの原因」になり得る点を忘れず、必要なものだけに絞ります。
発注側・受注側それぞれのチェックポイント
表示速度は、立場によって見るべき点が変わります。制作と運用ですれ違わないよう、両視点を整理します。
- 発注側（Web担当者・経営者） ── 納品時にCore Web Vitalsの合格を確認項目に入れる。改善を「速くして」と曖昧に頼まず、指標と目標値で依頼する。
- 受注側（制作・フリーランス） ── サーバー要件とPHPバージョンを最初に握る。キャッシュ・最適化は納品前にバックアップと検証をセットで行う。
どちらの立場でも、計測の数値を共通言語にするとすれ違いが減ります。「なんとなく遅い」ではなく「LCPが4秒だから2.5秒を目指す」と話せると、改善の合意が取りやすくなります。
WordPress表示速度の改善に関するよくある質問
Q1. WordPressの表示速度はどこから改善すべきですか？
効果が大きく壊れにくい順に進めます。①サーバー・PHPの見直し → ②画像の最適化 → ③キャッシュ導入 → ④不要プラグイン削除 → ⑤コード最適化が基本の着手順です。土台であるサーバーが遅いと、画像やコードをいくら最適化しても効果が頭打ちになります。最初にPageSpeed Insightsで現状を測り、遅い原因を切り分けてから手をつけてください。
Q2. Core Web Vitalsの合格基準を教えてください。
3指標それぞれに基準があります。LCP（表示の速さ）は2.5秒以下、INP（操作への反応）は200ミリ秒以下、CLS（レイアウトのずれ）は0.1以下が「良好（合格）」のラインです。LCPが4秒超、INPが500ミリ秒超、CLSが0.25超になると「不合格」と判定されます。PageSpeed Insightsでこの3つの実測値を確認し、合格していない指標から優先して対策します。
Q3. キャッシュプラグインを入れたら表示が崩れました。なぜですか？
キャッシュは生成済みのページを使い回すため、設定や他プラグインとの相性で表示崩れや更新の未反映が起きやすい領域です。対策は、導入前に必ずバックアップを取り、1つずつ有効化して毎回表示を確認することです。キャッシュ系・最適化系を複数同時に動かすと原因の切り分けができなくなるため、役割が重複するプラグインは併用しないでください。崩れたら一度キャッシュを削除（クリア）して切り分けます。
Q4. PageSpeed Insightsのスコアが上がりません。改善できていないのでしょうか？
そうとは限りません。改善が反映されにくいのは、フィールドデータ（実ユーザーの計測値）が直近28日間の集計で、変化が出るまで時間がかかるためです。改善直後はラボデータ（Lighthouse）で効果を確認し、フィールドの数値は数週間かけて追います。スコアという1つの数字ではなく、LCP・INP・CLSの実測値が基準を満たしているかで判断してください。
Q5. プラグインは少ないほど速くなりますか？
数より「重さ」が問題です。読み込むCSS/JSが多いプラグインや、役割が重複するプラグインがあると遅くなります。使っていないプラグインは停止ではなく削除し、同じ役割のもの（キャッシュ系など）は1つに絞ります。一方で、画像最適化やキャッシュのように速度を上げるプラグインもあるため、「とにかく減らす」のではなく、役割が重複する不要なものを整理する、という考え方が現実的です。
Q6. 速くすると検索順位は上がりますか？
速度だけで順位が決まるわけではありません。Core Web Vitalsはページ エクスペリエンスの一要素で、内容の質が同程度のページが並んだときに、速いほうが有利に働くという位置づけです。順位の土台はあくまでコンテンツの有用性です。表示速度は「直帰率や離脱を減らし、コンバージョンの機会を逃さない」ための施策と捉え、SEO全体の改善とセットで進めるのが効果的です。
まとめ WordPress速度改善は着手順で決まる
WordPressの表示速度改善は、施策の知識量より着手する順番で結果が変わります。最後に要点を整理します。
- ゴールはCore Web Vitals。LCP 2.5秒以下／INP 200ms以下／CLS 0.1以下が合格ライン
- 遅い主因は画像・プラグイン肥大・低速サーバー・重いテーマの4つにほぼ集約される
- 着手はサーバー・PHP → 画像 → キャッシュ → プラグイン整理 → コードの順（効果×壊れにくさ）
- キャッシュ・最適化プラグインはバックアップ＋1つずつ検証で事故を防ぐ
- 計測はラボとフィールドの違いを理解し、スコアでなく3指標の実測値で判断する
まずはPageSpeed Insightsで現状を測り、遅い原因を切り分けるところから始めてください。土台のサーバーと画像を整えるだけで、多くのサイトは体感できる差が出ます。計測の数値を共通言語にすれば、制作と運用のすれ違いも減らせます。
※本記事はWordPressの表示速度改善とCore Web Vitalsの公開情報・公式ドキュメントをもとにした整理です。各指標の基準やツールの仕様はGoogleのアップデートにより変更される場合があります。最新情報はGoogle web.dev等の公式情報をご確認のうえ、施策の適用前には必ずバックアップを取得してください。
