Core Web Vitalsスコア改善の実践テクニック【2026年版】

この記事の対象: Core Web Vitalsのスコアを改善したいWeb制作者・サイト運営者
読了時間: 約9分

Core Web Vitals（CWV）は、Googleが定義するページのユーザー体験を測定する3つの指標です。検索順位に影響するランキング要因の1つであり、特にモバイル検索ではCWVのスコアが低いサイトは競合に差をつけられます。INPがコア指標に加わってから数年が経ち、計測環境もAIコーディングツールも変わりました。この記事では2026年時点の3指標の基準と、現場で効く改善テクニックを整理し直します。

Core Web Vitalsの3指標（2026年版）

LCP（Largest Contentful Paint）

ページのメインコンテンツが表示されるまでの時間を測定します。

判定	基準
Good	2.5秒以内
Needs Improvement	2.5〜4.0秒
Poor	4.0秒超

対象要素: <img>、<video>のポスター画像、CSSのbackground-image、テキストブロック。ファーストビューで最も大きな要素が対象です。

INP（Interaction to Next Paint）

ユーザーの操作（クリック、タップ、キー入力）から次の画面描画までの遅延時間を測定します。2024年3月にFID（First Input Delay）から置き換わった指標で、2026年の現在はすでに定着し、PageSpeed InsightsやSearch Consoleのレポートも完全にINP基準に移行しています。

判定	基準
Good	200ms以内
Needs Improvement	200〜500ms
Poor	500ms超

FIDとの違い: FIDは「最初の操作」のみ測定していたのに対し、INPはページ内のすべての操作を対象に、最も遅延が大きい操作を代表値とします。「初回クリックだけ速ければ良い」設計は通用しません。

CLS（Cumulative Layout Shift）

ページの読み込み中に要素が予期せず移動する量を測定します。

判定	基準
Good	0.1以下
Needs Improvement	0.1〜0.25
Poor	0.25超

発生例: 画像が遅れて読み込まれてテキストが押し下げられる、広告が突然挿入されてボタンの位置がずれる、Webフォントの読み込みでテキストのサイズが変わる。

3指標が測っているタイミングの違い

LCP最初の表示がどれだけ速いか

INP操作への反応がどれだけ速いか

CLS表示がどれだけ動かないか

3つは別々の工程で発生するため、対策もそれぞれ独立しています。LCPだけ改善してINPとCLSを放置すると、総合評価は上がりません。

計測方法

PageSpeed Insights

Googleが提供する無料ツール。URLを入力するだけで3指標のスコアと改善提案を確認できます。

フィールドデータ（実際のユーザーデータ）とラボデータ（シミュレーション結果）の2種類を表示。SEOに影響するのはフィールドデータです。ラボデータだけ見て「Good」と判断し、実際のユーザー環境では悪化していたというズレがよく起きます。

Google Search Console

「ウェブに関する主な指標」レポートで、サイト全体のCWVスコアの推移と問題のあるURLを確認できます。

活用法: ページ単位の問題を特定し、優先的に改善すべきURLを見つけます。テンプレートが共通のサイトでは、1ページ直すと同じテンプレートを使う全ページに効果が波及します。

Chrome DevTools（Lighthouseタブ）

ブラウザのDevToolsからLighthouseを実行。ローカル環境やステージング環境での計測に便利です。

注意: Lighthouseはラボデータのみ。実際のユーザー環境とは異なる場合があります。公開前の目安として使い、公開後はフィールドデータで答え合わせをする運用が実務的です。

計測結果を自社のGA4データと突き合わせて「どのページで離脱が増えているか」まで見たい場合は、以下の記事も参考になります。

テクニック AIでGA4を分析してサイト改善につなげる｜使える答えが返るデータの渡し方 GA4の画面をスクリーンショットして「改善点を教えて」と投げると、だいたい「直帰率が高いのでファーストビューを見直しましょう」が返ってきます。間違ってはいな…

LCP改善テクニック

画像の最適化

LCPの原因の多くは画像の読み込み遅延です。ファーストビューの画像をどう先読みさせるかが勝負になります。

<!-- ファーストビューの画像はpreloadで先読み -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<!-- 画像フォーマットはWebP/AVIFを使用 -->
<picture>
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="ヒーロー画像" width="1200" height="600"
       fetchpriority="high" decoding="async">
</picture>

対策	効果
WebP/AVIF形式に変換	JPEGに比べてファイルサイズを大きく削減できる
fetchpriority=”high”	LCP画像の読み込み優先度を上げる
preload	画像のリクエストを前倒しする
適切なサイズ指定	必要以上に大きな画像を読み込まない

サーバーレスポンス時間の短縮

TTFB（Time to First Byte）が長い場合は、サーバー側の改善が必要です。

対策	方法
CDN導入	Cloudflare等でエッジキャッシュ
サーバーキャッシュ	ページキャッシュの有効化
PHPバージョン	最新の安定版にアップグレード
データベース最適化	不要なpost revisionの削除、インデックス最適化

ShopifyのようにホスティングをプラットフォームへすべてSaaS事業者が持つ構成では、TTFB自体のチューニング余地は小さい一方、テーマ側のLiquidやアプリの埋め込みが重くなるとLCPを押し下げます。表示崩れや反映遅延があわせて起きている場合は、原因の切り分けから始めるのが近道です。

テクニック Shopifyで反映されない・表示されない原因｜確認する順番と対処法管理画面で直したはずの文言が、公開URLでは古いまま。商品を登録したのに一覧に出てこない。セクションを並べ替えたのに、実際のページは何も変わっていない。Sh…

レンダリングブロックの排除

CSSやJavaScriptがページの描画をブロックしている場合、LCPが遅延します。

<!-- クリティカルCSSをインライン化 -->
<style>/* ファーストビューに必要なCSS */</style>

<!-- 残りのCSSは非同期読み込み -->
<link rel="preload" href="/style.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">

<!-- JavaScriptはdefer -->
<script src="/main.js" defer></script>

INP改善テクニック

JavaScriptの最適化

INPの問題の多くは、重いJavaScript処理がメインスレッドをブロックしていることが原因です。

// NG: クリック時に重い処理を同期実行
button.addEventListener('click', () => {
  heavyCalculation();  // メインスレッドを長時間ブロックする
  updateUI();
});

// OK: 重い処理をスケジューラで分割
button.addEventListener('click', () => {
  updateUI();  // まずUIを更新
  requestIdleCallback(() => {
    heavyCalculation();  // アイドル時に重い処理
  });
});

長時間タスクの分割

50msを超えるタスク（Long Task）はINPに悪影響を与えます。

// Long Taskを分割する
async function processItems(items) {
  for (const item of items) {
    processItem(item);
    // 定期的にメインスレッドに制御を戻す
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

インタラクション応答の優先度設計

/* コンテンツの表示をブロックしないCSS */
.non-critical {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

content-visibility: autoを使うと、画面外の要素のレンダリングを省略し、インタラクションの応答速度が向上します。

INP改善は「どこが重いか」を見つける作業の比重が大きく、原因箇所の特定にAIコーディングツールを使うと切り分けが早くなります。Long Taskの発生源をプロファイラの出力から読み解かせる、修正案のコードを書かせるといった使い方です。

テクニック Claude Code Web制作使い方｜テーマ改修と記事生成を任せる線引きターミナルで動くAIエージェント「Claude Code」を、実際の制作案件で使い続けています。Shopifyテーマの改修、WordPressの子テーマ追加…

テクニック WordPressサイトの表示速度を改善する実践テクニック【2026年版】 WordPressサイトの表示速度は、SEO・ユーザー体験・コンバージョン率のすべてに影響します。表示が遅いサイトはGoogleの評価でも不利になり、ユーザ…

CLS改善テクニック

画像・動画のサイズ指定

<!-- 必ずwidth/heightを指定 -->
<img src="/photo.webp" alt="写真" width="800" height="450">

<!-- CSSでアスペクト比を維持 -->
<style>
  .responsive-img {
    width: 100%;
    height: auto;
    aspect-ratio: 16 / 9;
  }
</style>

Webフォントの読み込み最適化

/* font-display: swapでFOIT（テキスト非表示）を防止 */
@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap;
}

/* サイズ調整で代替フォントとのCLSを軽減 */
@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap;
  size-adjust: 105%;
  ascent-override: 90%;
}

動的コンテンツの挿入ルール

広告やCookie同意バナーなど、後から挿入される要素はCLSの主要因です。

要素	対策
広告スロット	事前にスペースを確保（min-height設定）
Cookie同意バナー	position: fixedで重ならない配置
遅延読み込みコンテンツ	skeleton UIでスペースを確保

/* 広告スロットの事前スペース確保 */
.ad-slot {
  min-height: 250px;
  background: #f5f5f5;
}

CLSが起きる構成と、起きない構成の違い

対策あり

画像にwidth/height指定済み
広告枠にmin-heightを確保
フォント切替時のサイズ差を吸収

対策なし

画像サイズが読み込むまで不明
広告挿入時にレイアウトが動く
Webフォント読み込みでテキスト幅が変わる

CLSは実装の抜け漏れ1つで簡単に再発するため、改修後はLighthouseだけでなくSearch Consoleのフィールドデータで数週間は推移を見ておくのが安全です。

改善後のモニタリング体制

一度スコアを上げても、画像の差し替えやアプリ追加のたびにCLSやLCPは再び悪化します。継続的に見る仕組みが要ります。

Search Consoleの「ウェブに関する主な指標」を月次で確認する
デザインや機能追加のリリース前にLighthouseで比較する
Shopifyなどコマースプラットフォームでは、アプリ導入のたびにパフォーマンスへの影響を計測レポートと突き合わせる

ECサイトでは売上データとパフォーマンス指標を並べて見る習慣があると、CWVの悪化が売上にどう影響しているかまで追えます。

リニューアルガイド Shopify分析レポートの見方｜数字を見る優先順位と落ちた原因の特定手順 Shopifyの管理画面を開くと、「ストア分析」の中に十数種類の数字が並んでいます。セッション数、コンバージョン率、平均注文額、オンラインストアの転換率、ト…

まとめ

Core Web Vitalsの改善ポイントをまとめます。

LCP（表示速度）:
– 画像をWebP/AVIFに変換＋fetchpriority=”high”
– CDN導入＋サーバーキャッシュ
– クリティカルCSSのインライン化

INP（応答速度）:
– Long Taskの分割
– UIの更新を先行、重い処理は後回し
– content-visibility: autoの活用

CLS（レイアウト安定性）:
– img/videoにwidth/height指定
– font-display: swap＋size-adjust
– 動的要素のスペースを事前確保

3指標すべてで「Good」を達成することで、ユーザー体験の向上とSEO評価の改善が期待できます。一度の改修で終わらせず、リリースのたびに計測を挟む運用まで含めて設計しておくと、スコアの逆戻りを防げます。

よくある質問

Core Web Vitalsのスコアが悪いと検索順位は必ず下がりますか

CWVはランキング要因の1つですが、コンテンツの質や関連性ほど比重は大きくありません。ただしモバイル検索では体感差が大きいため、同程度のコンテンツ品質の競合がいる場合に差がつきやすい指標です。

INPとFIDは両方見る必要がありますか

いいえ。FIDはすでに廃止されており、現在のPageSpeed InsightsやSearch ConsoleもINPのみを表示します。古い記事や資料に出てくるFIDの基準値は参考にしなくて構いません。

Lighthouseでは良いスコアなのに実際のユーザーは遅いと感じます

Lighthouseはラボデータのみで、ネットワーク環境や端末性能にばらつきのある実際のユーザーの体験とは異なります。判断材料にするのはSearch ConsoleやPageSpeed Insightsのフィールドデータです。

Shopifyのようなプラットフォームでも同じ対策が通用しますか

画像の最適化やWebフォントの扱いなど、HTML/CSSレベルの対策はそのまま通用します。一方でサーバー側のTTFBやテーマの構造には手を入れられる範囲に制限があるため、プラットフォーム固有の制約を先に確認してから着手するのが安全です。

CWVの改善にかかる期間の目安はありますか

画像最適化やサイズ指定など実装側の対策は数日で反映できますが、Search Consoleのフィールドデータに改善が反映されるまでは実測ベースで数週間のタイムラグがあります。公開直後に判断せず、一定期間のデータが貯まってから評価してください。