Core Web Vitals：Webパフォーマンスを測定・改善する方法

Web2026-11-09TryQuickToolBox

モダンなWebアプリを構築しても、ユーザーから「遅い」と感じられるとの声が上がるかもしれません。検索順位にも影響する可能性があります。Core Web Vitals（CWV）は、Googleがユーザー体験を測る指標です：Largest Contentful Paint（LCP）、Interaction to Next Paint（INP）、Cumulative Layout Shift（CLS）の3つです。このガイドでは、これらを正確に測定し、効果的に改善する方法を紹介します。

Core Web Vitalsとは？

Core Web Vitalsは、ユーザー体験の重要な側面を定量化する3つの指標です：

LCPは読み込みパフォーマンスを測定します。最大のコンテンツ要素（画像、テキストブロック、動画）が表示されるまでの時間を示します。目標は2.5秒以下です。
INPは応答性を測定します。すべてのインタラクション（クリック、タップ、キー押下）のレイテンシを捉え、最悪の（またはそれに近い）遅延を報告します。目標は200ミリ秒以下です。
CLSは視覚的安定性を測定します。読み込み中に発生する予期しないレイアウトシフトを定量化します。目標は0.1以下です。

これらの指標は、フィールド測定（実際のユーザーから）とラボ測定（制御された環境で）の両方で行われます。どちらも重要です。

Core Web Vitalsの測定方法

問題を診断するには、フィールドデータとラボデータの両方が必要です。

フィールドデータ（リアルユーザーモニタリング）

フィールドデータは、デバイスやネットワーク全体での実際のユーザー体験を反映します。以下のソースを使用してください：

Chrome User Experience Report（CrUX）：数百万のサイトの実ユーザー指標の公開データセット。PageSpeed InsightsやCrUX API経由でアクセスできます。
Google Search Console：Core Web Vitalsレポートは、CrUXデータに基づいて注意が必要なURLグループを表示します。
Web Vitals JavaScriptライブラリ：web-vitalsライブラリをサイトに追加し、測定値をアナリティクスエンドポイントに送信します。

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

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  navigator.sendBeacon('/analytics', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

ラボデータ（合成テスト）

ラボツールは制御された環境で読み込みをシミュレートするため、デバッグやCI統合に最適です。

Lighthouse：Chrome DevToolsに組み込まれ、CLIとしても利用可能で、PageSpeed Insightsにも統合されています。ラボ指標と改善の機会を報告します。
WebPageTest：カスタムネットワーク条件とフィルムストリップによる高度なテスト。
Chrome DevTools Performanceパネル：INPに影響する長いタスクを含む、ランタイムパフォーマンスを記録・分析します。

ベストプラクティス：ラボデータで修正点を特定し、フィールドデータで効果を検証します。

Largest Contentful Paint（LCP）の改善

LCPは通常、ヒーロー画像や大きなテキストブロックが支配的です。これらを最適化しましょう：

LCPリソースを最適化する：画像を圧縮し（WebP/AVIFを使用）、srcsetでレスポンシブサイズを提供し、LCP画像が重要な場合はプリロードします。
レンダリングブロッキングリソースを排除する：クリティカルCSSをインライン化し、非クリティカルなCSSとJavaScriptを遅延させます。
サーバー応答時間（TTFB）を改善する：CDNを使用し、キャッシュを有効にし、バックエンドクエリを最適化します。
クライアントサイドレンダリングを減らす：SPAの場合、初期表示にサーバーサイドレンダリング（SSR）や静的生成を検討します。

例：LCP画像をプリロードする：

<link rel="preload" as="image" href="/hero.avif" imagesrcset="/hero-480.avif 480w, /hero-800.avif 800w" imagesizes="(max-width: 600px) 480px, 800px">

Interaction to Next Paint（INP）の改善

INPは、ユーザーのインタラクションから次のペイントまでの遅延を測定します。長いタスクと重いJavaScriptが一般的な原因です。

長いタスクを分割する：setTimeout、requestIdleCallback、またはスケジューラAPIを使用してメインスレッドに制御を譲ります。
イベントハンドラを最適化する：コストの高いハンドラをデバウンスまたはスロットルし、レイアウトスラッシングを避けます。
JavaScriptの実行時間を減らす：コード分割、ツリーシェイキング、非クリティカルスクリプトの遅延を行います。
Web WorkersをCPU集約的な作業に使用します。

例：メインスレッドに制御を譲る：

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function handleClick() {
  // ... 何らかの処理
  await yieldToMain();
  // ... 続行
}

Cumulative Layout Shift（CLS）の改善

CLSは、要素が予期せず移動したときに発生します。以下の方法で防ぎましょう：

画像や動画には常にwidthとheight属性を含めるか、CSSのaspect-ratioを使用します。
動的コンテンツ（広告、埋め込み、iframe）のスペースを確保するには、min-heightやプレースホルダーを使用します。
ユーザーのインタラクションによってトリガーされない限り、既存のコンテンツの上にコンテンツを挿入しないようにします。
font-display: optionalを使用するかフォントをプリロードすることで、FOIT/FOUTによるシフトを回避します。

例：広告用のスペースを確保する：

<div>
  <!-- ここに広告が読み込まれる -->
</div>

継続的改善のためのツールとワークフロー

パフォーマンスは一度きりの修正ではありません。測定をワークフローに統合しましょう：

予算を設定する：Lighthouse CIを使用してプルリクエストでしきい値を強制します。
フィールドデータを監視する：CrUXまたは独自のRUMでダッシュボードを設定します。
修正を優先する：「良好」なしきい値との差が最も大きい指標に焦点を当てます。
実機でテストする：ミッドレンジのモバイルデバイスをエミュレートして問題を発見します。

簡単なチェックには、PageSpeed Insightsでページを実行してください。ラボデータとフィールドデータを組み合わせて表示します。

FAQ

Core Web Vitalsの現在のしきい値は？

LCP：良好≤2.5秒、改善が必要≤4秒、不良>4秒。INP：良好≤200ms、改善が必要≤500ms、不良>500ms。CLS：良好≤0.1、改善が必要≤0.25、不良>0.25。

CrUXデータはどのくらいの頻度で更新されますか？

CrUXデータは毎日更新されますが、データセットは過去28日間のローリングウィンドウを反映しています。Search Consoleは定期的に更新されます。

デザインを変更せずにCore Web Vitalsを改善できますか？

はい。多くの改善は技術的なものです：画像の最適化、スクリプトの遅延、動的コンテンツのスペース確保、メインスレッドの作業削減などです。

サイトのパフォーマンスを分析する準備はできましたか？Nginxログアナライザーを使用して、TTFBとLCPに影響する遅いサーバー応答を特定しましょう。