「PageSpeed Insightsで計測したら赤いスコアが並んでいてショック」「Googleサーチコンソールに『Core Web Vitals：不良』と出て慌てている」——そういう相談をよく受けます。

Core Web Vitalsは2021年にGoogleがランキング要因として正式採用して以来、SEOにおいて無視できない指標になりました。2026年現在も重要度は増すばかりで、特にモバイル検索での順位への影響が顕著になっています。

この記事では、3つの指標（LCP・INP・CLS）それぞれの意味・目標値・計測方法から、具体的な改善手順までを解説します。「なんとなくパフォーマンスが遅い」という漠然とした悩みを、数値で捉えて的確に直せるようになることがゴールです。

Core Web Vitalsとは何か：3つの指標を30秒で理解する

Core Web Vitalsは、ユーザー体験をユーザー視点で測るための3つの指標です。Googleが「このページは本当に使いやすいか」を判断するモノサシだと思ってください。

指標 何を測るか 良好の基準
LCP
Largest Contentful Paint		 ページの主要コンテンツが表示されるまでの時間 2.5秒以内
INP
Interaction to Next Paint		 ユーザー操作（クリック・タップ）への応答速度 200ms以内
CLS
Cumulative Layout Shift		 ページ読み込み中に要素がずれる量（レイアウトシフト） 0.1以下

INPは2024年3月に旧指標「FID（First Input Delay）」と入れ替わって正式採用されました。FIDはクリックへの最初の応答だけを測っていましたが、INPはページ滞在中のすべてのインタラクションを測るため、より実態に近い指標になっています。

まず現状を計測する：無料で使える3つのツール

改善の前に「今どこが悪いのか」を把握することが最優先です。感覚でコードをいじっても、スコアが上がらないどころか悪化することがあります。

① PageSpeed Insights（最速で全体像をつかむ）

PageSpeed InsightsにURLを入力するだけで、LCP・INP・CLSのスコアと改善候補が表示されます。モバイルとPCを切り替えて確認しましょう。モバイルスコアの方が一般的に低く出ます。

表示される「改善のヒント」は優先度順に並んでいるので、上から順番に対応するだけでも効果があります。ただし、診断結果はラボデータ（シミュレーション）とフィールドデータ（実際のユーザー計測）の2種類があり、SEOに直接影響するのはフィールドデータの方です。

② Chrome DevTools Lighthouse（詳細なデバッグに）

Chromeで対象ページを開き、DevTools（F12）の「Lighthouse」タブから計測できます。PageSpeed Insightsと同じエンジンですが、ローカルで動くので開発中のページも計測可能です。

特に「Performance」スコアの詳細タイムラインで、どの処理がボトルネックになっているかを可視化できるのが強みです。

③ Googleサーチコンソール（実ユーザーのデータを確認）

「ウェブに関するエクスペリエンス」メニューのCore Web Vitalsレポートで、実際のユーザーデータに基づく評価を確認できます。サイト全体でどのページが「不良」「改善が必要」「良好」なのかが一覧で見られるので、優先順位付けに最適です。

なお、自分のサイトを継続的に監視するなら、PagePulse（Web監視ツール）のようなツールで定期的なパフォーマンス計測を自動化すると、改善が退行していないかすぐに気づけます。

広告スペース

LCP（最大コンテンツの描画）を改善する

LCPが遅い原因のほとんどは、ヒーロー画像・OGP画像などの大きな画像の読み込みの遅さです。まずここを潰しましょう。

対策1：ヒーロー画像にfetchpriority="high"を付ける

ブラウザはデフォルトで画像の優先度を低く設定します。ファーストビューの主要画像にはfetchpriorityを明示的に指定することで、ダウンロードを最優先にできます。

<!-- Before -->
<img src="hero.jpg" alt="ヒーロー画像">

<!-- After -->
<img src="hero.jpg" alt="ヒーロー画像"
     fetchpriority="high"
     loading="eager">

逆に、スクロールしないと見えない画像にはloading="lazy"を付けて後回しにします。この2つを使い分けるだけで、LCPが0.3〜0.8秒改善することが多いです。

対策2：画像フォーマットをWebPまたはAVIFに変換する

JPEGと比べてWebPは約25〜35%、AVIFは約50%ファイルサイズが小さくなります。2026年現在、AVIFは主要ブラウザの97%以上がサポートしているので、積極的に採用できます。

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="ヒーロー画像" fetchpriority="high">
</picture>

Cloudflare Imagesやsharp（Node.jsライブラリ）を使えばビルド時に自動変換できます。

対策3：サーバーのTTFB（最初のバイトが届くまでの時間）を短縮する

LCPが遅い場合、画像ではなくサーバーのレスポンス自体が遅いケースもあります。Googleの推奨はTTFB 800ms以内。Cloudflare PagesやVercelのようなCDNベースのホスティングに移行するだけで、日本からのTTFBが劇的に改善します。

対策4：レンダリングブロッキングリソースを排除する

headタグ内に<script src="...">があると、そのJSが読み込まれるまでページの描画が止まります。

<!-- NG：レンダリングがブロックされる -->
<script src="analytics.js"></script>

<!-- OK：非同期読み込み -->
<script src="analytics.js" defer></script>
<script src="widget.js" async></script>

Google Analyticsなどのサードパーティスクリプトはほぼすべてdeferまたはasyncで問題ありません。

INP（次の描画への応答時間）を改善する

INPは旧FIDより格段に厳しい指標です。FIDが「最初のクリックへの応答」だけを測っていたのに対し、INPはページを開いている間のすべてのクリック・タップ・キー入力の応答時間の最悪値を測ります。

200ms以内というのは人間が「遅い」と感じない閾値。JavaScriptが重いSPAほどINPが問題になりやすいです。

対策1：長いJavaScriptタスクを分割する

メインスレッドで50ms超のタスクが走ると、その間ユーザーのインタラクションへの応答がブロックされます。これを「Long Task」と呼び、INP悪化の主犯です。

// Before：重い処理をブロッキングで実行
function processItems(items) {
  items.forEach(item => heavyProcess(item));
}

// After：小分けにしてメインスレッドを解放
async function processItems(items) {
  for (const item of items) {
    heavyProcess(item);
    // ブラウザに制御を返す
    await scheduler.yield();
  }
}

scheduler.yield()は2024年から主要ブラウザでサポートされた新しいAPIで、Long Taskを自然に分割できます。

対策2：イベントハンドラを軽量に保つ

クリックイベントで大量の処理を同期実行するのはNGです。UIの更新だけを即座に行い、重い処理はrequestAnimationFrameやWeb Workerに逃がしましょう。

button.addEventListener('click', () => {
  // 即座にUI更新（ユーザーに反応を見せる）
  button.textContent = '処理中...';
  button.disabled = true;

  // 重い処理は非同期に
  requestIdleCallback(() => {
    heavyDataProcessing();
    button.textContent = '完了';
    button.disabled = false;
  });
});

対策3：ReactなどのSPAではトランジションAPIを活用する

React 18以降のuseTransitionやstartTransitionを使うと、状態更新の優先度を下げてINPを改善できます。フィルタリングや検索など「結果がすぐに出なくても良い」処理に適しています。

import { useTransition } from 'react';

function SearchResults() {
  const [isPending, startTransition] = useTransition();
  const [results, setResults] = useState([]);

  const handleSearch = (query) => {
    startTransition(() => {
      setResults(filterItems(query)); // 優先度を下げて実行
    });
  };

  return (
    <>
      <input onChange={e => handleSearch(e.target.value)} />
      {isPending ? <Spinner /> : <ResultList items={results} />}
    </>
  );
}
広告スペース

CLS（累積レイアウトシフト）を改善する

CLSは「ページを読んでいたら広告が突然現れてコンテンツが下にズレた」という体験を数値化したものです。0.1以下が良好で、0.25以上は「不良」判定です。

CLSの原因は決まっていることが多く、対策もシンプルです。

対策1：画像・動画にwidth/heightを必ず指定する

サイズ未指定の画像は、読み込まれた瞬間にレイアウトを押し広げます。これが最もよくあるCLSの原因です。

<!-- NG：サイズ未指定 -->
<img src="photo.jpg" alt="写真">

<!-- OK：実際の比率で指定（CSSでレスポンシブにしてもOK） -->
<img src="photo.jpg" alt="写真" width="800" height="450">

CSSでaspect-ratioを使う方法も有効です：

img {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

対策2：広告・埋め込みコンテンツのスペースを事前に確保する

AdSenseなどの広告は読み込み後に展開してレイアウトをズラす典型例です。広告が入るエリアに最小高さを確保しておきましょう。

.ad-container {
  min-height: 250px; /* 広告の最大高さに合わせる */
  display: flex;
  align-items: center;
  justify-content: center;
}

対策3：Webフォントの読み込みを最適化する

Webフォントが読み込まれた際にテキストがリフローするのもCLSの原因です。font-display: optionalかfont-display: swapを使い、<link rel="preconnect">でフォントのドメインへの接続を事前に確立します。

<!-- headタグ内に追加 -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
/* font-display: swap でFOUT（テキストのちらつき）を最小化 */
@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap;
}

対策4：動的に挿入されるコンテンツはDOM上部に追加しない

バナーやクッキー同意バーなどを画面上部に動的挿入すると、既存コンテンツが押し下げられてCLSが悪化します。代わりにposition: fixedやposition: stickyを使うか、ページ最下部に配置しましょう。

改善後の継続監視が重要な理由

Core Web Vitalsは「一度直したら終わり」ではありません。サードパーティスクリプトの更新、新しい機能追加、CMSのアップデートなど、あらゆる変更がスコアに影響します。

実際、僕の経験ではGoogle AnalyticsのバージョンアップでINPが突然50ms悪化したことがありました。定期的な計測がなければ気づけなかったケースです。

継続監視のためのアプローチは3つあります：

  • Googleサーチコンソール — フィールドデータを週1回確認するルーティンを作る
  • CI/CDへの組み込み — GitHub ActionsでLighthouseを自動実行し、スコアが閾値を下回ったらビルド失敗にする
  • 外形監視ツール — PagePulseのようなWeb監視ツールでパフォーマンス異常を検知し、Slackなどへ通知する

特に複数のサービスを運営している個人開発者には、外形監視との組み合わせがおすすめです。何かがおかしくなったときに自分で気づく前に通知が来る体制を作っておくと、問題が大きくなる前に対処できます。

Core Web Vitals改善の優先順位付け：どこから手をつけるか

3つの指標を同時に改善しようとすると、どこから手をつけるか迷います。以下の優先順位を参考にしてください。

  1. まずCLSを0.1以下に — 対策が明確で、比較的短時間で改善できます。画像サイズ指定と広告スペース確保だけで解決することが多い。
  2. 次にLCPを2.5秒以内に — ヒーロー画像の最適化とfetchpriority指定が最大の効果。Cloudflare PagesやVercelへの移行でTTFBも改善。
  3. 最後にINPを200ms以内に — Long Taskの特定にChrome DevToolsのPerformanceパネルが必要。最も技術的な難易度が高い。

ただし、PageSpeed Insightsの「改善のヒント」が特定の項目を強調している場合は、そちらを優先してください。LCPが極端に遅い場合はLCPから始めるのが正解です。

よくある勘違いと落とし穴

「ラボスコアが100点なのにサーチコンソールが不良」

Lighthouseのラボデータは高性能なデスクトップPC・高速回線でのシミュレーションです。フィールドデータは低スペックのスマートフォン・3G回線を使う実ユーザーのデータを含むため、乖離が生じます。SEOに影響するのはフィールドデータなので、ラボスコアが良くても油断は禁物です。

「画像を全部lazy loadにした」

ファーストビューの画像（LCP要素になりうる画像）にlazy loadを設定すると、LCPが悪化します。loading="lazy"はスクロールしないと見えない画像にのみ使用してください。

「JavaScriptを全部deferにした」

deferはHTMLパース完了後に実行されるため、DOMが必要なスクリプトには安全です。ただし、document.write()を使うレガシーなサードパーティスクリプトはdeferで壊れることがあります。変更後は必ず動作確認を。

広告スペース

まとめ：Core Web Vitals改善のチェックリスト

Core Web Vitalsの改善は、ユーザー体験の改善であり、SEO順位の改善でもあります。以下のチェックリストで現状を確認してみてください。

LCP改善チェックリスト

  • ☐ ヒーロー画像にfetchpriority="high"を設定した
  • ☐ スクロール不要な画像はlazyを外した
  • ☐ 画像をWebPまたはAVIFに変換した
  • ☐ headタグのscriptをdefer/asyncにした
  • ☐ CDN（Cloudflare Pages / Vercel）でTTFBを改善した

INP改善チェックリスト

  • ☐ Chrome DevToolsでLong Taskを特定した
  • ☐ クリックハンドラを軽量化し、重い処理を非同期に移した
  • ☐ scheduler.yield()またはsetTimeout(0)でタスクを分割した
  • ☐ ReactならstartTransitionで状態更新の優先度を制御した

CLS改善チェックリスト

  • ☐ 全画像・動画にwidth/heightを指定した
  • ☐ 広告エリアにmin-heightで最小スペースを確保した
  • ☐ Webフォントにfont-display: swapを設定した
  • ☐ 動的コンテンツをページ上部に挿入しない設計にした

一度にすべてを直す必要はありません。サーチコンソールで最も「不良」ページが多い指標から1つずつ対応していきましょう。地道な改善の積み重ねが、検索順位と直帰率の改善につながります。

🔍 サイトのパフォーマンスを継続監視するなら

Core Web Vitalsの改善が退行していないか定期的に監視することが大切です。PagePulse（Web監視ツール）を使えば、サイトのパフォーマンス異常を自動検知して通知できます。複数サイトをまとめて管理したい場合は、StatusCraft（ステータスページ）との併用もおすすめです。

また、ページ内容を素早く把握したい場合はQuickSummary（AI要約Chrome拡張）を使えば、長いテクニカルドキュメントの要点をすぐに掴めます。

広告スペース