Core Web Vitals：測定と改善の方法

Core Web Vitalsがサイトにとって重要な理由

サイトが遅いというレポートを見たことはあるけれど、どこから手を付ければいいか分からない――そんな経験はありませんか？ Core Web Vitalsは、Googleが提唱する実ユーザー体験の指標です。具体的にはLargest Contentful Paint（LCP）、Interaction to Next Paint（INP）、Cumulative Layout Shift（CLS）の3つを指します。これらは検索ランキングに影響するだけでなく、何よりユーザーがサイトをどう感じるかを左右します。LCPが遅いと訪問者はイライラし、INPが高いとページが反応しないように感じられ、CLSが悪いと誤クリックを引き起こします。このガイドでは、これらの指標を測定し、実践的なステップで改善する方法を紹介します。

3つのCore Web Vitalsを理解する

最適化を始める前に、各指標が何を測定し、どのような閾値があるのかを把握しましょう。

これらの閾値はラボテストではなく、フィールドデータ（実ユーザー）に基づいています。ページ読み込みの少なくとも75%で「良好」範囲を目指しましょう。

Core Web Vitalsの測定方法

ラボデータとフィールドデータの両方が必要です。ラボデータはデバッグに役立ち、フィールドデータは実際のユーザー体験を反映します。

ラボツール

• Chrome DevToolsのLighthouse：パフォーマンススコアと具体的な改善機会について監査を実行します。
• WebPageTest：フィルムストリップやウォーターフォールチャートを使った高度なテストが可能です。
• Chrome UX Report（CrUX）：実ユーザーからのフィールドデータで、PageSpeed InsightsやCrUX APIからアクセスできます。

フィールドツール

• PageSpeed Insights：URLのラボデータとフィールドデータの両方を表示します。
• Google Search Console：Core Web Vitalsレポートで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);

これにより、改善を追跡するためのフィールドデータの継続的なストリームが得られます。

Largest Contentful Paint（LCP）の改善

LCPはしばしば最大の課題です。最大の要素は通常、ヒーロー画像か大きなテキストブロックです。その読み込み経路を最適化しましょう。

1. LighthouseやDevToolsのパフォーマンスパネルを使ってLCP要素を特定する。
2. 読み込みを優先する：画像にfetchpriority="high"を指定するか、<link rel="preload">でプリロードします。
3. 画像を最適化する：圧縮し、モダンなフォーマット（WebP/AVIF）を使い、srcsetでレスポンシブサイズを配信します。
4. サーバー応答時間を短縮する：キャッシュ、CDN、バックエンドクエリの最適化を活用します。
5. レンダリングをブロックするリソースを排除する：クリティカルCSSをインライン化し、非クリティカルなJSを遅延させます。

例：ヒーロー画像をプリロードし、フェッチ優先度を設定します：

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<img src="/hero.avif" alt="Hero" width="1200" height="600" fetchpriority="high">

レイアウトシフトを避けるために、必ずwidthとheightを設定してください。

Interaction to Next Paint（INP）の改善

INPは応答性を測定します。長いタスクはメインスレッドをブロックし、視覚的なフィードバックを遅らせます。INPを改善するには：

• 長いタスクを分割する：setTimeoutやscheduler.yieldを使ってブラウザに制御を譲ります。
• イベントハンドラを最適化する：入力のデバウンスを行い、重い同期処理を避けます。
• JavaScriptを削減する：コード分割、ツリーシェイキング、非クリティカルなスクリプトの遅延を行います。
• Web Workersを使う：CPU負荷の高いタスクに活用します。
• 大規模なDOM更新を避ける：DOM変更をバッチ処理し、requestAnimationFrameを使います。

例：長いループの間にメインスレッドに制御を譲ります：

async function processItems(items) {
  for (let i = 0; i < items.length; i++) {
    // do work
    if (i % 50 === 0) {
      await new Promise(resolve => setTimeout(resolve, 0));
    }
  }
}

これにより、重い処理中でもページの応答性が保たれます。

Cumulative Layout Shift（CLS）の改善

CLSは要素が予期せず移動したときに発生します。一般的な原因は、サイズ指定のない画像、広告、埋め込み、Webフォントです。

• 画像や動画には必ずwidthとheightを指定する。
• 動的コンテンツ（広告、埋め込み）のスペースを確保する：CSSのmin-heightやアスペクト比ボックスを使います。
• font-display: swapを使い、フォントをプリロードする：テキストが見えなくなることやレイアウトシフトを避けます。
• 既存のコンテンツの上にコンテンツを挿入しない：ユーザーの操作に応じた場合を除きます。

例：aspect-ratioを使ってスペースを確保します：

.video-container {
  aspect-ratio: 16 / 9;
  width: 100%;
}

これにより、動画の読み込み時のシフトを防げます。

監視と反復改善

パフォーマンスは一度きりの修正ではありません。実ユーザーの指標を使って継続的な監視を設定しましょう。ダッシュボードを使ってLCP、INP、CLSを時系列で追跡します。変更するたびにラボツールで検証し、数日後にフィールドデータを確認します。最も多くのユーザーに影響する修正を優先しましょう。

よくある質問

Core Web Vitalsの現在の閾値は？

LCP：良好 ≤2.5秒、改善が必要 2.5～4.0秒、不良 >4.0秒。INP：良好 ≤200ミリ秒、改善が必要 200～500ミリ秒、不良 >500ミリ秒。CLS：良好 ≤0.1、改善が必要 0.1～0.25、不良 >0.25。

Core Web Vitalsはどのくらいの頻度で測定すべき？

フィールドデータを継続的に監視し、重要な変更のたびにラボテストを実行します。Search Consoleで週に一度トレンドを確認しましょう。

サイトを再構築せずにCore Web Vitalsを改善できますか？

はい。画像の最適化、プリロード、CSSの調整など、多くの改善は完全な再構築なしに段階的に適用できます。

LCPを改善するために画像をすばやく圧縮する必要がありますか？ 品質を損なわずにファイルサイズを削減できる無料のImage Compressorをお試しください。