表示速度・Core Web Vitals改善【2026年】｜INPで変わったUX評価をやさしく解説
Core Web Vitalsの3指標(LCP 2.5秒・INP 200ミリ秒・CLS 0.1)を初心者にもわかりやすく解説。FIDからINPへの変更点、遅くなる原因、画像最適化やJS削減などの改善策、PageSpeed InsightsやSearch Console(CrUX)での計測方法、SEOとの本当の関係まで、2026年時点の実務目線でまとめました。
Core Web Vitalsとは｜3つの指標をやさしく整理
Core Web Vitals（コアウェブバイタル）は、Googleがユーザー体験の良し悪しを数値で測るために定めた指標群です。日本語のSearch Consoleでは「ウェブに関する主な指標」と表示されます。難しく見えますが、要は「ページはすぐ表示されるか」「操作にすばやく反応するか」「表示中に画面がガタつかないか」という、訪問者が体感する快適さを3つの角度から数値化したものです。 2026年時点で計測対象となる指標は、LCP（読み込みの速さ）・INP（操作への反応性）・CLS（表示の安定性）の3つです。かつて反応性の指標はFID（First Input Delay）でしたが、2024年3月にINP（Interaction to Next Paint）へ正式に置き換わりました。この変更は本記事の中心テーマなので、後ほど詳しく説明します。 重要なのは、これらの指標が「実際にサイトを訪れたユーザーの端末で測った体験」に基づいて評価される点です。開発者のPCだけで速く見えても、通信環境やスマホの性能によっては遅い、という差を可視化してくれるのがCore Web Vitalsの役割です。
LCP（Largest Contentful Paint）｜表示の速さ
LCPは、ページを開いてから画面内で最も大きなコンテンツ（多くの場合はメインの画像や見出しの大きなテキスト）が表示されるまでの時間です。訪問者が「このページ、ちゃんと出たな」と感じるタイミングの目安になります。 良好とされる基準は2.5秒以内です。2.5〜4.0秒は「改善が必要」、4.0秒を超えると「不良」と判定されます。LCPが遅い主な原因は、重すぎる画像、遅いサーバー応答、表示を妨げるCSSやJavaScriptの読み込みなどです。
INP（Interaction to Next Paint）｜操作への反応性
INPは、ユーザーがボタンのクリックやタップ、キー入力などの操作をしてから、その結果として画面が次に更新（描画）されるまでの時間を測ります。ページ滞在中のあらゆる操作を対象にし、その反応の遅さを総合的に評価するのが特徴です。 良好とされる基準は200ミリ秒（0.2秒）以内です。200〜500ミリ秒は「改善が必要」、500ミリ秒を超えると「不良」です。数値が小さいほど「押したらすぐ反応する、きびきびしたサイト」ということになります。
CLS（Cumulative Layout Shift）｜表示の安定性
CLSは、ページ表示中にレイアウトが予期せずズレる量を数値化したものです。読もうとした瞬間に広告や画像が後から挿し込まれて文章が下にずれ、押すつもりのないボタンを誤タップしてしまう——あの不快な現象を防ぐための指標です。 良好とされる基準は0.1以下です。0.1〜0.25は「改善が必要」、0.25を超えると「不良」と判定されます。CLSは時間ではなくズレの割合を表す無単位のスコアで、値が小さいほど画面が安定していることを意味します。
FIDからINPへ｜何が変わり、なぜ重要になったのか
2024年3月、Core Web VitalsのうちFID（First Input Delay）が廃止され、INP（Interaction to Next Paint）が正式な指標に昇格しました。名前が変わっただけに見えますが、測っている内容には大きな違いがあります。ここを理解すると、なぜ最近「操作性」が重視されるのかが腑に落ちます。
FIDは「最初の操作の待ち時間」だけを見ていた
FIDは、ユーザーが最初に行った操作について、ブラウザがその処理を始めるまでの「待ち時間」だけを測る指標でした。つまり評価するのはページ表示直後の1回きり、しかも「反応が始まるまで」で、その後に画面がきちんと更新されたかは見ていません。 このため、実際には操作後の処理が重くて画面がなかなか更新されないサイトでも、FIDの数値上は良好に見えてしまうことがありました。ユーザーの実感と指標がズレる、という弱点があったのです。
INPは「操作への総合的な反応性」を見る
INPは、最初の1回だけでなくページ滞在中のほぼすべての操作を対象にし、しかも「操作してから実際に画面が次に描画されるまで」の全体を測ります。押した瞬間から目に見える結果が返るまでを丸ごと評価するため、ユーザーが感じる「もたつき」により忠実です。 つまりINPは、待ち時間だけでなく処理そのものの重さや描画の遅れまで含めた、操作への総合的な反応性を示します。FIDより厳しく、そして実感に近い指標になったと言えます。
INP対策が必要になるサイトの特徴
INPが悪化しやすいのは、JavaScriptで多くの処理を行うサイトです。クリックのたびに大量の計算をしたり、巨大なデータを一度に処理したり、サードパーティ製の重いスクリプト（チャット・解析・広告など）がメインスレッドを占有したりすると、操作後の描画が遅れてINPが伸びます。 対策の方向性は、重い処理を分割して少しずつ実行する、不要なスクリプトを削る、イベント処理を軽くする、といったものです。静的な内容が中心の一般的なコーポレートサイトであれば、そもそもJavaScriptを盛りすぎないことが最良のINP対策になります。
ページが遅くなる主な原因
改善策を考える前に、まず「なぜ遅いのか」を整理します。表示速度やCore Web Vitalsの悪化は、たいてい次のいくつかの原因が組み合わさって起きています。原因を特定せずに対策だけ足すと、効果が出ないまま作業が増えてしまうので、まずは切り分けが大切です。
重い画像とメディア
最も多く、そして最も効果が出やすい原因が画像です。撮影したままの数MBある写真をそのまま貼っている、表示サイズは幅400pxなのに元データは幅4000pxある、といったケースは珍しくありません。これはLCPを直接悪化させます。動画の自動再生や大量のアイコン読み込みも同様に負荷になります。
過剰なJavaScriptとサードパーティスクリプト
アクセス解析、広告、チャットボット、SNS埋め込み、各種プラグインなど、外部から読み込むスクリプト（サードパーティスクリプト）はページを重くする代表格です。これらはブラウザの処理を占有し、特にINPを悪化させます。1つ1つは便利でも、積み重なると操作のもたつきや表示遅延の原因になります。自作のJavaScriptが必要以上に大きい場合も同じです。
レイアウトシフトと遅いサーバー応答
サイズ指定のない画像や、後から挿入される広告・埋め込みはCLSを悪化させます。またWeb文字（Webフォント）の読み込み遅れで、表示途中に文字が入れ替わってレイアウトがずれることもあります。 もう一つ見落とされがちなのがサーバーの応答速度です。ブラウザが最初の応答（HTML）を受け取るまでの時間（TTFB）が長いと、そこから先の処理がすべて後ろにずれ、LCPも悪化します。安いだけで処理能力の低いサーバーや、毎回重い処理でページを生成する構成は、根本的なボトルネックになりがちです。
具体的な改善策｜画像・JS・フォント・配信・レンダリング
原因が見えたら、効果の大きいところから順に手を入れます。ここでは実務でよく使う改善策を、指標との対応がわかるように紹介します。すべてを一度にやる必要はなく、まずは画像最適化とサーバー・配信の見直しから着手すると費用対効果が高いことが多いです。
画像の最適化と遅延読み込み（LCP対策）
画像は次の3点を押さえるだけで大きく改善します。1つ目は形式で、WebPやAVIFといった軽量フォーマットに変換します。2つ目はサイズで、表示する幅に合わせて圧縮・リサイズし、さらにsrcsetやpicture要素で端末ごとに最適な解像度を配信します。3つ目は遅延読み込み（Lazy Loading）で、最初に見える範囲より下の画像はスクロールで近づいてから読み込ませ、初期表示を軽くします。 ただしファーストビューの主役画像（LCP対象になりやすい画像）は、遅延させず優先的に読み込むよう指定するのがコツです。ここを取り違えると、かえってLCPが遅くなります。
不要スクリプトの削減とフォント・CLS対策（INP/CLS対策）
まず、本当に必要な外部スクリプトだけに絞り込みます。使っていない解析タグや古いプラグインは削除し、残すものも読み込みタイミングを後ろにずらす（deferやasync、あるいは操作されてから読み込む）ことで、INPと初期表示を改善できます。 CLS対策としては、画像や動画に必ず幅・高さ（またはアスペクト比）を指定して表示領域をあらかじめ確保します。Webフォントは、読み込み中も代替フォントで文字を表示し（font-displayの調整）、切り替え時のズレを抑えます。広告や埋め込みを入れる場合も、あらかじめ枠の大きさを確保しておくと、後から要素が押し込まれてガタつくのを防げます。
キャッシュ・CDNとレンダリング方式（LCP/TTFB対策）
サーバー応答を速くするには、キャッシュとCDN（世界各地に配置された配信網）が効果的です。一度生成したページや画像をキャッシュして使い回し、ユーザーに近い拠点から配信することで、TTFBとLCPを短縮できます。 さらに根本的なのがレンダリング方式の選択です。毎回サーバーでページを組み立てる方式より、静的に生成しておいたページを配信する方式（SSGや、あらかじめ生成しておく構成）の方が高速です。HaLVision TechではNext.jsとReactを用い、静的生成やキャッシュ、画像最適化を前提に「初めから速い」実装を標準としています。CMSで作った後から速度対策を継ぎ足すのではなく、設計段階でCore Web Vitalsに配慮しておくほうが、結果的に手間もコストも抑えられます。
計測方法｜PageSpeed Insights・Search Console・CrUX
改善は「測って、直して、また測る」の繰り返しです。ここで押さえておきたいのが、速度データには2種類あるという点です。1つは開発環境で疑似的に測る「ラボデータ」、もう1つは実際の訪問者の端末で集めた「フィールドデータ（実ユーザーデータ）」です。Core Web Vitalsの合否判定に使われるのは後者です。
PageSpeed Insightsで単ページを診断する
PageSpeed Insightsは、URLを入力するだけでそのページのスコアと改善提案を表示してくれる無料ツールです。上部に表示される実ユーザーデータ（過去28日間の実測値）でLCP・INP・CLSの合否を確認しつつ、下部のラボデータと提案リストで「何が遅いのか・どう直すか」を具体的に把握できます。まず1ページを診断し、指摘の多い項目から手を付けるのが基本の流れです。
Search Consoleでサイト全体の傾向を見る
Google Search Consoleの「ウェブに関する主な指標」レポートを使うと、サイト全体のページを「良好・改善が必要・不良」に分類して確認できます。似た構造のページはまとめて評価されるため、どのテンプレート（商品ページ、記事ページなど）に問題が集中しているかを俯瞰でき、優先順位を付けやすくなります。個別ページの深掘りはPageSpeed Insights、全体傾向はSearch Console、と役割分担すると効率的です。
CrUX（実ユーザーデータ）が判定の基準になる
CrUX（Chrome User Experience Report）は、Chromeを使う実際のユーザーから匿名で集められた体験データです。PageSpeed InsightsやSearch Consoleが示す合否は、このCrUXの実測値に基づいています。だからこそ、開発者のPCで速く見えても、通信の遅い環境や性能の低いスマホで遅ければ評価は上がりません。「実際の来訪者にとって速いか」という視点で改善することが、最終的にCore Web Vitalsの合格につながります。
SEOとの関係｜順位への影響と離脱の関係を正しく理解する
ここは誤解の多いところなので、正確にお伝えします。Core Web Vitalsは検索順位に影響する要素の一つですが、それは数ある要素の中の一つにすぎず、速度が最大の要因ではありません。Google自身も、ページ体験は多くのランキング要素の一つであり、質の高いコンテンツを速度で上回ることはない、という趣旨を繰り返し説明しています。
速度は「同点決勝」で効くと考える
内容の薄い速いページより、内容の充実した少し遅いページの方が上位に来ることは普通にあります。検索結果は、まずコンテンツの関連性や信頼性で大きく決まり、Core Web Vitalsはその上で「内容が近い競合どうしの差」を分ける、いわば同点決勝のような役割で効くと捉えるのが実態に近い理解です。したがって、コンテンツが不十分なまま速度だけを追い込んでも、順位が劇的に上がるとは限りません。
本当の価値は「離脱を防ぎ成果につなげる」こと
速度改善の最大の効果は、順位そのものよりも「訪れた人を逃さないこと」にあります。表示が遅い、操作がもたつく、画面がガタつくサイトは、内容を読まれる前に離脱されがちです。ここで注意したいのは、Googleは直帰率や滞在時間といった数値をそのまま順位の直接要因にしているわけではない、という点です。 それでも、快適なサイトはクリックされた後に読まれ、問い合わせや再訪問といった成果につながりやすくなります。速度改善は「順位を直接操作する裏技」ではなく、「せっかくの訪問者を成果に変えるための土台づくり」と捉えると、投資判断を誤りません。良い体験の積み重ねが、指名検索やリンク・共有という形で、長期的にSEOへ間接的な好影響をもたらします。
まず何から手を付けるべきか
限られた時間で効果を出すなら、順番が大切です。おすすめは、(1)画像の最適化、(2)不要な外部スクリプトの削減、(3)サーバー・配信（キャッシュ/CDN）の見直し、の3つから始めることです。この3点は多くのサイトで効果が大きく、専門知識がなくても着手しやすい領域です。そのうえで、レンダリング方式のような根本部分は、リニューアルや新規制作のタイミングで見直すのが現実的です。HaLVision Techのように、Next.js・Reactで速度に配慮した標準実装を前提にできると、後追いの対策コストを抑えられます。
よくある質問
Q.INPとFIDは何が違うのですか。
FIDは「最初の操作について、処理が始まるまでの待ち時間」だけを測っていました。INPは、ページ滞在中のほぼすべての操作を対象に、「操作してから実際に画面が次に更新されるまで」の全体を測ります。つまりINPの方が、待ち時間だけでなく処理の重さや描画の遅れまで含めて評価するため、ユーザーが感じる「もたつき」に忠実で、より厳しい指標になっています。2024年3月にFIDに代わって正式な指標になりました。
Q.Core Web Vitalsの合格基準を教えてください。
良好とされる基準は、LCP（表示の速さ）が2.5秒以内、INP（操作への反応性）が200ミリ秒以内、CLS（表示の安定性）が0.1以下です。この判定は、実際の訪問者の端末で集めた実ユーザーデータ（CrUX）に基づいて行われます。3つすべてが良好であることが望ましい状態です。
Q.表示速度を上げれば検索順位は必ず上がりますか。
必ず上がるとは言えません。Core Web Vitalsは順位に影響する要素の一つですが、最大の要因ではなく、まずはコンテンツの関連性や信頼性が大きく効きます。速度は、内容が近い競合どうしの差を分ける場面で効くと考えるのが実態に近いです。内容が不十分なまま速度だけを追い込んでも、劇的な順位上昇は期待しにくい点に注意してください。
Q.速度改善は自分でできますか。それとも専門家が必要ですか。
画像の最適化（軽量な形式への変換・サイズ調整・遅延読み込み）や、不要な外部スクリプトの削除は、比較的取り組みやすく効果も大きい領域です。まずはPageSpeed Insightsで診断し、指摘の多い項目から着手するとよいでしょう。一方で、レンダリング方式やサーバー構成といった根本的な部分は専門的な判断が必要になるため、リニューアルや新規制作のタイミングで専門家に相談するのが現実的です。
Q.PageSpeed InsightsとSearch Consoleはどう使い分けますか。
PageSpeed Insightsは、1つのURLを詳しく診断し「何が遅いか・どう直すか」を具体的に知るのに向いています。Search Consoleの「ウェブに関する主な指標」レポートは、サイト全体のページを良好・改善が必要・不良に分類し、どのテンプレートに問題が集中しているかを俯瞰するのに向いています。全体傾向はSearch Console、個別の深掘りはPageSpeed Insights、と役割分担すると効率的です。
Q.ラボデータと実ユーザーデータの違いは何ですか。
ラボデータは、決まった条件のもとで疑似的に測る速度データで、原因の切り分けや改善作業の確認に便利です。実ユーザーデータ（フィールドデータ／CrUX）は、実際の訪問者の端末や通信環境で集めた体験データです。Core Web Vitalsの合否判定に使われるのは実ユーザーデータの方なので、最終的には「実際の来訪者にとって速いか」を基準に改善することが重要です。