



WithCodeMedia-1-pc
WithCodeMedia-2-pc
WithCodeMedia-3-pc
WithCodeMedia-4-pc




WithCodeMedia-1-sp
WithCodeMedia-2-sp
WithCodeMedia-3-sp
WithCodeMedia-4-sp









生徒PageSpeed Insightsで測ったら赤い数字だらけでした…。どこから直せばいいですか?
ペン博士全部いっぺんに直そうとしないこと。LCP・INP・CLSの3つだけ見ればいい。しかも原因は毎回だいたい同じ場所にある。実測して、効く順に潰していこう。
Core Web Vitals(コアウェブバイタル)は、Googleが定めるページ体験の指標です。検索順位の要素のひとつであり、それ以上に離脱率へ直結します。
指標は3つだけです。表示の速さ(LCP)、操作への反応(INP)、レイアウトのずれ(CLS)。それぞれ原因になりやすい箇所が決まっているため、順番に潰せば確実に改善します。
この記事では、まず正しい測り方を示し、3指標それぞれの原因と対処、WordPressでの具体的な設定、改善後の確認方法まで解説します。

覚えるのはこの表だけです。数値の意味と、何が原因になりやすいかをセットで押さえます。
| 指標 | 測るもの | 良好 | 要改善 | 主な原因 |
|---|---|---|---|---|
| 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の回線と性能では問題が表面化せず、実際の利用環境と乖離します。

ページで最も大きな要素が表示されるまでの時間です。多くのサイトでは、ファーストビューの画像かテキストブロックが対象になります。
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; /* 先に代替フォントで表示する */
}
ボタンを押してから画面が反応するまでの時間です。原因はほぼ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));広告やチャットツールなどのサードパーティスクリプトは、自分のコードより重いことが多いです。まず読み込んでいるタグを棚卸しし、本当に必要か判断してください。

読んでいる途中で文字や画像が動く現象です。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%; /* 代替フォントとの文字幅の差を補正 */
}| ずれの原因 | 対処 |
|---|---|
| 画像のサイズ未指定 | width・height属性を書く |
| 広告・埋め込みの後読み | min-heightで場所を確保 |
| Webフォントの切り替え | font-displayとsize-adjust |
| 後から挿入されるバナー | 既存要素の上に重ねる(押し下げない) |
| 動的な一覧の差し込み | 読み込み中の高さを固定 |
CLSは数行の修正で0.25から0.05まで下がることも珍しくありません。着手コストが最も低いため、最初に取りかかる指標として適しています。
多くのサイトで、転送量の6〜8割を画像が占めます。ここを削るのがLCP改善の近道です。
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幅の画像を配るのは無駄です。srcsetとsizesを書けば、ブラウザが最適な1枚を選びます。
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点でも表示が崩れていれば失敗です。数値を上げる前に、実機で操作して問題がないかを必ず確認してください。
直したら終わりではありません。記事の追加やプラグイン更新で、簡単に元へ戻ります。
# 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 | サードパーティタグの整理 | 中 | 中 |
| 7 | CSS・JSの最適化 | 大 | 中(要検証) |
1と2は数行の修正で終わるのに効果が大きいため、必ず最初にやってください。7番は手間が大きく事故率も高いので、他を終えてから着手します。
どの指標が問題になりやすいかは、ページの性質によって変わります。全ページを同じように直す必要はありません。
| ページ種別 | 問題になりやすい指標 | 重点対策 |
|---|---|---|
| トップページ | LCP・CLS | メインビジュアルの最適化 |
| 記事ページ | CLS・LCP | 本文中の画像と広告枠 |
| 一覧・アーカイブ | LCP | サムネイルの枚数と遅延読込 |
| 問い合わせフォーム | INP | 入力時のJavaScript処理 |
| 検索結果ページ | INP | 絞り込みの再描画 |
改善の順番は流入の多いページからです。Search Consoleの検索パフォーマンスで上位ページを確認し、そこから着手すれば同じ工数で効果が大きくなります。
<!-- 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.06 | 30分 |
| 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は実際に体験してもらうのが早いです。スマホで自社サイトを開き、読もうとした瞬間に広告が入って位置がずれる様子を見せれば、説明は不要になります。
LCPの内訳を見ると、実は画像ではなくサーバーの応答待ちが大半を占めていることがあります。ここを縮めると全ページが一律に速くなります。
| 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/
done1回だけの測定では判断できません。3回以上測って2回目以降の値を見てください。初回はキャッシュが効いていないため、実態より遅く出ます。
<?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つだけです。改善はラボデータで確認しながら進め、合否はフィールドデータで判断します。着手順は、画像へのwidth・height指定でCLSを潰し、ファーストビュー画像の遅延読み込みを解除してLCPを縮め、そのうえでWebP化とキャッシュを入れるのが最も効率的です。INPはJavaScriptの処理時間が原因なので、重い処理の分割とサードパーティタグの整理で対応します。スコアそのものを目的にせず、実機での表示と操作を必ず確認してください。
スコアそのものは順位の評価対象ではありません。見るべきは3指標が「良好」に入っているかどうかで、LCP2.5秒以下・INP200ms以下・CLS0.1以下が基準です。スコアは目安として使い、判断は指標の実測値で行ってください。
Search Consoleに表示されるのは過去28日間の実訪問データのため、反映に時間がかかります。修正直後の確認はLighthouseなどのラボデータで行い、フィールドデータは4週間ほど待ってから判断してください。
2024年3月にINPへ置き換わり、指標から外れました。現在はINPを見てください。FIDは最初の操作だけを測る指標でしたが、INPはページ滞在中のすべての操作を評価するため、実際の体感に近い数値になります。
逆効果になります。ファーストビューの画像を遅延させると、それがLCPの対象要素である場合に表示が明確に遅くなります。画面に最初から映る画像はloading="eager"とfetchpriority="high"を指定し、下部の画像だけを遅延させてください。
1つに絞ってください。複数入れると同じ処理が重複し、圧縮済みファイルをさらに処理して表示が壊れることがあります。まずキャッシュと画像最適化に対応した1つを入れ、設定を1項目ずつ有効化して表示を確認しながら進めるのが安全です。

目的に合わせて選べる「AI副業」「AI転職」「AI活用」の3コースを用意。副収入・キャリアチェンジ・日常の生産性アップまで、あなたのゴールに合わせてAIを学べます。
会員登録はカンタン30秒で完了します。まずは公式LINEから、無料でAI学習をスタートしましょう!
WithCodeでWeb制作を習得後、フリーランスエンジニアとして活動。HTML/CSS・JavaScript・WordPress案件を中心に年間20件以上の制作実績を持つ。「難しい技術をわかりやすく」をモットーに、初心者〜中級者向けの技術記事を執筆。副業・フリーランス独立を目指す方に向けた情報発信に注力している。
公式サイト より
今すぐ
無料カウンセリング
を予約!