WithCodeMedia-1-pc
previous arrowprevious arrow
next arrownext arrow

WithCodeMedia-1-sp
previous arrowprevious arrow
next arrownext arrow

Core Web Vitals改善ガイド|LCP・INP・CLSを実測して直す手順

生徒

PageSpeed Insightsで測ったら赤い数字だらけでした…。どこから直せばいいですか?

ペン博士

全部いっぺんに直そうとしないこと。LCP・INP・CLSの3つだけ見ればいい。しかも原因は毎回だいたい同じ場所にある。実測して、効く順に潰していこう。

Core Web Vitals(コアウェブバイタル)は、Googleが定めるページ体験の指標です。検索順位の要素のひとつであり、それ以上に離脱率へ直結します。

指標は3つだけです。表示の速さ(LCP)、操作への反応(INP)、レイアウトのずれ(CLS)。それぞれ原因になりやすい箇所が決まっているため、順番に潰せば確実に改善します。

この記事では、まず正しい測り方を示し、3指標それぞれの原因と対処、WordPressでの具体的な設定、改善後の確認方法まで解説します。

  • Core Web Vitalsの3指標と合格ライン
  • 実測の方法(ラボデータとフィールドデータの違い)
  • LCP(表示の速さ)を改善する
  • INP(操作への反応)を改善する
  • CLS(レイアウトのずれ)を改善する
  • 画像の最適化が最も効く理由
  • WordPressでの具体的な設定
  • やりすぎると逆効果になる施策
  • 改善後の確認と継続的な監視
  • 優先順位のつけ方

目次

3つの指標と合格ライン

3つの指標と合格ライン

覚えるのはこの表だけです。数値の意味と、何が原因になりやすいかをセットで押さえます。

指標測るもの良好要改善主な原因
LCP主要コンテンツの表示時間2.5秒以下4.0秒超画像・サーバー応答
INP操作してから反応するまで200ms以下500ms超JavaScriptの処理
CLS表示中のレイアウトずれ0.1以下0.25超サイズ未指定の要素

合格の判定は全ページの75パーセンタイルで行われます。つまり4分の3の訪問で基準を満たす必要があり、一部のページだけ速くても評価されません。

なお、2024年3月にFID(初回入力遅延)が廃止され、INPに置き換わりました。古い記事ではFIDの解説が残っていますが、現在は見る必要がありません。

実測の方法

実測の方法

測定には2種類あり、混同すると「直したのに数値が変わらない」と誤解します。

種類何のデータかツール反映速度
ラボデータ測定環境での1回の結果Lighthouse / PageSpeed Insights即時
フィールドデータ実際の訪問者28日分の集計Search Console / CrUX約28日

改善作業中はラボデータで確認し、最終的な合否はフィールドデータで判断します。修正がフィールドデータに反映されるまで最大28日かかるため、焦らず待ちます。

ブラウザで実測する

Chrome DevTools → Lighthouse タブ
 → モードは「ナビゲーション」、デバイスは「モバイル」を選ぶ
 → 「ページ分析を開始」

※ 拡張機能の影響を避けるため、シークレットウィンドウで測る
// 実際の訪問者の値を自分で計測する(web-vitalsライブラリ)
import { onLCP, onINP, onCLS } from 'web-vitals';

const send = ({ name, value, rating }) => {
  console.log(name, Math.round(value), rating);
  // GA4へ送る場合
  gtag('event', name, { value: Math.round(value), metric_rating: rating });
};

onLCP(send);
onINP(send);
onCLS(send);

実測で最も重要なのはモバイルで測ることです。PCの回線と性能では問題が表面化せず、実際の利用環境と乖離します。

LCP(表示の速さ)を改善する

LCP(表示の速さ)を改善する

ページで最も大きな要素が表示されるまでの時間です。多くのサイトでは、ファーストビューの画像かテキストブロックが対象になります。

まず対象要素を特定する

DevTools → Performance → 記録 → LCPのマーカーをクリック
 または Lighthouse の「最大コンテンツの描画要素」欄を見る

画像が対象の場合

<!-- ファーストビューの画像は遅延読み込みしない -->
<img src="/img/hero.webp"
     width="1200" height="630"
     alt="説明"
     fetchpriority="high">

<!-- 逆に、下部の画像は必ず遅延させる -->
<img src="/img/section.webp" width="800" height="450" alt="説明" loading="lazy">

よくある間違いが、全画像に loading="lazy" を付けることです。ファーストビューの画像まで遅延させると、LCPが確実に悪化します。

<!-- 重要な画像を先読みする -->
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

<!-- 外部ドメインへの接続を先に確立する -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

テキストが対象の場合

Webフォントの読み込み待ちで文字が表示されない状態が疑われます。font-displayで先に代替フォントを見せます。

@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap;      /* 先に代替フォントで表示する */
}

サーバー応答が遅い場合

  • TTFB(最初の1バイトまで)が0.8秒を超えていないか確認する
  • キャッシュを有効にする(WordPressならページキャッシュ)
  • プラグインを整理する。有効化しているだけで重いものがある
  • サーバーのプランやPHPバージョンを見直す

INP(操作への反応)を改善する

INP(操作への反応)を改善する

ボタンを押してから画面が反応するまでの時間です。原因はほぼJavaScriptの処理に集中します。

// 悪い例:クリック時に重い処理を同期実行する
button.addEventListener('click', () => {
  const result = heavyCalculation(largeArray);   // 数百ms占有する
  render(result);
});

// 良い例:先に画面を反応させ、重い処理を後ろへ回す
button.addEventListener('click', () => {
  showLoadingState();                 // 即座に反応を返す

  requestAnimationFrame(() => {
    setTimeout(() => {
      const result = heavyCalculation(largeArray);
      render(result);
    }, 0);
  });
});
原因症状対処
長いJavaScript処理押しても反応しない処理を分割・遅延させる
サードパーティタグ全体的にもたつく読み込みを遅延・削減
巨大なDOMスクロールが重い要素数を減らす・仮想化
過剰なイベント入力が遅れるdebounce・throttleを使う
// 入力のたびに処理せず、止まってから実行する
function debounce(fn, wait = 300) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), wait);
  };
}

searchInput.addEventListener('input', debounce((e) => {
  search(e.target.value);
}, 300));

広告やチャットツールなどのサードパーティスクリプトは、自分のコードより重いことが多いです。まず読み込んでいるタグを棚卸しし、本当に必要か判断してください。

CLS(レイアウトのずれ)を改善する

CLS(レイアウトのずれ)を改善する

読んでいる途中で文字や画像が動く現象です。3指標の中で最も直しやすく、効果もすぐ出ます。

<!-- 悪い例:サイズ未指定。読み込み後に高さが確定して下がずれる -->
<img src="/img/photo.jpg" alt="">

<!-- 良い例:幅と高さを属性で指定する -->
<img src="/img/photo.jpg" width="800" height="450" alt="">
/* CSS側で比率を固定しておく方法 */
.thumb {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

/* 後から差し込む領域は、あらかじめ高さを確保する */
.ad-slot {
  min-height: 280px;
}

/* Webフォントの切り替えでずれる場合は代替フォントを調整する */
@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%;      /* 代替フォントとの文字幅の差を補正 */
}
ずれの原因対処
画像のサイズ未指定widthheight属性を書く
広告・埋め込みの後読みmin-heightで場所を確保
Webフォントの切り替えfont-displaysize-adjust
後から挿入されるバナー既存要素の上に重ねる(押し下げない)
動的な一覧の差し込み読み込み中の高さを固定

CLSは数行の修正で0.25から0.05まで下がることも珍しくありません。着手コストが最も低いため、最初に取りかかる指標として適しています。

画像の最適化が最も効く理由

多くのサイトで、転送量の6〜8割を画像が占めます。ここを削るのがLCP改善の近道です。

  • 形式:WebPに変換する。JPEGより2〜3割軽くなる
  • 寸法:表示サイズの2倍以内に収める。4000px幅の写真をそのまま載せない
  • 容量:本文用は200KB以下、アイキャッチは300KB以下を目安に
  • 遅延:ファーストビュー以外はloading="lazy"
  • レスポンシブsrcsetで画面幅に応じた画像を配る
<img src="/img/photo-800.webp"
     srcset="/img/photo-400.webp 400w,
             /img/photo-800.webp 800w,
             /img/photo-1200.webp 1200w"
     sizes="(max-width: 768px) 100vw, 760px"
     width="800" height="450"
     alt="説明" loading="lazy">

スマホに1200px幅の画像を配るのは無駄です。srcsetsizesを書けば、ブラウザが最適な1枚を選びます。

WordPressでの具体的な設定

WordPressサイトでは、プラグインとテーマ側の設定で大半を対応できます。

対策手段効果の大きさ
ページキャッシュキャッシュ系プラグイン大(TTFB短縮)
WebP変換画像最適化プラグイン大(転送量削減)
不要プラグイン削除手動で棚卸し中〜大
CSS・JSの最適化最適化プラグイン中(要検証)
絵文字スクリプト削除functions.php
リビジョン削減wp-config.php小(DB軽量化)
<?php
// 使っていない絵文字スクリプトを止める
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );

// ファーストビューの画像を遅延読み込みの対象から外す
add_filter( 'wp_get_attachment_image_attributes', function ( $attr, $attachment, $size ) {
	if ( is_singular() && ! did_action( 'wp_body_open' ) ) {
		$attr['loading'] = 'eager';
		$attr['fetchpriority'] = 'high';
	}
	return $attr;
}, 10, 3 );
<?php
/** リビジョンを3件までに制限する */
define( 'WP_POST_REVISIONS', 3 );

/** 自動保存の間隔を延ばす */
define( 'AUTOSAVE_INTERVAL', 300 );

やりすぎると逆効果になる施策

スコアを上げようとして、かえって表示が壊れる例があります。次の4つは慎重に扱ってください。

施策リスク判断
CSS・JSの結合と圧縮レイアウト崩れ・機能停止1つずつ検証
すべての画像を遅延読込LCPが悪化するファーストビューは除外
JSの遅延実行(defer一括)動作順が壊れる依存関係を確認
最適化プラグインの多重導入設定が衝突する1つに絞る

特に最適化プラグインの併用は事故のもとです。同じ処理を2つのプラグインが行うと、圧縮済みのファイルをさらに圧縮して壊れることがあります。

スコアは目的ではありません。100点でも表示が崩れていれば失敗です。数値を上げる前に、実機で操作して問題がないかを必ず確認してください。

改善後の確認と継続的な監視

直したら終わりではありません。記事の追加やプラグイン更新で、簡単に元へ戻ります。

  • 月1回:Search Consoleの「ウェブに関する主な指標」で全体を確認
  • 公開前:新しいテンプレートを作ったらLighthouseで測る
  • プラグイン更新後:主要ページの表示を実機で確認
  • 四半期ごと:画像の総容量と、有効プラグイン数を棚卸し
# CLIで定点観測する(Lighthouse CI)
npx lighthouse https://example.com/ \
  --preset=desktop --output=json --output-path=./report.json --quiet

# 主要指標だけ取り出す
cat report.json | python3 -c "
import json,sys
d=json.load(sys.stdin)['audits']
for k in ['largest-contentful-paint','cumulative-layout-shift','total-blocking-time']:
    print(k, d[k]['displayValue'])"

優先順位のつけ方

優先順位のつけ方

限られた時間で最大の効果を出すための順序です。上から順に取りかかってください。

順位対策手間効果
1画像のサイズ指定(CLS)
2ファーストビュー画像の遅延解除
3画像のWebP化・リサイズ
4ページキャッシュの導入
5不要プラグインの削除
6サードパーティタグの整理
7CSS・JSの最適化中(要検証)

1と2は数行の修正で終わるのに効果が大きいため、必ず最初にやってください。7番は手間が大きく事故率も高いので、他を終えてから着手します。

ページ種別ごとの重点ポイント

どの指標が問題になりやすいかは、ページの性質によって変わります。全ページを同じように直す必要はありません。

ページ種別問題になりやすい指標重点対策
トップページLCP・CLSメインビジュアルの最適化
記事ページCLS・LCP本文中の画像と広告枠
一覧・アーカイブLCPサムネイルの枚数と遅延読込
問い合わせフォームINP入力時のJavaScript処理
検索結果ページINP絞り込みの再描画

改善の順番は流入の多いページからです。Search Consoleの検索パフォーマンスで上位ページを確認し、そこから着手すれば同じ工数で効果が大きくなります。

記事ページで特に効く3点

<!-- 1. 本文中の画像はすべて幅・高さを持たせる -->
<img src="/img/section.webp" width="1120" height="630" alt="説明" loading="lazy">

<!-- 2. 広告・埋め込み枠は先に高さを確保する -->
<div class="embed-slot" style="min-height:280px"></div>

<!-- 3. YouTubeはサムネイル置換で読み込みを遅らせる -->
<div class="yt-facade" data-id="VIDEO_ID">
  <img src="https://i.ytimg.com/vi/VIDEO_ID/hqdefault.jpg"
       width="480" height="360" alt="動画のサムネイル" loading="lazy">
</div>

YouTubeの埋め込みは1つで数百KBのスクリプトを読み込みます。クリックされるまでサムネイル画像で代替すると、LCPとINPの両方が改善します。

実際に測って直した例

典型的なWordPressメディアで、どの対策がどれだけ効いたかの目安です。数値は環境によって変わりますが、順序の参考になります。

対策LCPの変化CLSの変化作業時間
画像に幅・高さ指定変化なし0.28 → 0.0630分
FV画像のeager化4.1s → 3.2s変化なし10分
画像のWebP化3.2s → 2.6s変化なし1時間
ページキャッシュ導入2.6s → 1.9s変化なし30分
不要プラグイン5個削除1.9s → 1.7s変化なし2時間

注目すべきは最初の2つが40分で終わっている点です。CLSはほぼ解消し、LCPも1秒近く縮んでいます。着手のハードルが低い順に並べると、こうした結果になります。

測定の記録を残す

日付:2026-09-01
対象URL:https://example.com/article/
測定条件:Lighthouse モバイル / シークレットウィンドウ

対策前: LCP 4.1s / INP 240ms / CLS 0.28
実施内容:本文画像に width・height を追加(12枚)
対策後: LCP 4.0s / INP 240ms / CLS 0.06

所感:CLSは想定どおり改善。LCPは画像形式が原因のため次回対応。

1つ直すごとに測って記録すると、どの施策が効いたかが明確になります。まとめて直してから測ると、効果の切り分けができません。

チーム・クライアントへの説明

改善の必要性を伝えるとき、技術用語のままでは判断してもらえません。言い換えの例を挙げます。

指標技術的な説明伝わる言い換え
LCP最大コンテンツの描画時間ページが「見えた」と感じるまでの時間
INP次の描画までの相互作用ボタンを押してから反応するまでの待ち
CLS累積レイアウトシフト読んでいる途中で文字や画像がずれる現象

特にCLSは実際に体験してもらうのが早いです。スマホで自社サイトを開き、読もうとした瞬間に広告が入って位置がずれる様子を見せれば、説明は不要になります。

  • スコアの数値ではなく、離脱率や滞在時間と結びつけて説明する
  • 「検索順位が上がる」と断言しない。体験の改善が主目的
  • 作業時間と効果の一覧(前述の表)を示し、優先順位を合意する
  • 改善後は前後の数値を並べて共有する

サーバー応答(TTFB)を縮める

LCPの内訳を見ると、実は画像ではなくサーバーの応答待ちが大半を占めていることがあります。ここを縮めると全ページが一律に速くなります。

TTFBの目安と確認方法

TTFB評価とるべき対応
0.2秒以下良好対応不要
0.2〜0.8秒許容範囲キャッシュで改善余地
0.8〜1.8秒要改善キャッシュ必須・構成見直し
1.8秒超深刻サーバー移転を検討
# TTFBだけを測る
curl -o /dev/null -s -w "接続: %{time_connect}s  TTFB: %{time_starttransfer}s  合計: %{time_total}s\n" \
  https://example.com/

# 複数回測って平均を見る(初回はキャッシュ未生成で遅い)
for i in 1 2 3; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/
done

1回だけの測定では判断できません。3回以上測って2回目以降の値を見てください。初回はキャッシュが効いていないため、実態より遅く出ます。

WordPressでTTFBが伸びる主な原因

  • キャッシュ未導入:毎回PHPとデータベースで組み立てている
  • プラグインの過多:有効化しているだけで初期化処理が走る
  • データベースの肥大化:リビジョンや期限切れデータの蓄積
  • 外部APIの同期呼び出し:表示時に外部へ問い合わせている
  • PHPのバージョンが古い:8.x系は7.x系より明確に速い
<?php
/** 表示に時間がかかっているクエリを調べる(調査時のみ有効化) */
define( 'SAVEQUERIES', true );

/** 調査後は必ず false に戻す。負荷が増えるため */
<?php
// 遅いクエリを一時的にログへ出す(管理者のみ・調査用)
add_action( 'shutdown', function () {
	if ( ! defined( 'SAVEQUERIES' ) || ! SAVEQUERIES || ! current_user_can( 'manage_options' ) ) {
		return;
	}
	global $wpdb;
	foreach ( $wpdb->queries as $q ) {
		if ( $q[1] > 0.05 ) {   // 50ms超のクエリだけ記録
			error_log( sprintf( '[slow %.3fs] %s', $q[1], substr( $q[0], 0, 200 ) ) );
		}
	}
} );

この調査で、特定のプラグインが毎回重いクエリを投げていることが判明する場合があります。原因が絞れれば、代替プラグインへの差し替えという判断もできます。

キャッシュを入れるときの注意

対象キャッシュ理由
記事・固定ページする内容が変わらない
問い合わせフォーム除外するトークンが固定化する
カート・会員ページ除外する他人の情報が出る恐れ
管理画面除外する編集内容が反映されない
検索結果除外推奨組み合わせが無限にある

キャッシュ事故で最も重いのがログイン状態のページをキャッシュしてしまうケースです。他人の会員情報が別の訪問者に表示される可能性があるため、除外設定は必ず確認してください。


まとめ

Core Web Vitalsで見るのはLCP・INP・CLSの3つだけです。改善はラボデータで確認しながら進め、合否はフィールドデータで判断します。着手順は、画像へのwidthheight指定でCLSを潰し、ファーストビュー画像の遅延読み込みを解除してLCPを縮め、そのうえでWebP化とキャッシュを入れるのが最も効率的です。INPはJavaScriptの処理時間が原因なので、重い処理の分割とサードパーティタグの整理で対応します。スコアそのものを目的にせず、実機での表示と操作を必ず確認してください。

よくある質問(FAQ)

PageSpeed Insightsのスコアは何点あればいいですか?

スコアそのものは順位の評価対象ではありません。見るべきは3指標が「良好」に入っているかどうかで、LCP2.5秒以下・INP200ms以下・CLS0.1以下が基準です。スコアは目安として使い、判断は指標の実測値で行ってください。

修正したのに数値が変わりません。

Search Consoleに表示されるのは過去28日間の実訪問データのため、反映に時間がかかります。修正直後の確認はLighthouseなどのラボデータで行い、フィールドデータは4週間ほど待ってから判断してください。

FIDはもう見なくていいのですか?

2024年3月にINPへ置き換わり、指標から外れました。現在はINPを見てください。FIDは最初の操作だけを測る指標でしたが、INPはページ滞在中のすべての操作を評価するため、実際の体感に近い数値になります。

画像をすべて遅延読み込みにすればいいのでは?

逆効果になります。ファーストビューの画像を遅延させると、それがLCPの対象要素である場合に表示が明確に遅くなります。画面に最初から映る画像はloading="eager"fetchpriority="high"を指定し、下部の画像だけを遅延させてください。

最適化プラグインは何を入れればいいですか?

1つに絞ってください。複数入れると同じ処理が重複し、圧縮済みファイルをさらに処理して表示が壊れることがあります。まずキャッシュと画像最適化に対応した1つを入れ、設定を1項目ずつ有効化して表示を確認しながら進めるのが安全です。

あわせて読みたい関連記事

AIスキルで、未来の自分をアップデート!

今なら完全無料でAIを学べる!WithAI

今なら完全無料でAIを学べる!

  • 動画や実践で楽しく学べる:初心者でも安心のカリキュラム
  • スマホ・PCどちらでもOK:好きな時間に学習できる
  • 料金は一切ナシ0円でAIスキルが身につく

目的に合わせて選べる「AI副業」「AI転職」「AI活用」の3コースを用意。副収入・キャリアチェンジ・日常の生産性アップまで、あなたのゴールに合わせてAIを学べます。

会員登録はカンタン30秒で完了します。まずは公式LINEから、無料でAI学習をスタートしましょう!

この記事を書いた人

WithCodeでWeb制作を習得後、フリーランスエンジニアとして活動。HTML/CSS・JavaScript・WordPress案件を中心に年間20件以上の制作実績を持つ。「難しい技術をわかりやすく」をモットーに、初心者〜中級者向けの技術記事を執筆。副業・フリーランス独立を目指す方に向けた情報発信に注力している。

– service –WithGroupの運営サービス

  • WithCode
    - ウィズコード -

    スクール

    「未経験」から
    現場で通用する
    スキルを身に付けよう!

    詳細はこちら
  • WithFree
    - ウィズフリ -

    実案件サポート

    制作会社のサポート下で
    実務経験を積んでいこう!

    詳細はこちら
  • WithCareer
    - ウィズキャリ -

    就転職サポート

    大手エージェントのサポート下で
    キャリアアップを目指そう!

    詳細はこちら

公式サイト より
今すぐ
無料カウンセリング
予約!

目次