アーム代表の伊藤です。
Core Web Vitalsが見ているのは、読み込みの速さ・操作への反応・表示の安定の3つだけです。
合格ラインはLCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です（Google公式の基準。FIDは2024年3月にINPへ置き換え済み）。
この記事では、3指標それぞれの意味と悪化の原因、具体的な直し方、数値を無料で確認する方法に加えて、依頼先を見極める材料としての使い方までを順番に整理します。
合格ラインはLCP2.5秒・INP200ミリ秒・CLS0.1以下。満点は要らない
- 判定基準は実ユーザーの75パーセンタイル値
- 集計はモバイルとデスクトップを別々に評価
- 遅い環境が多いと要改善判定になる
自分のサイトの数値をこの表に当てはめれば、どの指標が問題なのかがすぐに分かります。◎良好（合格）・△要改善・×不良の3段階で、LCP・INP・CLSのしきい値をまとめました。
指標 | 何を測るか | しきい値 |
|---|---|---|
LCP | 主要コンテンツの表示（読み込み） | 2.5秒以下・△〜4.0秒・×4.0秒超 |
INP | 操作への反応（応答性） | 200ミリ秒以下・△〜500ミリ秒・×500ミリ秒超 |
CLS | 表示のガタつき（視覚的安定性） | 0.1以下・△〜0.25・×0.25超 |
（良好の基準の出典: Google 検索セントラル「Core Web Vitals」、3段階のしきい値の出典: web.dev「Web Vitals」、INPの各値の出典: web.dev「Interaction to Next Paint（INP）」）
合否は「75パーセンタイル値」で判定されます
これらの数値はページの読み込みの75パーセンタイル値で評価されます（出典: web.dev「Web Vitals」）。
集計は実際のユーザーの記録（フィールドデータ）をもとに、モバイルとデスクトップを分けて行われます。一部の高速な環境で合格していても、遅い端末や回線での読み込みが多ければ「要改善」と判定されます。
Core Web Vitalsとは、自社サイトの「重い」を数値にした3指標
- 日本語表記はウェブに関する主な指標
- 順位の一要素だが上位を保証しない
- FIDは2024年3月にINPへ置換済み
Core Web Vitals（コアウェブバイタル）とは、ページの「読み込みの速さ」「操作への反応の速さ」「表示の安定性」という、実際のユーザー体験の質を数値で表したGoogleの指標です。日本語では「ウェブに関する主な指標」と表示されることもあります。
血圧・血糖値のように、3指標をセットで見る理由
健康診断でいう血圧・血糖値・体重のようなもの、と考えると分かりやすいです。どれか一つを見るだけでは体調は分かりませんが、3つ揃えて見ると「どこに無理がかかっているか」が見えてきます。
Core Web Vitalsも、次の3つの指標をセットで見ることで、サイトの体験のどこに問題があるかを切り分けられます。
- LCP（読み込み）: メインの画像や見出しなど、大きなコンテンツが表示されるまでの速さ
- INP（反応）: クリックやタップに、画面が反応するまでの速さ
- CLS（安定性）: 読み込み中に、ボタンや文字がガタッとずれない安定性
この3指標は、Googleが検索順位を決めるときに考慮する要素のひとつとして公式に位置づけられています（出典: Google 検索セントラル「Core Web Vitals と Google 検索の検索結果について」）。
ただしGoogleは、ページエクスペリエンスについて「単一のシグナルはない」と述べ、Core Web Vitalsが良好でも検索結果の上位表示が保証されるわけではないと明記しています（出典: Google 検索セントラル「ページエクスペリエンス」）。
Core Web Vitalsは順位を約束する数値ではなく、ユーザーが中身に出会うための土台の数値です。
よくある誤解: 「FID」はもう使われていない（2024年3月にINPへ）
Core Web Vitalsを調べると、いまだに「LCP・FID・CLS」と説明している記事が数多く見つかります。ここが最初のつまずきポイントなので、先に整理しておきます。
FID（First Input Delay）は、2024年3月12日にINPへ置き換わりました（出典: web.dev「Interaction to Next PaintがCore Web Vitalになります」）。
現在Googleが公式に示すCore Web Vitalsの3指標は、LCP・INP・CLSです（出典: Google 検索セントラル「Core Web Vitals と Google 検索の検索結果について」）。
FIDは「最初のクリックが反応するまでの遅れ」だけを見ていました。
INPはその後継で、最初の1回だけでなく、ページ滞在中に行われた操作全体の反応の速さを見ます（出典: web.dev「Interaction to Next Paint（INP）」）。
FIDより現実のストレスを正確にとらえる指標に進化した、と理解すれば十分です。もし「FID」で解説している記事を見かけたら、情報が更新されていない可能性が高いです。指標名を読み替えて読んでください。
内部SEO対策の3領域のうち、Core Web Vitalsが担うのは1つだけ
Core Web Vitalsは、内部SEO対策（テクニカルSEO）の3領域のうちページエクスペリエンスという1区画を測る指標です。検索順位を左右する要素の全部ではありません。
領域 | 目的 | 代表的な施策 |
|---|---|---|
クロール最適化 | 検索エンジンに見つけてもらう | 内部リンク・サイトマップ |
インデックス最適化 | 検索結果に登録してもらう | タイトル・見出し・重複整理 |
ページエクスペリエンス | 快適に使ってもらう | 表示速度・モバイル対応・HTTPS化 |
クロール・インデックスはページエクスペリエンスより前の工程で、Core Web Vitalsの直接の対象ではありません。検索エンジンにまだ登録されていないページの表示速度をいくら磨いても、検索結果に出ない以上は順位に反映されないので、まず「見つけてもらう」「登録してもらう」が成立したうえで、この記事の改善が数字に反映されてきます。表示速度の改善そのものの手順は、サイトの表示速度改善｜目安はLCP2.5秒、重い原因の切り分けと直し方のコラムに整理しています。
LCP・INP・CLSの意味と、悪化の原因・直し方
- LCPは画像をWebP/AVIF化で1秒短縮
- INPの主犯はJavaScriptの重さ
- CLSは幅と高さの指定で改善する
3つの指標を、意味・悪化する主な原因・直し方とゴールの順に1枚ずつまとめます。
LCPとは。2.5秒を超えると不良判定になる
LCP（Largest Contentful Paint）とは、ページを開いてから、画面内でいちばん大きなコンテンツ（多くはメイン画像や大きな見出し）が表示されるまでの時間です。合格ラインは2.5秒以下。
ユーザーが「このページ、ちゃんと開いたな」と感じるまでの速さ、と考えてください。
悪化する主な原因
- 大きすぎる画像（撮影したままの重い画像をメインビジュアルに使っている）
- サーバーの応答が遅い（安価な共有プランで、最初の反応が返ってくるまでに時間がかかる）
- CSSやJavaScriptが表示をブロックしている（本文が出る前に、大量のファイルの読み込みを待たされている）
直し方とゴール
最も効果が高いのは画像対策です。メインビジュアルの画像をWebPやAVIF（※JPEGやPNGより軽い新しい画像形式）に変換します。表示サイズに合わせて圧縮するだけで、LCPが1秒以上縮むことも珍しくありません。
あわせて、そのメイン画像だけは遅延読み込み（後回しの読み込み）の対象から外すのがコツです。いちばん見せたい画像を後回しにすると、かえってLCPが悪化します。
ゴールの置き方はシンプルで、まずLCP 4.0秒超（不良）のページを2.5秒以下（良好）に引き上げることを最優先にします。すでに2.5秒を切っているページを1秒速くする労力より、遅いページを合格ラインに乗せる労力のほうが、体験にも数値にもはるかに大きく表れます。
INPとは。押したのに反応しないストレスの正体
INP（Interaction to Next Paint）とは、ユーザーがクリックやタップ、キー入力をしてから、画面が反応して次の表示に切り替わるまでの速さです。合格ラインは200ミリ秒以下。
ボタンを押したのに一瞬固まる、あの「押したのに反応しない」ストレスを数値化した指標です。
Chromeの使用状況データによると、ユーザーがページで費やす時間の90%は、ページが読み込まれた後だとされています（出典: web.dev「Interaction to Next Paint（INP）」）。
だからこそ、読み込みの速さ（LCP）だけでなく、操作の反応（INP）まで見る必要がある、というのがFIDから進化した理由です。
悪化する主な原因
INPの主犯は、ほとんどの場合JavaScriptの重さです。クリックに対する処理が重かったり、裏で動くスクリプトがブラウザの処理を占領していると、反応が遅れます。運用の中で足し続けたチャットツール、アクセス解析、広告タグなどが積み重なっているケースが典型です。
直し方とゴール
コードを触らない範囲では、今も使っているか分からないタグ・スクリプトの棚卸しが第一歩です。停止したまま残っているプラグイン、誰も見ていない計測タグを外すだけで、反応が軽くなることがあります。
実装に踏み込める場合は、重い処理を細かく分割する、使っていないJavaScriptを読み込まない、といった対策が有効です。
ゴールはINP 500ミリ秒超（不良）のページを、まず200〜500ミリ秒（要改善）へ、最終的に200ミリ秒以下（良好）へ。フォームやメニューなど、ユーザーが必ず操作する部分から優先して直すと、体験の改善を実感しやすくなります。
CLSとは。ボタンがずれて誤タップさせる原因
CLS（Cumulative Layout Shift）とは、読み込みの途中で、ボタンや文字、画像の位置がどれだけガタッとずれるかを表す指標です。合格ラインは0.1以下。
押そうとしたボタンが直前にずれて、別のリンクを押してしまう、あの不快さを数値化したものです。時間（秒）ではなく、ずれの大きさを示す数値である点が、他の2つと違います。
悪化する主な原因
- 画像や動画に、表示領域（幅と高さ）が指定されていない（読み込まれた瞬間に場所を確保して、下の要素を押し下げる）
- 広告やSNS埋め込みが、後から割り込んで表示される
- Webフォントの切り替わりで、文字が一瞬で入れ替わる
直し方とゴール
CLSは、原因がはっきりしていて直しやすい指標です。まずすべての画像・動画に幅と高さ（表示領域）を指定すること。これだけで大きく改善するケースが多くあります。広告やバナーには、あらかじめ表示スペースを予約します。
Webフォントは、読み込み中も文字が消えない設定にします。いずれも「後から割り込ませない」「先に場所を確保する」という考え方で共通しています。
ゴールは0.1以下。CLSは一度直せば戻りにくいので、費用対効果が高い指標です。
直したら、無料ツールで数値を確認する
直し方が分かったら、まず自社サイトの現状を測ります。感覚で「重い気がする」と手を動かすと、関係のない場所を直して時間だけが溶けます。無料で使える確認方法は2つです。
Google Search Console「ウェブに関する主な指標」
すでにSearch Consoleを導入しているなら、左メニューの「ウェブに関する主な指標」を開くのがいちばん早い方法です。
実際のユーザーの環境で集計されたデータをもとに、「良好」「要改善」「不良」のページ数がまとめて表示され、どのページ群に問題があるかを一覧で把握できます。サイト全体の健康状態を俯瞰したいときに向いています。
PageSpeed Insightsで1ページずつ深掘りする
個別のページを詳しく見たいときは、Googleが無料で提供するPageSpeed InsightsにURLを入れて「分析」を押します。ここで理解しておきたいのが、2種類のデータの違いです。
- 実際のユーザーのデータ（フィールドデータ）: 過去28日間の実ユーザーの記録。Core Web Vitalsの合否は、こちらで判定されます。
- 診断環境のデータ（ラボデータ）: その場で一定条件で測定した参考値。改善の作業直後にすぐ確認できるので、直しながら試すのに向いています。
結果画面には「このURL」と「オリジン」という切り替えがあります。「このURL」は入力したページ単体の、「オリジン」はサイト全体の集計です。
「データがありません」には、逃げ道がある
公開して間もないサイトや閲覧の少ないページでは、実際のユーザーのデータが十分に集まらず「データがありません」と表示されることがあります。
その場合はオリジンでサイト全体の傾向を見るか、診断環境のデータ（ラボデータ）を参考にしてください。改善に取り組んだ直後にフィールドデータが変わらなくても、慌てる必要はありません。実ユーザーのデータが反映されるには時間がかかるので、作業中はラボデータで手応えを確認し、最終判定はフィールドデータで見る、と使い分けてください。
トップページだけでなく、サービス紹介、料金、問い合わせフォームなど、成果に直結するページも忘れずに測ります。
指標の意味が分かったら、次は重い原因の切り分けと直し方です。
全指標を満点にする必要はない。ただし「不良」の放置は10%規模の離脱に直結する
- 合格基準は75パーセンタイル値の達成
- BBCは1秒遅いと10%が離脱と計測
- 不良を合格圏に乗せる方が効果大きい
目指すのは満点でも100点でもなく、ページの読み込みの75パーセンタイル値が合格ラインに収まっている状態です。
満点ではなく、「不良」を合格ラインに乗せる
Core Web Vitalsの話をすると、「3つとも完璧な数値にしないといけないのか」「PageSpeed Insightsで100点を取るべきか」と身構える方がいます。これは誤解です。
正しくは、目指すのはページの読み込みの75パーセンタイル値が合格ラインに収まっている状態であって、満点でも100点でもありません（出典: web.dev「Web Vitals」）。
スコアの数字を1点ずつ積み上げるより、「不良」を合格ラインに乗せるほうが事業の数字に効果は大きいと考えてください。
指標そのものより、どの体験を良くするか
数値の完璧さを追うのではなく、どの体験を良くすれば指標が動くのかから逆算します。この考え方は、UI/UX改善しても「使われない」のはなぜ？成果が出ない原因の切り分けと直し方を扱ったコラムでも書いたとおり、Core Web Vitalsに限らないアームの基本姿勢です。
なお、この記事はCore Web Vitalsという指標そのものの解説に絞りました。
表示速度が遅くなる原因の切り分けや、画像圧縮・キャッシュ・サーバー見直しといった改善の全体像は、前段の表示速度改善のコラムで詳しく整理しています。あわせて読むと、指標の理解から実際の改善までが一本につながります。
遅いと10%が離脱する。事業の数字に直結する3つの理由
Core Web Vitalsが重要なのは、ユーザーの離脱を左右し、問い合わせや売上という事業の数字に直結するからです。そのうえで、Googleの検索評価やAI検索の土台にもなります。順に見ていきます。
1. 遅い・不安定なだけで、ユーザーは離脱する
体感の悪さは、数字にはっきり表れます。BBCは、サイトの読み込みが1秒延びるごとにさらに10%のユーザーを失うことを自社の計測で確認しています。
Core Web Vitalsを改善して成果を出した事例もあり、redBusは自社サイトのINP（操作への反応）を改善したのち売上が7%伸び、The Economic TimesはCore Web Vitalsの合格ラインを満たしたのち直帰率が全体で43%改善しています（出典: Google web.dev「速度が重要な理由」、2023年11月時点）。
いずれも各社の自社計測の結果で、同じ効果がどのサイトでも出るという保証はありません。中身がどれだけ良くても、入り口で待たされたりガタついたりするだけで、読まれる前に去られてしまいます。Core Web Vitalsは、それくらい手前にある課題です。
2. Core Web Vitalsは内部SEO対策の評価要素になっている
Core Web Vitalsは、Googleが検索順位を決めるときに考慮する要素のひとつと公式に位置づけられています（出典: Google 検索セントラル「Core Web Vitals と Google 検索の検索結果について」）。
あわせてGoogleは、Core Web Vitalsが良好でも上位表示は保証されないこと、同等に役立つページが複数ある場合には良いページエクスペリエンスが寄与し得ることを説明しています（出典: Google 検索セントラル「ページエクスペリエンス」）。
アームは実務上、合格ラインを超えていれば十分という距離感で捉えています。
3. AI検索（LLMO）の時代も、速さと安定が土台になる
もうひとつ、これからの視点があります。ChatGPTやGoogleのAI検索が、サイトの内容を読み取って回答に引用する場面が増えています。
取得に時間がかかる、表示が不安定といったサイトは、その分だけ内容を正しく届ける機会を逃しやすくなります。Core Web Vitalsは、人間のユーザーだけでなく、AIに内容を届けるうえでも土台になります。アームがSEOとLLMOをセットで考える理由のひとつです。
依頼先を選ぶときは、相手のサイト自体の速さも見ておく
- 実力は言葉でなく自社サイトに出る
- デザインの好みより数値は比較しやすい
- 確認は無料ツールで数秒で終わる
制作会社やフリーランスに依頼を検討しているなら、相手の会社自身のサイトをPageSpeed Insightsに入れてみるのも、判断材料のひとつになります。
公開されている発注相談を見ていると、見積もりの金額や実績の数だけでなく「提案してきた相手のポートフォリオサイト自体が重くて開きにくい」という違和感が、依頼をためらう理由になっている場面があります。デザインの良し悪しは好みが分かれますが、表示速度は数値で比較できるぶん、判断に迷ったときの拠り所になりやすいところです。
遅い＝下手、と即断はできない
もちろん、遅いからといって技術力がないと即断はできません。あえて重い演出を選んでいる場合もあります。それでも自分たちが日々見ているサイトの数値に無頓着な相手が、依頼主のサイトの数値には気を配ってくれるとは考えにくいというのは、ひとつの目安になります。
アームでは、設計の時点で速さと安定性をデザインの一部として扱っています（詳しくは次の章で説明します）。依頼を検討している方は、このコラムで紹介した確認方法を、そのまま相手のサイトにも使ってみてください。
Core Web Vitalsを満点にしても問い合わせは増えない。アームの向き合い方
- 速さと安定性は設計段階で決まる
- 満点でも問い合わせ増加とは限らない
- 実装後にLCPが悪化した例がある
ここからは、アームがこの指標をどう捉えているかをお伝えします。
速さや安定性は、公開後ではなく設計段階で決まる
Core Web Vitalsの3指標は、公開してから頑張って上げるものではなく、デザインと情報設計の段階でほぼ決まります。この演出は必要か、この画像はこのサイズで載せる意味があるか、この要素に表示領域を確保してあるか。
アームは設計の時点で、速さと安定性をデザインの一部として扱います。無駄のない構造は、結果として速く、ガタつきません。機能美を好むアームのデザイン観とも地続きです。
設計段階から使われ方を見る考え方は、UI/UXの改善全般にも共通します。
指標は「選ばれる理由」の土台にすぎない
正直に言えば、Core Web Vitalsを満点にしても、それだけで問い合わせが増えるわけではありません。速く安定して表示されることは、あくまでユーザーが中身に出会うための入り口です。
大事なのは、その入り口の先で、「このサイトに相談したい」と思ってもらえる中身になっているか。
数値を整えた先で問われるもの
AIやノーコードで見た目のいいサイトが誰でも作れる時代だからこそ、指標を整えたうえで「それが選ばれる理由になっているか」まで問うのが、アームの立ち位置です。数値はゴールではなく、体験と事業の成果から逆算する出発点だと考えています。
Core Web Vitalsは、誰にも褒められない仕事です。読み込みが速くても訪問者は気づきませんし、指標が良好でも表彰されることはありません。それでもここに手を抜かないのは、見えない基盤の質が結局は見える部分の信頼を支えているからです。
一気通貫だから、原因の切り分けが速い
Core Web Vitalsの悪化は、画像なのか、実装なのか、サーバーなのか、そもそもの設計なのか、領域をまたいで潜んでいます。
過去にアームがサイトを引き継いだ案件でも、デザインカンプの段階では美しかった演出が、実装されると積み重なってLCPを押し上げていたケースがありました。
分業の切れ目が、そのまま無駄な工事になる
分業体制では「デザインの問題か実装の問題か」の切り分けだけで往復が発生しがちですが、アームは課題を直接聞いたデザイナーが設計から実装まで見る一気通貫体制です。切り分けが速いぶん、無駄な工事をせずに済みます。
ホームページからSEO・LLMO対策までの提供サービスの詳細もあわせてご覧ください。
Core Web Vitalsや表示速度の改善について相談する
よくある質問
Core Web Vitalsの読み方と意味を教えてください。
「コアウェブバイタル」と読みます。ページの読み込み・操作反応・表示の安定性という、実際のユーザー体験の質を数値化したGoogleの3指標（LCP・INP・CLS）のことです。Google検索の評価要素のひとつにもなっています。
Core Web Vitalsの3つの指標と合格ラインは何ですか？
LCP（読み込み）が2.5秒以下、INP（操作への反応）が200ミリ秒以下、CLS（表示のガタつき）が0.1以下が、それぞれの合格ラインです。判定は、実際のユーザーの記録をもとにしたページの読み込みの75パーセンタイル値で行われます。
FIDとINPは何が違うのですか？
FIDは最初の1回の操作の反応だけを見ていた旧指標で、2024年3月にINPへ置き換わりました。INPはページ滞在中のすべての操作の反応を見るため、現実のストレスをより正確にとらえます。今の3指標はLCP・INP・CLSで、FIDは使われていません。
Core Web Vitalsはどこで確認できますか？
Google Search Consoleの「ウェブに関する主な指標」か、無料のPageSpeed InsightsにURLを入れて確認します。合否は「実際のユーザーのデータ（フィールドデータ）」で判定されるため、まずそちらを見てください。
PageSpeed Insightsで「データがありません」と表示されるのはなぜですか？
実際のユーザーのデータ（フィールドデータ）は過去28日間の閲覧から集計されるため、公開して間もないサイトや閲覧の少ないページでは表示されないことがあります。その場合は「オリジン」（サイト全体の集計）に切り替えるか、診断環境のデータ（ラボデータ）を参考にしてください。
Core Web VitalsはSEOにどのくらい影響しますか？
Googleは検索順位を決める要素のひとつと公式に位置づけていますが、良くするほど順位が上がる魔法ではありません。「遅すぎる・不安定すぎると足を引っ張る」に近い性質です。順位のためというより、離脱率や問い合わせという事業の数字のために改善する価値があります。
Core Web Vitalsは内部SEO対策やテクニカルSEOとどう違いますか？
内部SEO対策（テクニカルSEO）は、サイトの内側を検索エンジンとユーザーに正しく届く状態へ整える施策全体を指す、大きな枠です。
Core Web Vitalsは、その中のページエクスペリエンスという領域でユーザー体験の質を測る3つの指標を指します。別物ではなく、内部SEO対策の一部にCore Web Vitalsが含まれる、という包含関係です。
3つの指標は、どれから直すべきですか？
「不良」と出ている指標から着手するのが基本です。多くのサイトではLCP（画像やサーバー）とCLS（表示領域の指定）が直しやすく、効果も出やすい傾向があります。INPは原因がJavaScriptにあることが多く、実装の見直しが必要になる場合があります。
Core Web Vitalsは、全指標満点でなく不良の指標を合格ラインに乗せれば進む
Core Web Vitalsは、読み込み（LCP）・操作への反応（INP）・表示の安定性（CLS）の3指標です。合格ラインはLCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下。古い記事の「FID」は2024年3月にINPへ置き換わっています。
まずSearch ConsoleかPageSpeed Insightsで数値を確認し、「不良」と出ている指標から、画像・タグ・表示領域の指定と、直しやすいところに着手してください。
全指標を満点にする必要はありません。遅い・不安定なページを合格ラインに乗せることを優先すれば、Core Web Vitalsの改善は着実に前へ進みます。
