① Core Web Vitalsとは何か

Core Web Vitalsは、Googleがユーザー体験を測る上で重視する3つの指標「LCP」「INP」「CLS」の総称です。2024年3月に、それまでの指標だった「FID(First Input Delay)」が廃止され、「INP(Interaction to Next Paint)」に置き換わりました。

2.5秒
LCPの目標値(以下)
200ms
INPの目標値(以下)
0.1
CLSの目標値(以下)
「良好」の判定基準Google Search Consoleでは、対象URLのうち75パーセンタイルの訪問者がこの目標値をクリアしていれば「良好」と判定されます。一部の遅い環境からのアクセスがあっても、大多数が基準を満たしていれば問題ありません。

② LCP(Largest Contentful Paint)の改善

LCPは、ページ内で最も大きな要素(多くの場合はメイン画像やヒーロー画像、見出しテキスト)が表示されるまでの時間です。「ページが読み込まれた」とユーザーが体感するタイミングに最も近い指標とされています。

主な悪化原因

原因影響度
サーバー応答が遅い(TTFBが長い)
レンダリングを妨げるCSS/JavaScript
LCP対象画像の読み込みが遅い(圧縮不足・fetchpriority未設定)
クライアントサイドレンダリング(JSでコンテンツを後から描画)

具体的な改善策

LCP画像にfetchpriority="high"を設定 ふつう
ブラウザに「この画像を最優先で読み込め」と伝える属性です。ヒーロー画像やファーストビューのメイン画像に設定することで、LCPが大幅に改善するケースがあります。
LCP画像にloading="lazy"を付けない かんたん(アンチパターン回避)
画面外の画像には遅延読み込みが有効ですが、最初から見えているLCP画像に遅延読み込みを設定すると、かえって表示が遅れる原因になります。
TTFB(サーバー応答時間)の改善 むずかしい
キャッシュプラグインの導入、PHP・データベースの最適化、サーバーの乗り換えで改善します。詳細はサーバーサイド最適化ガイドを参照してください。
レンダーブロッキングCSS/JSの解消 むずかしい
Critical CSS(ファーストビューに必要なCSSのみ先読み)の導入や、不要なJSのdefer/async設定で改善します。多くのキャッシュプラグインが自動化機能を提供しています。

実装例

<!-- LCP画像への設定例 -->
<img src="hero.jpg" fetchpriority="high" width="1200" height="600" alt="メインビジュアル">

<!-- 画面外の画像(LCP対象外)には遅延読み込みを付ける -->
<img src="below-fold.jpg" loading="lazy" width="800" height="400" alt="補足画像">
fetchpriority="high"とloading="lazy"を同じ画像に併用すると矛盾した指示になるため、必ずどちらか一方のみを設定してください。
LCP要素の特定方法Chrome DevToolsの「Performance」タブでページを記録し、「LCP」とラベル付けされたタイムラインのマーカーをクリックすると、どの要素がLCPと判定されているか正確に確認できます。背景画像(CSSのbackground-image)がLCP要素になっている場合はfetchpriority属性が使えないため、preloadタグでの対応が必要です。

③ INP(Interaction to Next Paint)の改善

INPは、ユーザーがクリック・タップ・キー入力などの操作を行ってから、画面に視覚的な反応が返るまでの時間です。訪問中に発生した全ての操作のうち、ほぼ最悪値(高いパーセンタイル)が採用されるため、「1回でも重い処理があると悪化する」厳しい指標です。

主な悪化原因

原因影響度
メインスレッドを占有する重いJavaScript処理
サードパーティスクリプト(広告・SNS埋め込み・チャットツール等)
大量のDOM要素(1ページに多すぎる要素数)
入力イベントハンドラの処理が重い

具体的な改善策

不要なサードパーティスクリプトの見直し ふつう
reCAPTCHA・SNSウィジェット・チャットツール等は、必要なページのみに限定して読み込むよう設定します。詳細は高速化ガイドのサードパーティスクリプト対策を参照してください。
JavaScriptの遅延実行・分割 むずかしい
ページ表示直後に必要な処理と、後から実行してよい処理を分離します。WP RocketやFlyingPressの「JS遅延実行」機能で自動化できる場合があります。
Perfmattersでスクリプトをページ単位無効化 ふつう
お問い合わせページ以外でフォーム用スクリプトを読み込まない、といった制御によりメインスレッドの負荷を軽減できます。詳細はPerfmattersの解説ページを参照してください。
INPは「体感速度」に直結するLCPやスコアの数値が良くても、ボタンを押した反応が鈍いとユーザーは「遅い」と感じます。INPはこうした体感速度を最も正確に反映する指標です。

実装例:長いタスクの分割

// 悪い例:1つの重い処理でメインスレッドを占有
function heavyProcess(items) {
  items.forEach(item => process(item)); // 数千件を一気に処理
}

// 改善例:処理を分割してブラウザに制御を返す
function processInChunks(items, index = 0) {
  const chunkSize = 50;
  const chunk = items.slice(index, index + chunkSize);
  chunk.forEach(item => process(item));
  if (index + chunkSize < items.length) {
    setTimeout(() => processInChunks(items, index + chunkSize), 0);
  }
}
これは開発者・カスタムテーマ制作者向けの例です。既製プラグインを使っている場合は、プラグイン側の設定でスクリプトの遅延実行を有効にすることで同様の効果が得られます。

④ CLS(Cumulative Layout Shift)の改善

CLSは、ページ読み込み中に要素が突然動く(レイアウトがずれる)度合いを数値化した指標です。「読もうとしたら広告が挿入されてボタンを誤タップした」といった経験を防ぐための指標といえます。

主な悪化原因

原因影響度
画像・広告にwidth/heightが指定されていない
Webフォント読み込み時のFOUT(フォント切り替わりによるずれ)
JavaScriptによる動的コンテンツの後挿入(バナー・通知等)

具体的な改善策

imgタグにwidth・heightを明示 かんたん
サイズを事前に指定することで、画像の読み込み前にブラウザが表示領域を確保でき、後からのずれを防げます。WordPress 5.5以降は自動でこの属性が付与されますが、テーマによっては除去されている場合があるので確認してください。
font-display: swap の設定 ふつう
Webフォント読み込み中はシステムフォントで先に表示し、読み込み完了後に切り替えます。切り替え時のずれを最小限にするには、システムフォントとWebフォントで文字サイズの差が小さいものを選ぶことも重要です。
動的コンテンツ用の領域を事前確保 ふつう
広告枠や通知バナーなど後から挿入される要素には、min-heightなどであらかじめ領域を確保しておきます。

実装例

/* フォント切り替え時のずれを防ぐ */
@font-face {
  font-family: 'CustomFont';
  src: url('font.woff2') format('woff2');
  font-display: swap;
}

/* 動的挿入要素の領域を事前確保 */
.ad-slot { min-height: 250px; }

/* aspect-ratioで画像比率を保持(width/height指定が難しい場合) */
img.responsive { width: 100%; height: auto; aspect-ratio: 16 / 9; }

⑤ 測定ツールの使い分け

ツールデータの種類用途
PageSpeed Insightsラボ+フィールド(両方表示)手軽に総合スコアと改善提案を確認したいとき
Google Search Consoleフィールドデータのみ実際の訪問者の体感値をURLグループ単位で把握したいとき
Chrome DevTools(Performanceタブ)ラボデータのみどの処理が重いか、詳細なボトルネックを特定したいとき
web.dev/measure・CrUX Dashboardフィールドデータのみ過去28日間の推移をグラフで確認したいとき

⑥ フィールドデータとラボデータの違い

ラボデータは、決められた条件(回線速度・端末スペックを固定)で1回だけ測定したシミュレーション値です。再現性が高く、改善前後の比較に向いています。

フィールドデータは、実際にサイトを訪れた人のブラウザから集計された実測値(Chrome UX Reportが元データ)です。過去28日間の集計のため反映に時間差があり、訪問者の回線環境やデバイスに数値が左右されます。

両方を見る理由ラボデータだけを見ていると「スコアが90点なのに、Search Consoleでは不良と表示される」という食い違いが起こります。改善作業はラボデータで検証し、最終的な効果判定はフィールドデータ(Search Console)で行うのが基本です。

⑦ よくある改善の落とし穴

スコアだけを追いかけて表示崩れを起こす
「未使用CSSの削除」や「JS遅延実行」は効果が大きい反面、正しく除外設定をしないとレイアウトが崩れたり、機能が動作しなくなることがあります。設定後は必ず主要ページの見た目と動作を確認してください。
1回だけ計測して満足してしまう
フィールドデータは反映まで最大28日かかります。施策後は最低でも2〜4週間おいてからSearch Consoleで最終確認しましょう。
PC版の数値だけを見てしまう
Googleの評価はモバイルファーストです。PCスコアが100点でも、モバイルスコアが低ければ実質的な評価は低いままです。必ずモバイル版の数値を優先して確認してください。

⑧ よくある質問(FAQ)

Core Web VitalsはGoogleの検索順位に直接影響しますか?
Core Web Vitalsは「ページエクスペリエンス」の評価要素の1つで、公式には順位を決める数百の要因の中の1つとされています。コンテンツの質に比べれば影響は限定的ですが、同水準のコンテンツ同士が競合する場面では差がつく要因になり得ます。
INPとFIDの違いは何ですか?
FID(First Input Delay)は「最初の1回」の応答性しか測定できませんでしたが、INP(Interaction to Next Paint)は訪問中に発生した全ての操作の応答性を評価します。2024年3月にFIDは正式に廃止され、INPがCore Web Vitalsの正式指標になりました。
PageSpeed Insightsのスコアが良いのにCore Web Vitalsで「不良」と表示されるのはなぜですか?
PageSpeed Insightsのスコアはラボデータ(1回のシミュレーション測定)、Core Web Vitalsのフィールドデータ(Search Console等に表示される数値)は実際の訪問者の環境から集計した実測値です。回線速度が遅い訪問者や低スペック端末からのアクセスが多いと、ラボスコアが良くてもフィールドデータは悪化することがあります。
モバイルとPCどちらのCore Web Vitalsを優先すべきですか?
モバイルを優先してください。Googleはモバイルファーストインデックスを採用しており、検索順位への影響もモバイル版のCore Web Vitalsが基準になります。PCスコアが良好でもモバイルが不良のままでは評価は改善しません。
3つの指標のうち、まずどれから改善すべきですか?
Google Search ConsoleのCore Web Vitalsレポートで「不良」の件数が最も多い指標から着手するのが効率的です。一般的にはLCPが最も改善余地が大きく、対策の効果も出やすい傾向があります。3指標とも「不良」がない場合は、次に「改善が必要」の指標に着手してください。

関連コンテンツ