LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Core Web Vitalsとは — Webサイトの表示速度・操作性を測る指標

Core Web Vitals（コア ウェブ バイタル）とは、Googleが定めるWebページのユーザー体験を測定する指標群です。web.devの公式定義では「読み込み性能（loading performance）」「インタラクティビティ（interactivity）」「視覚的安定性（visual stability）」の3領域を対象とし、現在はLCP・INP・CLSの3指標で構成されています^*1。

本稿で扱うのはWebサイト（ブラウザで表示されるページ）のCore Web Vitalsです。モバイルアプリの起動時間やANR（Application Not Responding）といったネイティブアプリ特有の性能課題とは計測方法・改善手法が異なるため、対象を分けて捉える必要があります。

3指標の定義と良好の閾値 — LCP・INP・CLS

各指標には「良好（Good）」「改善が必要（Needs Improvement）」「不良（Poor）」の3段階の評価があり、web.devの公式ドキュメントに数値で明示されています^*1。

LCP（Largest Contentful Paint） — 読み込み性能

LCPは、ページ内で表示面積が大きい画像またはテキストブロックが表示されるまでの時間を測る指標です。ユーザーが「ページの主要な内容が表示された」と感じるタイミングに近いことから、読み込み性能を代表する指標として採用されています^*1。良好とされる閾値は2.5秒以下です^*1。

INP（Interaction to Next Paint） — 応答性

INPは、ページに対するユーザーのクリック・タップ・キー入力などの操作から、その結果として画面が視覚的に更新されるまでの時間を測る指標です。web.devの公式ドキュメントでは、ページの生存期間中に発生したほぼすべてのインタラクションを観察し、外れ値を除いたうえで遅い方のインタラクションの値を報告する仕組みだと説明されています^*2。良好とされる閾値は200ミリ秒以下、200〜500ミリ秒は改善が必要、500ミリ秒を超えると不良と判定されます^*2。

CLS（Cumulative Layout Shift） — 視覚的安定性

CLSは、ページの表示中に発生する予期しないレイアウト変動（要素の位置が突然ずれる現象）の累積量を測る指標です。広告や画像の遅延読み込みによって後から要素が挿入され、既存の要素が押し下げられるような現象が典型例です。良好とされる閾値は0.1以下です^*1。

INPがFIDを置き換えた経緯

2024年3月12日以前は、応答性を測る指標としてFID（First Input Delay、初回入力遅延）が採用されていました。web.devの公式発表によると、INPは同日付でCore Web Vitalsの正式な指標としてFIDを置き換えています^*3。FIDはページ内で最初に発生した1回の操作のみを対象にしていたのに対し、INPはページ全体のすべてのインタラクションを観察するため、より実態に近い応答性評価が可能になった点が主な違いです^*2。古い資料でFIDが登場する場合は、現在の評価対象ではない点に注意が必要です。

指標別のボトルネックと改善手法

3指標はそれぞれ異なる技術要因に影響されるため、ボトルネックの特定と改善手法も指標ごとに整理する必要があります。

LCPのボトルネック — サーバ応答・レンダリングブロック・画像

LCPが遅い場合、原因は「サーバ応答の遅さ」「レンダリングをブロックするCSS/JavaScript」「大きな画像やフォントの読み込み遅延」のいずれかに大別されます。改善の基本は、サーバのレスポンスタイム短縮（キャッシュ・CDNの活用）、クリティカルCSSの分離、画像の圧縮・次世代フォーマット（WebP・AVIF）への変換、遅延読み込み（lazy loading）の適用です。ただし、最初の画面（ビューポート内）に表示される画像には遅延読み込みを適用すると逆にLCPが悪化するため、優先読み込み（fetchpriorityやpreload）を使い分ける判断が必要です。

INPのボトルネック — メインスレッドの長時間処理・JavaScript実行量

INPが悪化する主な原因は、ブラウザのメインスレッドを長時間占有するJavaScriptの実行です。大量のイベントリスナー処理、重いレンダリング処理、サードパーティスクリプト（広告・アクセス解析タグなど）の負荷が典型的な要因になります。改善手法としては、処理を小さな単位に分割してメインスレッドを定期的に解放する（コードスプリッティング）、不要なJavaScriptの削減、サードパーティスクリプトの読み込みタイミングの見直し（遅延実行）が挙げられます。

CLSのボトルネック — サイズ未指定の要素・動的コンテンツの挿入

CLSが悪化する典型例は、画像や広告枠にサイズ（width/height）が指定されておらず、読み込み完了後に周囲の要素が押し下げられる現象です。改善の基本は、画像・動画・埋め込みコンテンツに明示的なサイズを指定すること、Webフォント読み込み時のフォールバック表示を工夫すること、動的に挿入される通知バナーなどをユーザー操作の結果としてのみ表示する設計にすることです。

計測方法 — Lighthouse・PageSpeed Insights・CrUXの違い

Core Web Vitalsの改善に着手する前提として、計測方法の違いを理解しておく必要があります。計測データには「ラボデータ」と「フィールドデータ」の2種類があり、性質が異なります。

Lighthouse — ラボデータで再現性のある診断を行う

Lighthouseは、Webページの品質向上を支援するオープンソースの自動化ツールです^*4。パフォーマンス・アクセシビリティ・SEOなどの観点で診断を行い、決められた環境条件（シミュレートされたネットワーク・デバイス）で1回のセッションを計測する「ラボデータ」を提供します。再現性が高く、改善前後の効果比較に向いていますが、実際のユーザー環境とは異なる条件での計測になる点に留意が必要です。

PageSpeed Insights — ラボとフィールドの両方を確認できるWebUI

PageSpeed Insightsは、Webブラウザ上でLighthouseを実行できるツールで、インストール不要で利用できます^*4。PageSpeed InsightsはLighthouseによるラボデータに加えて、実際のユーザーから収集されたフィールドデータ（CrUX）も同じ画面で確認できる点が特徴です。両者の数値が大きく異なる場合は、ラボ環境とは異なる実ユーザーの回線・デバイス条件が影響している可能性を検討します。

CrUX — 実際のユーザー体験を集計したフィールドデータ

CrUX（Chrome User Experience Report）は、実際のChromeユーザーがWeb上の人気ページをどのように体験しているかを反映したGoogleのデータセットです^*5。特定のブラウザ設定条件を満たす実ユーザーの匿名化された利用データから収集されており、ページやオリジン（サイト全体）ごとに一定の閲覧数などの適格性基準を満たす場合に集計対象となります^*5。Google検索のCore Web Vitals評価は、このCrUXのフィールドデータをもとに行われます^*6。

SEO・UXへの影響 — Google検索での位置づけ

Google Search Centralの公式ドキュメントでは、Core Web Vitalsを含む「ページエクスペリエンス」の要素が、Googleの検索ランキングシステムが重視する体験と一致すると説明されています^*6。同ドキュメントでは、検索での成功のためにCore Web Vitalsを良好な水準にすることを推奨する旨が明記されています^*6。

一方で、Core Web Vitalsはあくまでランキングに関わる要素の一つであり、コンテンツの関連性や網羅性といった評価軸と並行して考慮されるものです。表示速度の改善のみでコンテンツの質を代替できるわけではない点は、施策の優先順位を検討する上で押さえておく必要があります。

UXの観点では、LCPの遅さは直帰率の上昇、INPの悪さは操作時のフラストレーションによる離脱、CLSの悪さは誤クリック（意図しないリンクのタップなど）につながりやすいとされています。表示速度の改善は検索経由の流入だけでなく、訪問後の回遊率やコンバージョン率にも影響する施策です。

外注の進め方と委託範囲

Core Web Vitalsの改善を外注する場合、計測から実装までの工程を分解し、どこを内製で担い、どこを委託するかを整理することが計画の出発点になります。

ステップ1：現状計測とボトルネックの棚卸し

PageSpeed InsightsやCrUXデータで対象ページのLCP・INP・CLSの現状値を取得し、どの指標がどの程度悪化しているかを特定します。サイト全体の傾向を把握するには、Google Search ConsoleのCore Web Vitalsレポートを併用すると、URLグループ単位で不良ページを一覧できます。この段階のデータがない場合は、計測基盤の整備自体を委託範囲に含めることも検討します。

ステップ2：技術的な原因分析

Lighthouseのラボデータやブラウザの開発者ツール（パフォーマンスタブ）を使って、レンダリングブロックの原因となるリソース、メインスレッドを占有する処理、レイアウト変動を起こしている要素を特定します。CMSやフレームワークの構成、サードパーティスクリプトの影響範囲まで踏み込んで分析する必要があるため、フロントエンドの実装知識を持つ外注先への委託が有効な工程です。

ステップ3：改善実装と検証

特定した原因に対して、画像最適化・コード分割・サーバ設定の見直しなどの実装を行います。改善実装後は、実装前と同じ条件でLighthouse計測を行い、変化を数値で確認します。フィールドデータ（CrUX）は反映までに一定の期間を要するため、公開直後のラボデータでの検証と、数週間後のフィールドデータでの再確認を分けて計画に組み込みます。

委託範囲を決める際の確認項目

外注先を選定する際は、改善前後のLighthouse/CrUXレポートの提示を納品物として要件に含めることで、成果を数値で確認しながら進められます。加えて、対象サイトのCMSやフレームワークに関する実装経験、サードパーティスクリプトの棚卸し経験を確認すると、委託範囲とのマッチ度を判断しやすくなります。

まとめ — Core Web Vitals改善を外注で進める3つの視点

本稿では、Webサイトの表示速度・操作性を示すCore Web Vitals（LCP・INP・CLS）の定義と閾値、指標別のボトルネックと改善手法、計測方法、外注の進め方を整理しました。要点を3つに集約すると次の通りです。

第一に、Core Web Vitalsは2024年3月12日にINPがFIDを置き換えて以降、LCP（2.5秒以下）・INP（200ミリ秒以下）・CLS（0.1以下）の3指標体制になっています^*1*2*3。改善に着手する前に、現行の指標と閾値を正確に把握することが出発点です。

第二に、指標ごとにボトルネックの技術要因が異なるため、LCPはサーバ応答・画像・レンダリングブロック、INPはメインスレッドを占有するJavaScript、CLSはサイズ未指定の要素という切り分けで原因分析を進める必要があります。

第三に、計測にはラボデータ（Lighthouse）とフィールドデータ（CrUX）の違いがあり、Google検索のCore Web Vitals評価はフィールドデータに基づきます。外注する際は、現状計測・原因分析・改善実装のどの工程にリソースやスキルのギャップがあるかを見極め、改善前後の計測レポートを納品物として要件に含めることが、成果の見える化につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Web Vitals — web.dev」（最終更新：2024年10月31日）
2. *2　出典：Google「Interaction to Next Paint (INP) — web.dev」
3. *3　出典：Google「INP becomes a Core Web Vital on March 12 — web.dev」
4. *4　出典：Google「Lighthouse overview — Chrome for Developers」
5. *5　出典：Google「Chrome UX Report (CrUX) — Chrome for Developers」
6. *6　出典：Google「Understand Core Web Vitals and Google Search results — Google Search Central」

Tweet