Core Web Vitalsの改善方法｜LCP・INP・CLSを最適化する実践ガイド
Core Web Vitalsとは？
Core Web Vitals（コアウェブバイタル）は、Googleがユーザー体験を定量的に評価するための3つの指標です。2021年にランキング要因として導入されて以来、Webサイトのパフォーマンス改善において欠かせない基準となっています。3つの指標はそれぞれ、ページの読み込み速度、操作への応答性、視覚的な安定性を測定します。
優れたCore Web Vitalsスコアは、離脱率の低下やコンバージョン率の向上と相関関係があります。それ以上に重要なのは、ユーザーがサイトをどのように体験するかという本質的な品質の改善を反映している点です。Googleは引き続きSearch ConsoleやPageSpeed Insightsでこれらの指標を重視しており、あらゆるSEO戦略において対応が不可欠な要素となっています。
3つの指標と基準値
LCP（Largest Contentful Paint）— 読み込み速度
LCPは、ページ内で最も大きなコンテンツ要素（通常はヒーロー画像、見出し、テキストブロック）が画面に表示されるまでの時間を測定します。
| 判定 | 基準値 |
|---|---|
| 良好 | 2.5秒以内 |
| 改善が必要 | 2.5秒〜4.0秒 |
| 不良 | 4.0秒超 |
INP（Interaction to Next Paint）— 応答性
INPは、ページのライフサイクル全体を通じたすべてのユーザー操作（クリック、タップ、キー入力）の遅延を測定し、最も遅かった操作を報告します。2024年3月にFID（First Input Delay）に代わって正式なCore Web Vitalsの指標となりました。
| 判定 | 基準値 |
|---|---|
| 良好 | 200ms以内 |
| 改善が必要 | 200ms〜500ms |
| 不良 | 500ms超 |
CLS（Cumulative Layout Shift）— 視覚的安定性
CLSは、ページの読み込み中にレイアウトが予期せずずれる度合いを数値化した指標です。画像、広告、フォントの遅延読み込みにより、読んでいたテキストが突然ずれるような体験を防ぐことが目的です。CLSの値が高いということは、ユーザーにとってストレスのある不安定なレイアウトであることを意味します。
| 判定 | 基準値 |
|---|---|
| 良好 | 0.1以下 |
| 改善が必要 | 0.1〜0.25 |
| 不良 | 0.25超 |
LCPを改善する具体的な方法
LCPの悪化原因の多くは、大きな未最適化の画像、レンダリングをブロックするリソース、またはサーバーレスポンスの遅さに起因します。
画像を最適化する
ほとんどのページでは画像がLCP要素になります。画像の最適化は、多くの場合で最大の改善効果をもたらします。
<img
src="hero.webp"
alt="サービスのメインビジュアル"
width="1200"
height="630"
fetchpriority="high"
decoding="async"
/>
具体的なテクニックは以下のとおりです。
- WebPまたはAVIF形式を使用する（JPEGと比べて30〜50%軽量化）
fetchpriority="high"をLCP画像に設定し、ブラウザが最優先で読み込むようにするwidthとheight属性を必ず指定する（CLSの防止にもなる）srcsetとsizes属性を使って、デバイスに応じた適切なサイズの画像を配信する- LCP画像には遅延読み込み（lazy loading）を適用しない（ファーストビュー以下の画像にのみ使用する）
レンダリングブロックを排除する
CSSや同期的なJavaScriptは、最初のペイントを大幅に遅延させる原因になります。
<!-- クリティカルCSSをインライン化 -->
<style>
.hero { display: flex; align-items: center; min-height: 60vh; }
.hero img { max-width: 100%; height: auto; }
</style>
<!-- 残りのCSSは非同期で読み込む -->
<link rel="preload" href="/styles/main.css" as="style" onload="this.rel='stylesheet'" />
- ファーストビューに不要なスクリプトには
deferまたはasync属性 を付ける - 使っていないCSSを削除する（Chrome DevToolsのカバレッジタブで確認）
- フォントには
font-display: swapを指定して、フォールバックフォントですぐにテキストを表示させる
サーバーレスポンスを高速化する
TTFB（Time to First Byte）が遅い場合、フロントエンドをどれだけ最適化しても効果が限定的です。
- CDN（Cloudflare、CloudFront、Fastlyなど）を導入し、ユーザーに近いエッジロケーションからコンテンツを配信する
- サーバーサイドのキャッシュを有効にする（静的ページおよび半静的ページ）
- HTTP/2またはHTTP/3を使用して多重化接続を行う
- Next.jsなどのフレームワークを使用している場合は、静的生成（SSG）やISRを検討する
INPを改善する具体的な方法
INPの問題は、ブラウザのメインスレッドをブロックする長時間のタスクに起因し、ユーザー入力への応答を妨げます。
重い処理を分割する
50ミリ秒を超えるJavaScriptタスクは「ロングタスク」とみなされ、応答性を低下させます。
// 悪い例：ループ全体でメインスレッドを占有
function processItems(items) {
items.forEach(item => heavyComputation(item));
}
// 良い例：イテレーション間でブラウザに制御を返す
async function processItems(items) {
for (const item of items) {
heavyComputation(item);
await scheduler.yield();
}
}
イベントハンドラを軽量に保つ
button.addEventListener('click', () => {
// 即座に視覚的フィードバックを表示
showSpinner();
// 重い処理は遅延実行
requestIdleCallback(() => {
runExpensiveOperation();
hideSpinner();
});
});
その他の改善手法:
- サードパーティスクリプト（アナリティクス、広告、チャットウィジェット）を監査する。これらが最大のボトルネックであることが多い
- コード分割（code splitting） を使い、JavaScriptを事前にすべて読み込むのではなくオンデマンドで読み込む
scrollやresizeなどの頻繁に発火するイベントにはデバウンスを適用する- 可能な場合は、重い計算処理をWeb Workerに移す
CLSを改善する具体的な方法
CLSの発生原因は明確に特定でき、修正も比較的容易です。
メディア要素にサイズを指定する
<img src="photo.webp" alt="商品写真" width="800" height="533" />
<video width="1280" height="720" poster="thumb.jpg">
<source src="video.mp4" type="video/mp4" />
</video>
レスポンシブレイアウトでは、CSSの aspect-ratio プロパティを使う方法も有効です。
.video-wrapper {
aspect-ratio: 16 / 9;
width: 100%;
}
動的コンテンツ用のスペースを確保する
広告、バナー、Cookie同意通知など、遅れて読み込まれる要素はレイアウトシフトの一般的な原因です。あらかじめスペースを確保しておきましょう。
.ad-slot {
min-height: 250px;
width: 300px;
background: #f0f0f0; /* プレースホルダー背景 */
}
Webフォントの読み込みによるシフトを防ぐ
@font-face {
font-family: 'BrandFont';
src: url('/fonts/brand.woff2') format('woff2');
font-display: swap;
}
font-display: optional を使うと、カスタムフォントが間に合わない場合はフォールバックフォントをそのまま使用するため、レイアウトシフトを完全に排除できます。ただし、低速回線ではブランドフォントが表示されないというトレードオフがあります。
Core Web Vitalsの測定ツール
フィールドデータ（実ユーザーデータ）
- Chrome UX Report（CrUX）: 実際のChromeユーザーから収集されたパフォーマンスデータの集計値。PageSpeed InsightsやBigQueryからアクセスできる
- Google Search Console: Core Web Vitalsレポートでサイト全体のページの合格・不合格をステータス別に確認できる
ラボデータ（シミュレーション）
- PageSpeed Insights: フィールドデータ（利用可能な場合）とLighthouseのラボデータを一画面で確認できる
- Chrome DevTools（Lighthouse）: 開発中にローカルで測定を実行できる
- WebPageTest: 詳細なウォーターフォールチャートとフィルムストリップビューを提供
IndexReadyでのチェック
IndexReadyはPageSpeed Insights APIを利用して、サイトのパフォーマンスを自動評価します。SEOカテゴリ内で PageSpeedスコア（10点満点） と Core Web Vitals（10点満点） の2つの独立した項目として評価されるため、LCP、INP、CLSの現状を素早く把握できます。URLを入力するだけでベースラインスコアを取得し、最適化に取りかかる前の出発点として活用してください。
改善の優先順位
3つの指標すべてに改善が必要な場合は、以下の順序で取り組むことをおすすめします。
- まずLCPを改善する。 画像最適化だけでもスコアが大幅に向上するケースが多く、修正も比較的シンプルです。
- 次にCLSを修正する。 原因が特定しやすく、修正のほとんどがCSSのみの変更で済みます。
- 最後にINPを最適化する。 応答性の問題はJavaScriptの構造的な変更を伴うことが多く、改善に時間とテストが必要です。
PageSpeed Insightsで最も重要なページを測定し、最もスコアが低い指標を特定するところから始めましょう。
よくある質問（FAQ）
Core Web VitalsはSEOのランキングにどの程度影響しますか？
Core Web VitalsはGoogleが公式に認めたランキング要因ですが、コンテンツの関連性や被リンクほどの重みはありません。最も差が出るのは競合サイトとコンテンツの質や権威性が拮抗しているタイブレーク的な場面で、パフォーマンスが良いページが上位に表示される傾向があります。ランキングへの直接効果に加え、Core Web Vitalsの改善は離脱率の低下やエンゲージメントの向上をもたらし、間接的にもSEOに好影響を与えます。
FIDはもう関係ないのですか？
はい、関係ありません。FID（First Input Delay）は2024年3月にINP（Interaction to Next Paint）に完全に置き換わりました。FIDは最初のインタラクションの遅延のみを測定していましたが、INPはページのライフサイクル全体を通じたすべてのインタラクションの応答性を追跡します。これにより、実際のユーザー体験をより包括的かつ正確に反映した指標になっています。現在はINPの改善に注力してください。
モバイルとデスクトップでスコアが大きく違うのはなぜですか？
PageSpeed Insightsのラボデータは、モバイルの場合はCPU速度を約4倍に抑制し、低速なネットワーク接続をシミュレーションした環境で測定されます。そのため、デスクトップでは90点以上でもモバイルでは50〜60点台になることは珍しくありません。Googleはモバイルファーストインデックスを採用しているため、モバイルのスコア改善を優先しましょう。最も効果的な対策は、JavaScript実行時間の削減と、小さなビューポート向けの画像最適化です。
Core Web Vitalsの改善がSearch Consoleに反映されるまでどのくらいかかりますか？
GoogleはCore Web Vitalsのフィールドデータを28日間のローリングウィンドウで収集しています。修正をデプロイした後、Search ConsoleのCore Web Vitalsレポートに改善が反映されるまでには、通常4〜8週間かかります。PageSpeed InsightsやLighthouseのラボデータで変更をすぐに検証することはできますが、フィールドデータの確認には忍耐が必要です。