【2026年版】Core Web Vitals 実務（LCP/FID→INP/CLS）：テンプレと優先順位

結論

Core Web Vitals（コアウェブバイタル）は、Googleがページ体験を測る3つの指標です。2024年3月、FID（First Input Delay）はINP（Interaction to Next Paint）に正式に置き換えられました。

2026年現在、評価基準はLCP ≦ 2.5秒、INP < 200ミリ秒、CLS ≦ 0.1（いずれも75パーセンタイル＝全訪問の75%が基準内）です。

改善の順序は「Search Consoleで問題を発見→ PageSpeed Insights / Lighthouse（ラボデータ）で原因を特定」が基本です。

優先順位は「影響範囲（アクセス数・ページタイプ）× 改善コスト（工数・リスク）」のバランスで決めます。
この記事では、実務で使える診断フロー・改善チェックリスト・プラットフォーム別の現実解を、初心者でも実装できる粒度で解説します。

2026年版SEO対策の基礎はこちらをご覧ください。

【2026年版】SEO対策とは？基本・始め方・手順を完全ガイド

Core Web Vitalsとは（2026年の前提）
計測の基本：フィールドとラボの使い分け
優先順位の決め方（決定フロー）
LCP 改善テンプレ（順番にやるだけ）
INP 改善テンプレ（2026年版）
CLS 改善テンプレ（定番で確実）
- 主な原因と対策
プラットフォーム別の現実解（例）
改善の運用：検証→リリース→再計測

Core Web Vitalsとは（2026年の前提）

Core Web Vitalsは、実際のユーザー体験を数値化した3つの指標です。
Googleはこれらを「ページエクスペリエンスシグナル」の一部として検索ランキングに利用していますが、1指標だけで順位が決まるわけではありません。
コンテンツの質や関連性が最も重要であり、Core Web Vitalsは「同等の品質なら体験が良いページを優先する」補助的な要素です。

各指標の意味と基準

LCP（Largest Contentful Paint / 最大コンテンツの描画）

何を測るか：ページが読み込まれてから、メインコンテンツ（画像・見出し・動画など）が画面に表示されるまでの時間。
基準：2.5秒以内が「良好」、2.5～4.0秒が「改善が必要」、4.0秒超が「不良」。

INP（Interaction to Next Paint / 操作から次の描画まで）

何を測るか：ユーザーがクリック・タップ・キー入力したとき、ブラウザが反応して画面を更新するまでの時間。ページ訪問中のすべての操作のうち最も遅いもの（または98パーセンタイル）を評価。
基準：200ミリ秒未満が「良好」、200～500ミリ秒が「改善が必要」、500ミリ秒超が「不良」。

CLS（Cumulative Layout Shift / 累積レイアウト変更）

何を測るか：ページ読み込み中に、コンテンツが意図せず移動した量の合計。画像や広告が後から挿入されて文章がズレる現象を数値化。
基準：0.1以下が「良好」、0.1～0.25が「改善が必要」、0.25超が「不良」。

75パーセンタイルとは

Googleは「そのページを訪問したユーザーの75%が基準を満たしているか」で判定します。
つまり、100人が訪れたとき75人目に速い（または小さい）数値が評価対象です。
一部の遅い環境だけを改善しても効果は薄く、全体の分布を底上げする必要があります。

サイト全体の評価

Search Consoleの「ウェブに関する主な指標」レポートでは、URLグループごとに3指標のうち最も悪い結果が判定に反映されます。

例えば、LCPとINPが良好でもCLSが不良なら、そのグループは「不良」と表示されます。モバイルとPCは別々に集計され、Googleはモバイルを優先します。

計測の基本：フィールドとラボの使い分け

Core Web Vitalsを改善するには、2種類のデータを正しく使い分ける必要があります。

フィールドデータ（実ユーザーの計測）

どこで見るか
Search Console「ウェブに関する主な指標」、Chrome User Experience Report（CrUX）、PageSpeed InsightsのCrUX欄。
何が分かるか
実際の訪問者が体験した速度（過去28日間の集計）。検索ランキングに影響するのはこちら。
メリット
デバイス・ネットワーク・キャッシュ状態など現実の多様性が反映される。
デメリット
原因は分からない。数値が更新されるまで28日かかる。

ラボデータ（再現テスト）

どこで見るか
PageSpeed Insights、Lighthouse（Chrome DevTools）。
何が分かるか
固定環境（エミュレートされた低速回線・モバイル端末）での再現スコア。改善ポイントが「Diagnostics（診断）」や「Opportunities（改善案）」に表示される。
メリット
何度でも実行でき、コード変更前後の比較が即座にできる。
デメリット
実際のユーザー環境とは異なるため、数値がフィールドとズレることがある。

数値がズレる理由

ネットワーク速度
ラボは4G相当だが、実ユーザーには5Gや遅い3Gも混在。
端末性能
ラボはミドルレンジを想定。実環境は低スペックスマホ～ハイエンドPCまで幅広い。
キャッシュ
ラボは初回訪問を模擬。リピーターはリソースがキャッシュ済みで高速。
サンプル期間
フィールドは28日間の累積。ラボは実行時点のスナップショット。

診断の流れ

Search Consoleで「不良」「改善が必要」のURLグループを発見（フィールド）。
代表的なページをPageSpeed Insightsで分析（ラボ）し、ボトルネックを特定。
修正後、再度ラボで検証してから本番公開。
28日後にSearch Consoleで効果を確認（フィールド）。

優先順位の決め方（決定フロー）

すべてのページを一度に改善するのは現実的ではありません。
以下の4ステップで、効率よく成果を出す順番を決めます。

ステップ1：Search Consoleで問題URLを抽出

「ウェブに関する主な指標」レポートを開く。
「不良」または「改善が必要」と表示されたURLグループをクリック。
モバイル優先（Googleはモバイルファーストインデックス）。
PCは影響が少なければ後回しでもOK。

ステップ2：ページタイプ × 指標で分類

抽出したURLを、以下の軸で整理します。

ページタイプ：トップページ／記事詳細／カテゴリ一覧／商品ページ／フォームなど。
不良指標：LCP / INP / CLS のどれが基準超過か。
アクセス数：Googleアナリティクスや Search Console「検索パフォーマンス」でページビュー・クリック数を確認。

ステップ3：コストと効果で優先順位付け

項目	高優先度	中優先度	低優先度
アクセス数	トップ・主力記事・コンバージョンページ	中堅記事・サブカテゴリ	アーカイブ・古い記事
改善コスト	画像最適化・CSS調整（HTML/CSSのみ）	JSライブラリ更新・遅延読み込み実装	フレームワーク刷新・サーバ移行
体感への影響	LCP（読み込み第一印象）> INP（操作性）> CLS（視覚的不快感）	指標は並列だが、ユーザーが最初に感じる不満を優先	-

判定の目安
→ 低コスト × 高アクセス × LCP/INP → 最優先
→ 中コスト × 主力ページ → 次点
→ 高コスト × 低アクセス → 後回し

ステップ4：28日サイクルで再評価

修正をリリース。
28日後に Search Console を確認（CrUXは28日間の移動平均）。
「不良」→「改善が必要」→「良好」に移行したか確認。
効果が薄ければ、PageSpeed Insights で再診断し別の原因を探す。

LCP 改善テンプレ（順番にやるだけ）

LCPは「ページのメインコンテンツがいつ表示されるか」を測ります。
多くの場合、ヒーロー画像（ファーストビューの大きな画像）または見出しブロックがLCP要素です。

LCP要素の特定方法

PageSpeed Insights で「Largest Contentful Paint element」を確認。
Chrome DevTools：Performance パネルで記録 → Timings 欄の「LCP」をクリック → 該当要素がハイライトされる。

ボトルネックの分類

LCPは、以下の3段階に分解できます。

TTFB（Time to First Byte / 最初の1バイト到達時間）
サーバがHTMLを返し始めるまで。
リソース読み込み時間
画像・CSS・フォントのダウンロード。
レンダリング時間
ブラウザが要素を描画・配置するまで。

PageSpeed Insights の「LCP breakdown」で、どこに時間がかかっているか確認してください。

改善チェックリスト（上から順に実施）

1. 画像の最適化

問題
LCP要素が画像の場合、ファイルサイズが大きいと読み込みが遅い。

対策

適切なサイズにリサイズ：表示幅が800pxなら、元画像も800px前後に。
次世代フォーマット：WebP（非対応ブラウザ向けにJPEG/PNGをフォールバック）。
srcset と sizes 属性：デバイス幅に応じて最適なサイズを配信。

Copy

<img 
  src="hero-800.webp" 
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="メインビジュアル"
  width="1200" 
  height="600"
/>

補足
width と height を指定するとCLS対策にもなります。

2. LCP要素のプリロード（preload）

問題
ブラウザはHTMLを解析して初めて画像やフォントの存在を知るため、ダウンロード開始が遅れる。

対策
<link rel="preload"> で、HTMLの <head> 内に優先度を明示。

Copy

<link rel="preload" as="image" href="hero-800.webp" type="image/webp" />
<link rel="preload" as="font" href="/fonts/main-bold.woff2" type="font/woff2" crossorigin />

注意
プリロードは本当に必要なリソース（ヒーロー画像・メインフォント）だけに。過剰に指定すると逆効果。

3. クリティカルCSSのインライン化／未使用CSSの削減

問題
外部CSSファイルの読み込み待ちで、レンダリングがブロックされる。

対策

ファーストビュー用CSSをHTMLに直接埋め込む（インライン化）。残りは <link rel="stylesheet" media="print" onload="this.media='all'"> で遅延。
未使用CSS削除：PurgeCSSなどのツールで不要なスタイルを除去。

Copy

<style>
  /* ファーストビューのスタイルだけ */
  .hero { font-size: 2rem; background: #000; }
</style>
<link rel="preload" as="style" href="main.css" onload="this.rel='stylesheet'" />

4. ブロッキングJavaScriptの削減

問題<script> タグが <head> にあると、HTMLのパース（解析）が止まる。

対策

defer 属性：HTMLパース後に実行（推奨）。
async 属性：ダウンロード完了次第すぐ実行（順序が不定なので依存関係に注意）。
不要なスクリプトを削除：使っていない計測タグ・プラグインを整理。

Copy

<script src="app.js" defer></script>

5. サーバ応答時間（TTFB）の短縮

問題
サーバの処理が遅い、データベースクエリが重い、回線が遠い。

対策

CDN（コンテンツ配信ネットワーク）：ユーザーに近いサーバからHTMLを配信。
HTMLキャッシュ：動的生成（PHP/Pythonなど）を毎回実行せず、静的HTMLを保存。
ストリーミングSSR：HTMLを分割送信し、最初の部分を早く表示（Next.js、Remixなど）。
データベース最適化：インデックス追加、N+1クエリ削減。

INP 改善テンプレ（2026年版）

INP（Interaction to Next Paint）は、ユーザーがクリック・タップ・キー入力してから、画面が応答するまでの遅延を測ります。
2024年3月にFIDを正式に置き換え、2026年現在のCore Web Vitalsの柱です。

症状と原因

症状
ボタンを押しても反応が遅い、入力フォームの文字が遅れて表示される、メニューが開くまで待たされる。
原因
メインスレッド（ブラウザのUI処理担当）が、重いJavaScript処理で占有されている。

診断手順

PageSpeed Insights の「Minimize main-thread work」「Avoid long main-thread tasks」を確認。
Chrome DevTools → Performance パネル：録画中にクリック操作 → 50ミリ秒を超える「Long Task」（赤い三角マーク）を探す。
どのスクリプトが重いか：タスクをクリック → Bottom-Up / Call Tree で関数名・ファイル名を特定。

改善チェックリスト（上から順に実施）

1. 長いタスクを分割する

問題
50ミリ秒を超えるJavaScript処理は、ブラウザが他の操作を受け付けなくなる（ロングタスク）。

対策

コード分割（Code Splitting）：アプリ全体を1ファイルにせず、ページ・機能ごとに分ける（Webpack、Viteなど）。
scheduler.yield() / scheduler.postTask()：長いループの途中で制御を譲る（Chromeの新API）。
requestIdleCallback：緊急でない処理をアイドル時間に回す。

Copy

// 悪い例：5000件を一気に処理
for (let i = 0; i < 5000; i++) {
  processItem(i);
}

// 良い例：100件ずつ分割
async function processBatch() {
  for (let i = 0; i < 5000; i += 100) {
    for (let j = i; j < i + 100 && j < 5000; j++) {
      processItem(j);
    }
    await scheduler.yield(); // 他の処理に譲る
  }
}

2. メインスレッドを解放する

対策

Web Worker：重い計算（データ集計・画像処理）を別スレッドで実行。UIスレッドは操作受付に専念。
不要なJavaScript削除：使っていないライブラリ・プラグインをアンインストール。
サードパーティスクリプト抑制：広告・SNSウィジェット・チャットツールは遅延読み込み（IntersectionObserver でビューポートに入ったら実行）。

Copy

// Web Worker例
// worker.js
self.onmessage = (e) => {
  const result = heavyCalculation(e.data);
  self.postMessage(result);
};

// main.js
const worker = new Worker('worker.js');
worker.postMessage(data);
worker.onmessage = (e) => {
  console.log('結果:', e.data);
};

3. イベントハンドラの最適化

問題
スクロール・リサイズ・入力イベントは頻繁に発火し、処理が追いつかない。

対策

パッシブリスナー：{ passive: true } でブラウザのスクロール処理をブロックしない。
デバウンス（debounce）：連続イベントの最後だけ実行（検索サジェストなど）。
スロットル（throttle）：一定間隔ごとに実行（スクロールアニメーションなど）。

Copy

// デバウンス例（入力が止まって300ms後に実行）
let timer;
input.addEventListener('input', () => {
  clearTimeout(timer);
  timer = setTimeout(() => {
    fetchSuggestions(input.value);
  }, 300);
});

4. UI応答の即時フィードバック

問題
実際の処理が重くても、ユーザーは「反応した」と感じればストレスが減る。

対策

ローディングスピナー / スケルトンスクリーンをクリック直後に表示。
楽観的UI更新：サーバ応答前に画面を先に更新（失敗時はロールバック）。

Copy

button.addEventListener('click', async () => {
  button.disabled = true;
  spinner.style.display = 'block'; // すぐ表示
  await heavyTask();
  spinner.style.display = 'none';
  button.disabled = false;
});

5. フレームワーク特有の対策

React / Vue / Angularなど

SSR（サーバサイドレンダリング）：初回HTMLをサーバで生成し、クライアントJSを減らす。
部分ハイドレーション：インタラクティブな部分だけJavaScriptを有効化（Astro、Qwikなど）。
遅延マウント：ファーストビュー外のコンポーネントは後から初期化。

CLS 改善テンプレ（定番で確実）

CLS（Cumulative Layout Shift）は、ページ読み込み中にコンテンツが意図せず移動する現象を測ります。
画像や広告が後から挿入され、読んでいた文章がズレると、ユーザーは誤タップやストレスを感じます。

主な原因と対策

1. 画像・動画・iframeのサイズ予約

問題
画像がダウンロードされるまで高さが0pxで、読み込み後に縦方向に押し広げる。

対策

width と height 属性を必ず指定（ブラウザが読み込み前にスペースを確保）。
CSS aspect-ratio：レスポンシブ対応。

Copy

<img src="photo.jpg" width="800" height="600" alt="写真" />

<style>
  img {
    width: 100%;
    height: auto;
    aspect-ratio: 4 / 3; /* width/heightの比率 */
  }
</style>

2. フォントのFOUT/FOIT対策

問題
Webフォント読み込み中に文字が見えない（FOIT）、または代替フォントで表示後に置き換わる（FOUT）。行の高さが変わるとレイアウトがズレる。

対策

<link rel="preload"> でフォントを先読み。
font-display: swap：代替フォント表示を優先（読み込み後に置き換え）。
font-display: optional：初回訪問では代替フォント、2回目以降でWebフォント（最もCLS安全だが、デザイン妥協が必要）。

Copy

<link rel="preload" as="font" href="/fonts/main.woff2" type="font/woff2" crossorigin />

<style>
  @font-face {
    font-family: 'MainFont';
    src: url('/fonts/main.woff2') format('woff2');
    font-display: swap;
  }
</style>

3. 広告・埋め込みコンテンツのスペース確保

問題
Google AdSense、YouTube埋め込み、SNSウィジェットは、読み込み後にサイズが決まる。

対策

最小高さを事前に設定：min-height でプレースホルダー領域を確保。
aspect-ratio でボックス予約（YouTubeは16:9が標準）。

Copy

<div class="ad-container" style="min-height: 250px;">
  <!-- AdSenseコード -->
</div>

<div class="video-wrapper" style="aspect-ratio: 16 / 9;">
  <iframe src="https://www.youtube.com/embed/..." ...></iframe>
</div>

4. レイアウト変更にはtransformを使う

問題top、left、width、height をJavaScriptで変更すると、レイアウト再計算が発生しCLSに影響。

対策

transform と opacity を使う（GPU処理で再レイアウトなし）。

Copy

/* 悪い例 */
.menu { left: -300px; }
.menu.open { left: 0; } /* CLSに影響 */

/* 良い例 */
.menu { transform: translateX(-300px); }
.menu.open { transform: translateX(0); } /* CLS影響なし */

5. 遅延読み込み要素のプレースホルダー

問題loading="lazy" や IntersectionObserver で遅延読み込みする画像・コンテンツは、スクロール中に突然挿入される。

対策

スケルトン（骨組み）UIを表示：グレーのボックスで読み込み中を示す。
高さを事前確保：min-height またはダミー要素。

Copy

<div class="image-placeholder" style="min-height: 400px; background: #eee;">
  <img src="photo.jpg" loading="lazy" onload="this.parentElement.style.minHeight='auto'" />
</div>

プラットフォーム別の現実解（例）

実際のサイト運営では、プラットフォームや構成によって対策の優先度が変わります。代表的なケースを紹介します。

WordPress / ブログ / CMS

よくある問題

テーマやプラグインが画像に width/height を付けない。
目次・関連記事ウィジェットがJavaScript生成で挿入される。
Google AdSenseが記事中に自動挿入され、CLSを悪化させる。

対策

画像の自動サイズ指定：WordPress 5.5以降は自動付与。古いテーマは functions.php で強制追加。
プラグイン整理：使っていない機能を削除（SNSシェアボタン・スライダーなど）。
広告の固定スペース：AdSense data-ad-format="fixed" で高さを固定、または min-height 指定。
目次はSSR：JavaScriptで生成せず、サーバ側またはビルド時に埋め込む。

SPA（Single Page Application）/ React / Vue

よくある問題

初回読み込みのJavaScriptが巨大で、LCP・INPが遅い。
クライアントレンダリングでHTMLが空なので、LCP要素が遅れる。

対策

コード分割（Route-based splitting）：ページごとにJSファイルを分け、必要な分だけ読み込む。
SSR / SSG（Static Site Generation）：Next.js、Nuxt.js、SvelteKitでHTMLを事前生成。
遅延ハイドレーション：初回は静的HTML表示、インタラクションが必要になった時点でJSを起動（@builder.io/qwik、Astro Islandsなど）。
初期バンドルサイズ削減：Tree-shaking、dynamic import、不要ライブラリの削除。

CDN / 静的サイトホスティング

よくある問題

HTMLはCDNで配信しても、画像・フォントが遠いサーバにある。
キャッシュ設定が不適切で、毎回ダウンロードが発生。

対策

画像もCDNに配置：Cloudflare Images、Cloudinary、Imgixなど自動最適化サービス。
フォントのCDN配信：Google Fontsはそのまま使うより、ダウンロードして自社CDNに置く方が速い（プリロードしやすい）。
キャッシュヘッダー設定：
HTML：Cache-Control: public, max-age=0, must-revalidate（常に最新確認）
画像・CSS・JS（ハッシュ付き）：max-age=31536000, immutable（1年キャッシュ）

改善の運用：検証→リリース→再計測

Core Web Vitalsの改善は、PDCAサイクルで継続します。
一度直して終わりではなく、新機能追加・デザイン変更のたびに再検証が必要です。

基本フロー

ステージング環境でPageSpeed Insights / Lighthouse実行
本番公開前に、変更がスコアに与える影響を確認。
スコアが下がっていれば原因を探す。
本番公開
小規模な変更なら全ページ一斉でOK。
大規模リニューアルはA/Bテストや段階リリース推奨。
28日後にSearch Consoleで評価
CrUXは28日間の移動平均。
リリース直後は反映されないため、1か月待つ。
「ウェブに関する主な指標」で
「不良」→「改善が必要」→「良好」への移行を確認。

効果測定とフィードバック

改善したURLグループの数、平均LCP/INP/CLSの推移をスプレッドシートで記録。
ランキング・トラフィックへの影響をGoogleアナリティクスで分析
（Core Web Vitalsだけで順位が上がるわけではないが、相関は見える）。

よくある失敗例と回避策

失敗例1：広告挿入でCLSが悪化

状況：収益化のため記事中にAdSenseを追加 → CLSが0.05から0.3に急増。

原因：広告の高さを予約せず、読み込み後にコンテンツが押し下げられた。

回避策：広告枠に min-height: 250px（または実測の平均高さ）を設定。空白が残る場合は、後続コンテンツでカバー。

失敗例2：lazy loadingを全画像に適用してLCP悪化

状況：すべての画像に loading="lazy" を付けた → LCPが3秒から5秒に。

原因：ファーストビューのヒーロー画像まで遅延され、ユーザーが画面をスクロールするまで読み込まれなかった。

回避策：ファーストビュー画像には loading="lazy" を付けない。2枚目以降のみ遅延。

失敗例3：サードパーティスクリプトでINP悪化

状況：新しいチャットツールを導入 → INPが150msから400msに。

原因：チャットウィジェットの初期化が50msを超えるロングタスクを生成。

回避策：IntersectionObserver でページ下部にスクロールしたら読み込む、または「チャットを開く」ボタンクリック時に初期化。

モニタリングのベストプラクティス

定期レポート作成
月1回、Search Consoleのデータをエクスポートし、前月比を確認。
アラート設定
主要ページのスコアが閾値を下回ったら通知（PageSpeed Insights API + Slack/Emailなど）。
RUM（Real User Monitoring）導入
web-vitals.jsライブラリでJavaScriptから実測値を収集し、Googleアナリティクス・独自ログに送信。CrUXより細かい分析が可能。

Copy

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);
// → 各指標の値をGA4にイベント送信

Core Web Vitals改善の前後で必要な対策はこちら

下記記事で改善の前後に必要な作業や確認事項をご紹介しています。

インデックス未登録の原因別対処法
せっかく高速化しても、Googleにインデックスされていなければ意味がない。Search Console「ページがインデックスに登録されなかった理由」の読み解き方
代替ページ（適切なcanonicalタグあり）の対処方法
重複コンテンツとcanonical設定ミスを解消し、評価を集約
パンくずリストの最適化とJSON-LD構造化データ
ナビゲーション改善でクロール効率向上、リッチリザルト獲得
画像SEO：alt・ファイル名・サイトマップ最適化
LCP改善と並行して、画像検索からの流入も狙う