Core Web Vitalsとは?8年運用してわかった『UX定量化3指標の正体』と改善の正解

『Core Web Vitals』って、ぶっちゃけ何の指標なのか、ちゃんと説明できますか?

株式会社Cameen 西村温裕ことおんゆーです。

近年、SEOやWebサイト運営の現場で「Core Web Vitals」という言葉を聞かない日がないですよね。Googleの検索アルゴリズムでランキング要因として組み込まれ、Search ConsoleにもPageSpeed Insightsにも、専用のスコア欄が表示されるようになりました。

で、いざ「Core Web Vitalsって具体的に何を測ってるんですか?」「LCPとINPとCLSってどう違うんですか?」と聞かれると、答えに詰まる方が多いんですよね。「ページが速いか遅いかの指標でしょ?」という認識で止まって、3つの指標がそれぞれ何を測定しているかまで理解している人は意外と少ない。これ、自分だけだと思ってませんか?

うちの事業ではonyou0720.com・cameen.jp・stylo-education.com・CBCマートなど計5サイトを8年運用してきました。Core Web Vitalsは2020年の発表当初から計測対象に組み込んでいて、SEO観点だけでなくCVR改善の文脈でも数値を追ってきました。その中で見えてきたのは、Core Web Vitalsは単なる「ページ表示速度の点数」ではなく、「訪問者が離脱する前に体感する不快感を3つの観点で数値化したもの」だということ。スコアを上げることが目的ではなく、離脱を減らすことが本当の狙いです。

もう1つ、うちで繰り返し観察したのは、「Core Web Vitalsの数値だけ追いかけて、CVRや滞在時間が改善していないサイト」が多いという事実。LCPを3.5秒から2.0秒に改善しても、フォーム送信率が上がらないケースが頻発します。指標を見るだけでは足りなくて、「何のために改善するか」を決めないと、Core Web Vitals対応は技術的な体操で終わってしまう領域です。

今回はその「今さら聞けないCore Web Vitals」を、表面的な解説ではなく、3指標の構造と現場でのチューニング判断軸まで一気に深掘りしていきます。読み終わる頃には、自分のサイトのどの数値を、どの順番で、どのくらい改善すべきかが、紙に書き出せるレベルになっているはずです。

結論:Core Web Vitalsの核心は「速度」ではなく「UXの定量化」

Core Web Vitalsの本当の正体は、「ユーザーがページを開いてから操作を完了するまでの体感品質を、3つの観点で定量化したGoogleの公式UX指標」のことです。単なる速度測定ではなく、「読み込み」「応答」「視覚的安定性」の3軸でUXを数値化しています。

うちの体感として、Core Web Vitalsは3指標で構成されます。LCP(Largest Contentful Paint=主要コンテンツの表示速度)、INP(Interaction to Next Paint=操作への応答速度)、CLS(Cumulative Layout Shift=レイアウトのズレ量)、この3つです。各指標が「良好」「要改善」「不良」の3段階で判定され、サイト全体のUX健康診断書のような役割を果たします。

2020年のWeb Vitals発表以降、Googleは段階的に指標を更新してきました。2021年からPage Experienceシグナルとしてランキング要因化、2023年にFID(First Input Delay)からINPへ置き換え、2024年3月にINPが正式指標として組み込まれた、こういう経緯です。指標自体も「実際のユーザー体験により近いもの」に進化し続けています。

Core Web Vitalsの真の価値はSEOスコアではなく、「訪問者の離脱を未然に防ぐUX診断装置」として機能する点です。3指標いずれかが「不良」だと離脱率が顕著に上がり、CVRも下がります。スコアを追いかけることが目的ではなく、訪問者の体感を整えて、サイトの本来の役割(集客・販売・問い合わせ)を達成することが本質です。

なぜGoogleはCore Web Vitalsを導入したのか

もう少し深く掘ります。なぜGoogleはわざわざ「Core Web Vitals」という新しい指標体系を作ったのか。背景を整理します。

従来のページ表示速度指標は「Page Load Time」「DOMContentLoaded」など、技術寄りの計測値が中心でした。でも、これらの数字が良くても「実際の使い心地は悪い」というケースが大量に発生していたんですよね。例えばページのロードは速いのに、画像が後から差し込まれて読みかけのテキストが下にズレる、ボタンを押しても反応がない、こういう不快感は従来の指標では捕まえられませんでした。

そこでGoogleが2020年に発表したのが「Web Vitals」の概念。「ユーザーが実際に感じる体験品質を、機械が測定できる形に落とし込む」という思想です。中でも特に重要な3指標を「Core(中核)」として定め、Search ConsoleやChrome DevToolsで標準計測できるようにしました。これがCore Web Vitalsの誕生経緯です。

業界の体感として、Core Web Vitalsの導入は段階的にSEO影響を強めてきました。2021年6月のPage Experienceアップデートでモバイル検索のランキング要因に追加、2022年2月にデスクトップ検索にも拡大、2024年3月のINP正式採用、こういう流れで「無視できない指標」へと格上げされた経緯があります。

近年では、Lighthouse・PageSpeed Insights・Search Console・CrUX(Chrome User Experience Report)など、各種計測ツールがすべてCore Web Vitalsを中心に再設計されています。Web運営者にとって、もう避けて通れない指標として定着しました。

業界の進化として、Core Web Vitalsの指標自体も進化を続けています。FIDからINPへの置き換えは、「初回入力のみ測定」から「ページ滞在中すべての操作応答を測定」へと範囲が広がった事例。今後もユーザー実体験により近い指標が追加・更新されていく方針が、Google公式から明言されています。

うちで観察していて面白いのは、Core Web Vitalsが「Webサイトの作り方そのもの」を変えてしまった点。画像の遅延読み込み、CSS・JSの最適化、フォントの読み込み戦略、こういう実装パターンがすべてCore Web Vitalsの数値改善を念頭に設計されるようになりました。Googleが指標を作ることで、Web業界全体の標準が動く、これがすごい影響力ですよね。

LCP・INP・CLSが現場で意味するもの

3指標それぞれが、現場で具体的に何を測っているのか。1つずつ深掘りします。

LCP(Largest Contentful Paint):主要コンテンツが表示されるまでの時間

LCPは「ページ内で最も大きな要素が表示されるまでの時間」を測ります。多くの場合、ヒーロー画像・メインビジュアル・記事タイトル直下の大きな画像、これらが対象になります。訪問者が「あ、このページ開いた」と認知する瞬間を機械的に捕まえる指標です。

合格ラインは2.5秒以下。2.5〜4秒が「要改善」、4秒超が「不良」判定。うちで運用していて、LCPが3秒を超えるとフォーム送信率が明確に下がる傾向を観察しています。表示が遅いと、訪問者は「読む価値があるか判断する前」に離脱してしまう、こういう現象がデータに出ます。

INP(Interaction to Next Paint):操作してから画面が反応するまでの時間

INPは「ユーザーがクリック・タップ・キー入力した直後に、画面が応答するまでの時間」を測ります。2024年3月に正式採用された新しい指標で、ボタンを押して何も起きない時間、フォームに文字を打って画面が固まる時間、こういう「不快な待ち時間」を捕まえます。

合格ラインは200ミリ秒以下。200〜500msが「要改善」、500ms超が「不良」判定。うちで観察していて意外だったのは、LCPが良好でもINPが悪いサイトが多いこと。ファーストビュー表示は速いのに、ボタンを押すと固まる、こういう「途中で止まる体験」がINPで露呈します。JavaScriptの実行コストが重い、こういう原因が多い領域です。

CLS(Cumulative Layout Shift):ページのレイアウトが予期せずズレる量

CLSは「ページ読み込み中に、表示中の要素が予期せず動いた量の累積値」を測ります。読みかけの文章が画像の後読み込みで下にズレる、ボタンを押そうとした瞬間に広告が差し込まれて誤クリック、こういう「視覚的なガタつき」を数値化します。

合格ラインは0.1以下。0.1〜0.25が「要改善」、0.25超が「不良」判定。うちでCLSが悪化する典型は、(1)画像のwidth/height未指定、(2)Webフォントの遅延読み込み、(3)後から差し込まれる広告・通知バナー、この3つです。技術的には対応しやすい指標で、最初に手をつける場所として優先度が高い領域です。

3指標の関係性:UXを「読み込み」「応答」「安定性」の3軸で評価する

3指標は独立した観点でUXを測ります。LCPは「ページが開く速さ」、INPは「操作の応答性」、CLSは「視覚的な安定性」。1つでも悪いと体感品質が崩れる、こういう設計です。

うちで実感しているのは、3指標すべてが「良好」に達するには、サイトの設計思想からの見直しが必要だということ。LCPだけを直してもINPが悪い、INPを直してもCLSが残る、こういうパターンが頻発します。Core Web Vitalsは「総合的なUX設計力」が問われる指標体系です。

CrUX(実ユーザーデータ)とLighthouse(ラボデータ)の違い

Core Web Vitalsの数値には2系統あります。Lighthouseが計測する「ラボデータ」(理想環境での測定値)と、CrUXが収集する「実ユーザーデータ」(実際のChromeユーザーから集めた数値)。SEOランキングに影響するのは後者のCrUX、Search Consoleに表示されるのもCrUXの数値です。

ここがうちで初学者によく説明する盲点。Lighthouseで「90点取れた」と喜んでも、実ユーザーの体感が悪ければCrUXは「不良」のまま、SEO評価も上がりません。Lighthouseは改善の方向性確認用、CrUXは本番評価用、こういう使い分けが業界の標準的な運用です。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

飲食店で考えてみます。あなたがランチで初めての定食屋に入った、と仮定します。お店の体験品質を測るとしたら、何を見ますか?

3つの観点があるんですよね。(1)入店してからメニューが出てくるまでの時間、(2)注文してから料理が運ばれてくる速さ、(3)料理が運ばれる時に皿がズレたり水がこぼれたりしないか。この3つで「このお店、また来たい」「もう来ない」が決まります。

これ、まんまCore Web Vitalsなんです。(1)メニューが出るまでの時間=LCP(主要コンテンツ表示)、(2)注文への応答速度=INP(操作応答)、(3)皿のズレ・水のこぼれ=CLS(レイアウトの安定性)。ユーザーが体感する「待たされた」「反応がない」「不快」の3要素を、機械が測定できる形に落とし込んだのがCore Web Vitalsという指標体系です。

定食屋で考えると、3つすべてが揃って初めて「気持ちよく食事ができた」になりますよね。メニューは早く出てきたけど料理が30分待たされた、料理は早かったけど皿が傾いていた、こういう「片方は良いけど片方がダメ」では、お客さんは満足しません。Core Web Vitalsも同じで、LCPだけ良くてもINPが悪ければ離脱されます。

うちで運用していて実感するのは、Core Web Vitalsの「合格ライン」を全部クリアするのと、3つのうち2つだけクリアするのでは、訪問者の体感がまったく違うこと。定食屋の例で、3つすべて完璧な店と、2つは完璧で1つだけ少し悪い店、リピート率が大きく変わるのと同じ構造です。3指標すべてを「良好」域に持っていく投資が、CVR改善に直結します。

もう一つ、定食屋の比喩で押さえておきたいのが「測定する時間帯」の話。お昼のピーク時に測ると遅いけど、深夜に測れば速い、こういう店があります。Core Web Vitalsも同じで、Lighthouse(理想環境=深夜の閑散時)で測れば良好でも、CrUX(実ユーザー=お昼のピーク時)で測ると不良、こういうことがあるんです。実際のお客さん体験を反映するのはCrUXのほう、これを優先する目線が決定的です。

Core Web Vitals改善の3指標別アプローチ

アプローチ1:LCP改善は「画像最適化」と「サーバー応答」の二段攻め

LCPが悪い場合、原因の8割が画像関連です。ファイルサイズの肥大、適切なフォーマット(WebP/AVIF)未使用、遅延読み込み未対応、こういう要因がLCPを直接押し下げます。対策は、画像の圧縮・WebP変換・width/height指定・preload属性の活用、この4点セットです。

残り2割の原因はサーバー応答速度。TTFB(Time to First Byte)が500ms超だと、その時点でLCPが厳しくなります。サーバーキャッシュの導入、CDN活用、データベースクエリの最適化、こういう対策が必要。うちで運用していて、LCPが2.0秒を切ったサイトはほぼ例外なくCDN(CloudFlareなど)を導入しています。

アプローチ2:INP改善は「JavaScriptの軽量化」が9割

INPが悪い場合、ほぼJavaScript起因です。重いJSライブラリの過剰読み込み、メインスレッドをブロックする処理、サードパーティタグの遅延実行不足、こういう要因が「ボタンを押しても反応しない」体験を生みます。対策は、不要なJSの削除・コード分割・defer/async属性の活用・Web Workerでの重い処理の分離、この4点です。

うちで観察していて、INPの改善は最も技術的に骨が折れる領域です。LCPやCLSは静的な対策で済むことが多いんですが、INPは動的な処理の最適化が必要で、エンジニアリングコストが高い。WordPressサイトの場合、プラグインの数を減らすこと、これが地味に効きます。

アプローチ3:CLS改善は「予測可能な領域確保」が決定打

CLSが悪い場合、原因のほとんどは「後から差し込まれる要素」です。画像・iframe・広告・通知バナー、これらが領域確保なしに表示されると、既存要素が押し下げられてレイアウトがズレます。対策はシンプルで、すべての挿入要素に「width × height」を事前指定すること、これだけで大半が解決します。

うちで運用していて、CLSは3指標の中で最も対策が見えやすい領域。具体的には、(1)imgタグにwidth/height属性追加、(2)Webフォントにfont-display: swap指定+サイズ調整、(3)広告枠に固定heightを設定、この3点で多くのケースは「良好」域に入ります。技術的なコストが低いので、最初に着手する優先度が高い指標です。

Core Web Vitals対応で失敗する典型3パターン

うちでCore Web Vitalsを8年運用してきた中で、繰り返し見てきた失敗パターンはこの3つに集約されます。

うちで運用してわかった本音

うちの事業でCore Web Vitalsを5サイト×8年運用してきて、見えてきた本音をお伝えします。

本音1:CLSから手をつけるのが投資対効果が一番高い

3指標の改善で、うちが最初に手をつけるのは必ずCLSです。理由は単純で、技術コストが低く、効果が出やすいから。imgタグにwidth/heightを追加する、Webフォントの読み込みを調整する、広告枠に固定領域を確保する、こういう作業は数時間で終わります。それでCLSが「不良」から「良好」に動くケースが多いんです。

LCPやINPは、画像最適化やJS削減で1日〜数日かかります。CLSを先に倒しておくと、その後のLCP・INP対応に集中できる。優先順位はCLS→LCP→INPの順がうちの定石です。Core Web Vitalsを初めて改善する方には、必ずこの順番を勧めます。

本音2:WordPressサイトはプラグイン数が最大のINP悪化要因

うちの5サイトはすべてWordPressで運用していますが、INP悪化の主因は明らかに「プラグイン過多」です。便利だからと20個・30個と入れていくと、各プラグインが独自にJSを読み込み、サイト全体のメインスレッドがブロックされます。INPが500msを超える典型例がこのパターン。

うちで運用していて、サイトあたりのプラグイン数を10個以下に絞った時点で、INPが200ms前後に安定する経験を何度もしました。プラグインの追加は「便利」と「速度」のトレードオフです。新規プラグインを入れる前に、「これは本当に必要か」「既存機能で代替できないか」を毎回問う運用が、長期的なINP維持の決定打になります。

本音3:Core Web Vitalsの数値とCVRは必ずしも線形に連動しない

これは8年間の運用で実感した本音なんですが、Core Web Vitalsの数値とCVRは、必ずしも線形に連動しません。LCPが3.5秒から2.0秒に下がっても、フォーム送信率が変わらないケースが頻発します。逆に、LCPが3.0秒のままでも、コンテンツの質を上げたらCVRが2倍になった事例もあります。

具体的に、うちで観察したパターンは5つ。(1)LCP4秒超は明確に離脱増、(2)LCP2.5〜4秒は離脱率は微増、CVRはほぼ変わらず、(3)LCP2.5秒以下では、それ以上の改善はCVRに反映されにくい、(4)INPは500ms超で離脱増、200ms以下なら影響少、(5)CLSは0.25超で誤クリック増、0.1以下なら影響少。この5要素を頭に入れておくと、改善投資の判断がしやすくなります。

合格ライン(LCP 2.5秒・INP 200ms・CLS 0.1)を超えたあとは、技術投資の優先度が下がります。そこから先は、コンテンツの質・導線設計・オファー設計、こういう「Webサイトの中身」の改善が、CVRに直結する領域です。Core Web Vitalsを完璧にしてもCVRが上がらないなら、別の要因に課題がある可能性が高い、この視点を持つことが業界での経験則です。

もう一つ、うちで運用していて感じる本音は、Core Web Vitalsは「サイト立ち上げ時に基盤を整える」のがコスト最安だということ。サイト構築後に後から改善するのは、画像差し替え・コード書き換え・プラグイン整理など、膨大な手間がかかります。新規サイトを作る時に、設計段階からCore Web Vitalsを念頭に置く、これが業界で生産性を上げる決定打です。

Core Web Vitals改善を進める実装5ステップ

ここまで読んでくださった方、お疲れさまです。Core Web Vitals改善を始めるための実装5ステップを置いておきます。

シンプルですが、この5ステップでCore Web Vitalsを「良好」域に持っていく骨格が完成します。重要なのは順番で、CLS→LCP→INPの順に進めると、技術コスト対効果が最大化されます。

よくある質問(FAQ)

まとめ

で、結局Core Web Vitalsとは、こういうことです。

• Core Web Vitalsの核心は「速度指標」ではなく「UX体感を3軸で定量化したGoogle公式の診断装置」
• 本質はSEOスコアではなく、訪問者の離脱を未然に防ぐためのUX健康診断
• 3指標(LCP・INP・CLS)それぞれに別アプローチが必要で、CLS→LCP→INPの順に着手するのが投資対効果が高い

数値スコアを追いかけることが目的ではなく、訪問者の体感を整えてサイトの本来の役割(集客・販売・問い合わせ)を達成すること。これがCore Web Vitalsの本来の使い方です。検討しているなら、Search Consoleで現状把握から始めてみてください。

ではでは。