WordPressのCore Web Vitalsを改善するときは、LCP・INP・CLSのどれに問題があるかを確認してから変更します。PageSpeed Insightsの点数だけを見て、CSSやJavaScriptをまとめて削除すると、表示や操作を壊すことがあります。
この記事は、SWELLを含むWordPressサイトで、計測結果から修正箇所を選ぶための手順です。ページ全体の容量を調べたい場合はページの重さと内訳の確認へ進んでください。広告設定の変更を前提にした手順ではありません。
現在のCore Web VitalsはLCP・INP・CLS
| 指標 | 見ていること | 良好の目安 |
|---|---|---|
| LCP | 主要なコンテンツの表示までの時間 | 2.5秒以下 |
| INP | クリック・タップ・キー操作への応答性 | 200ミリ秒以下 |
| CLS | 予期しないレイアウトのずれ | 0.1以下 |
目安は実際の利用者のデータの75パーセンタイルで評価します。FIDは2024年にINPへ置き換わっており、現在の3指標に含めません。定義と基準はGoogleのWeb Vitals公式資料で確認できます。ここに記載した値は基準であり、WAZAの実測結果ではありません。
PageSpeed Insightsの実測データとラボデータを分ける
PageSpeed Insightsには、実際のChrome利用者から集計したフィールドデータと、Lighthouseによるラボ測定があります。前者は過去28日間の利用状況を反映し、後者は測定時の条件で原因を調べるために使います。変更直後のラボ結果が良くなっても、フィールドデータがすぐ同じ値へ変わるわけではありません。
URL単位のデータが不足する場合は、オリジン単位のデータが表示されることがあります。どの範囲を見ているかを確認してください。データがない表示を、合格や失敗として扱わないでください。LighthouseのPerformanceスコアとCore Web Vitalsの合否も別です。出典：PageSpeed Insights公式説明。
- 対象URL、測定日、モバイルかPCか、実測データの対象範囲を記録します。
- LCP・INP・CLSのどれが基準を超えるかを確認します。
- ラボの診断やブラウザの開発者ツールから、原因候補の要素・処理を特定します。
- 変更を1つずつ行い、同じ条件で複数回計測します。フォームやメニューなどの操作も確認します。
LCPが遅い：対象要素と表示までの待ち時間を調べる
LCPの対象は必ずしもメイン画像とは限らず、テキストなどの場合もあります。まず計測結果で対象要素を確認し、サーバー応答、対象資産の読み込み開始、転送、描画のどこで待っているかを調べます。画像を圧縮するだけで解決するとは限りません。
- LCP対象が画像なら、表示に必要なサイズと配信画像のサイズを比較します。過大な画像を縮小し、画質と形式を確認します。
- 最初から見える主要画像を遅延読み込みの対象にしていないか確認します。すべての画像の遅延読み込みを一括解除する必要はありません。
- CSS・フォント・JavaScriptなどが表示を待たせていないか調べます。preloadを増やす前に、本当に早く取得したい資産かを判断します。
- サーバー応答が遅い場合は、キャッシュの有無や動的処理を分けて確認します。サーバー移転を最初の結論にしないでください。
変更前後で画像の欠落、遅れて出る文字、ログイン状態による表示差を確認します。ページ単位の容量や読み込み資産の確認はページ重量の調査手順にまとめています。
INPが悪い：遅くなる操作を再現する
INPは読み込み速度だけの指標ではありません。メニューを開く、検索する、フォームへ入力するといった操作を行い、反応が遅い場面を調べます。ラボのTBTは調査の手がかりになりますが、INPと同じ指標として置き換えないでください。
- モバイル相当の環境で、実際に使うメニュー・検索・開閉・入力を操作します。
- 開発者ツールのPerformance記録で、操作時に長く続く処理と描画を確認します。
- 不要な処理を対象ページから外すか、処理を小さく分けられないか検討します。繰り返し登録されたイベントや二重初期化も確認します。
- 修正後に、同じ操作が正しく完了し、キーボードでも利用できることを確かめます。
jQueryを全ページで解除したり、テーマ同梱ライブラリを別版へ差し替えたりする方法を一律には勧めません。利用中のブロックやプラグインの依存関係を調べ、必要な機能を残して読み込み範囲を限定します。
CLSが悪い：ずれを起こした場所を調べる
画像だけでなく、後から挿入される要素、埋め込み、フォントの切り替えなどもレイアウトのずれを起こします。ページ読み込み時だけでなく、スクロールや操作後も確認します。詳しい原因と対処はGoogleのCLS最適化ガイドを参照してください。
- 開発者ツールのレイアウトシフト記録で、ずれた要素と直前の変化を確認します。
- 画像や動画は、実際の縦横比に合う幅・高さや領域を確保します。縦横比の異なる仮の数値で固定しないでください。
- 埋め込みなどの後から表示される要素には、必要な表示領域を事前に確保できるか確認します。
- フォント切り替えによる文字幅や行数の変化を確認します。フォントの取得量だけでなく、表示の安定性も比べます。
DOMContentLoadedの後からJavaScriptで画像サイズを追加しても、最初の描画までに領域を確保できる保証はありません。可能なら出力HTMLやCSSで最初から領域を決めます。親テーマの直接編集は避け、現行テーマで既に寸法が出力されていないか先に確認します。
WordPress・SWELLで変更する順番
- バックアップと戻し方を用意し、検証環境で変更します。
- テーマやプラグインの既存設定を確認し、遅延読み込み・キャッシュ・圧縮の重複を避けます。
- 画像・フォント・外部資産など、計測で特定した対象から調整します。
- 追加コードが必要な場合は対象ページと専用クラスを限定します。保守しやすい制作ルールも確認してください。
- キャッシュを適切に更新して再計測し、画面・フォーム・検索・メニューが壊れていないか確認します。
改善後に残す記録
URL、変更日時、変更箇所、計測条件、変更前後の結果、戻し方を残します。一度の点数だけで改善と断定せず、ラボ測定と実際の利用者データを分けて追います。検索順位や売上の変化も、速度改善だけの効果として断定しないでください。
2026年9月30日に公式資料と照合して説明を更新しました。今回の改訂は記事内容の修正であり、WAZA全体の高速化設定や広告設定を変更した結果ではありません。
よくある質問：WordPressのCore Web Vitalsを改善するとき
Core Web Vitalsの3指標と、良好の目安は？
記事では、LCPは主要なコンテンツの表示までの時間で2.5秒以下、INPはクリック・タップ・キー操作への応答性で200ミリ秒以下、CLSは予期しないレイアウトのずれで0.1以下です。目安は実際の利用者のデータの75パーセンタイルで評価します。FIDは2024年にINPへ置き換わっており、現在の3指標に含めません。最新の定義と基準はGoogleのWeb Vitals公式資料で確認してください。
改善は、どこから始めますか？
記事では、LCP・INP・CLSのどれに問題があるかを確認してから変更します。PageSpeed Insightsの点数だけを見て、CSSやJavaScriptをまとめて削除すると、表示や操作を壊すことがあります。
PageSpeed Insightsの実測データとラボデータは、何が違いますか？
記事では、実際のChrome利用者から集計したフィールドデータは過去28日間の利用状況を反映し、Lighthouseによるラボ測定は測定時の条件で原因を調べるために使います。データがない表示を合格や失敗として扱わないでください。LighthouseのPerformanceスコアとCore Web Vitalsの合否も別です。
LCPが遅いときは、画像を圧縮すれば解決しますか？
解決するとは限りません。記事では、LCPの対象は必ずしもメイン画像とは限らず、テキストなどの場合もあります。まず計測結果で対象要素を確認し、サーバー応答、対象資産の読み込み開始、転送、描画のどこで待っているかを調べます。サーバー移転を最初の結論にしないでください。
最初から見える画像も、遅延読み込みにしてよいですか？
記事では、最初から見える主要画像を遅延読み込みの対象にしていないか確認します。ただし、すべての画像の遅延読み込みを一括解除する必要はありません。
INPが悪いときは、何を調べますか？
記事では、INPは読み込み速度だけの指標ではないため、メニューを開く、検索する、フォームへ入力するといった操作を行い、反応が遅い場面を調べます。モバイル相当の環境で操作し、開発者ツールのPerformance記録で長く続く処理と描画を確認します。ラボのTBTは手がかりになりますが、INPと同じ指標として置き換えないでください。
jQueryを全ページで無効にすれば、INPは改善しますか？
記事では、jQueryを全ページで解除したり、テーマ同梱ライブラリを別版へ差し替えたりする方法を一律には勧めません。利用中のブロックやプラグインの依存関係を調べ、必要な機能を残して読み込み範囲を限定します。
CLSの原因は、画像だけですか？
いいえ。記事では、画像だけでなく、後から挿入される要素、埋め込み、フォントの切り替えなどもレイアウトのずれを起こします。ページ読み込み時だけでなく、スクロールや操作後も確認します。
WordPressやSWELLで変更するときの順番は？
記事では、バックアップと戻し方を用意し、検証環境で変更します。テーマやプラグインの既存設定を確認して、遅延読み込み・キャッシュ・圧縮の重複を避け、画像・フォント・外部資産など、計測で特定した対象から調整します。変更は1つずつ行い、同じ条件で複数回計測します。
改善後は、何を記録しますか？
URL、変更日時、変更箇所、計測条件、変更前後の結果、戻し方を残します。記事では、一度の点数だけで改善と断定せず、ラボ測定と実際の利用者データを分けて追い、検索順位や売上の変化も速度改善だけの効果として断定しないよう注意しています。
