Core Web Vitals（INP）とは？｜表示速度の次に見る、操作の遅さとコンバージョン率の関係

ページの表示は速いはずなのに、ボタンを押してもなかなか反応しない。そんな体験に心当たりはありませんか。

ページの読み込み速度は長年、Web担当者が最優先で気にしてきた指標です。ところが2024年3月、GoogleはCore Web Vitalsに新しい指標を正式採用しました。

INP（Interaction to Next Paint）は、日本語では「次の描画までの応答時間」と訳される指標です。これは表示の速さではなく、クリックやタップに対する反応の速さを測ります。

この記事では、INPが何を測り、なぜ既存の指標だけでは不十分だったのかを整理したうえで、コンバージョン率（CVR）との関係、自社サイトで確認・改善を始める手順までを解説します。専門用語は初出のたびに噛み砕きます。

エンジニアだけの話ではありません。プロダクトの数字を追う立場の方にとっても、離脱やCVR低下の原因候補として知っておく価値のある指標です。

Core Web Vitalsとは何か

まず土台となるCore Web Vitalsそのものを押さえておきます。これはGoogleが提唱する、ウェブページの体験品質を測る3つの指標の総称です。

読み込みの速さ、操作への反応の速さ、見た目の安定性。ユーザー体験を構成する異なる3つの側面を、それぞれ別の指標で測っている点がポイントです。どれか一つが良くても、残り二つが悪ければ体験全体は損なわれます。

3つの指標が見ている場所

3つの指標は、訪問者がページを開いてから操作を終えるまでの異なる瞬間に対応しています。まず全体像を表で押さえておきましょう。

いずれも75パーセンタイルという考え方で評価されます。平均ではなく、訪問者の4人に3人がその基準を満たしているかどうかを見る、という意味です。平均値には引きずられません。一部の重いページや遅い回線の訪問者に足を引っ張られていないかを、この基準は教えてくれます。

なぜ今、あらためて語られているのか

これまで表示速度の議論は、ページが開くまでの時間にほぼ集中してきました。LCPさえ合格すれば、体験は良いはずだと考えられがちだったのです。

しかしINPの登場は、その前提が半分しか正しくないことを示しました。表示は速いのに、フォーム送信やタブ切り替えのたびに引っかかるページは珍しくありません。すでにLCPを合格させているチームほど、次に見るべき指標としてINPが浮かび上がってきます。

なぜ合格ラインが固定されているのか

3つの基準値は、大量の実測データをもとに、ユーザーが体感で不満を持ち始める境界を統計的に求めて決められています。感覚的な目安ではなく、実際の行動データに裏付けられた線引きだという点は覚えておく価値があります。

だからこそ、この基準は検索順位のシグナルの一部としても使われています。ただし本記事の主眼はSEOではなく、この基準が体感の悪さの目安として使えるという点にあります。

新顔のINPを理解する

FIDの何が問題だったのか

INPが導入される前、操作への反応速度を測る指標にはFID（First Input Delay）というものがありました。名前のとおり、ページを開いて最初の1回の操作にどれだけ遅れて反応したかだけを見る指標です。

これには弱点がありました。最初のクリックだけたまたま速く応答しても、その後のスクロールやフォーム入力がずっともたついていれば、訪問者の体験は悪いままだからです。FIDはその劣化を検知できません。最初の1回さえ通過すれば、ページはずっと合格のままになってしまいます。

INPが測る、訪問中ずっとの体験

INPはこの弱点を解消するために設計されました。ページを開いてから閉じるまでに発生したすべての操作を対象に、それぞれの応答時間を記録し、その中でもっとも遅かった応答に近い値を、そのページのINPとして採用します。

つまりINPは、最初の印象ではなく訪問中を通して裏切られなかったかを測る指標です。ボタンを1回押すたびに何百ミリ秒も待たされる体験は、たとえ表示自体は一瞬で終わっていても、訪問者の記憶には重いサイトとして残ります。表示速度の指標だけを追いかけてきたチームほど、ここで見落としが起きやすくなります。

なぜ操作の遅さがコンバージョンを左右するのか

反応がない数百ミリ秒に何が起きているか

人はボタンを押した瞬間、画面が変化することを無意識に期待しています。その期待に対して反応が遅れると、押せていなかったのではと疑い、もう一度押すという行動を取りがちです。

この「押しても信用できない」という感覚は、一度芽生えるとそのページ全体への不信感に広がりやすいものです。表示は速いのに操作は信用できないという矛盾した体験は、訪問者にとって混乱の元になります。

ここで仮の例を置いて考えてみます。以下の数値はあくまで説明用の仮定です。カート追加ボタンの応答が悪化し、1回のクリックのつもりが連打によって処理が二重に走ってしまうページがあったとします。二重に走った処理は在庫チェックを二度実行し、体感の待ち時間はさらに伸びます。訪問者から見れば、遅いうえに挙動もおかしいページという二重の悪印象が残ることになります。

こうした押しても反応がないという体験の蓄積は、レイジクリック・デッドクリックとして観測できる異常クリックの典型的な発生源のひとつでもあります。INPの数値が悪いページほど、こうした異常クリックの記録も増える傾向があります。両者は同じ現象の別の面を見ているにすぎません。

仮の数値で機会損失を考える

数値のイメージを持つために、もう一つ仮の例（説明用の仮定であり実測ではありません）を置きます。申込フォームの送信ボタンで応答遅延が起きているサイトを考えます。月間1,000件がボタンを押し、そのうち3%にあたる30件が、反応の遅さに苛立って離脱してしまうと仮定します。

この仮定のもとでは、応答速度を改善して離脱が半分の15件に減るだけで、月15件分の申込が余分に積み上がる計算になります。集客を1件も増やさずに得られる分だけに、応答の遅さは見過ごされがちな機会損失だと言えます。

離脱ではなく入力放棄という形で表れる

表示が遅いページの離脱は、多くの場合離脱ページの分析で発見できます。ページを開いてすぐ閉じる、という分かりやすい形を取るからです。

一方でINPの悪化が引き起こす離脱は、少し違う形を取ります。フォームの途中まで入力していた、カートに商品を入れかけていた、といった行動の途中で発生しやすいという特徴があります。数クリックは進めているのでページ単体の直帰率には表れにくく、コンバージョン率（CVR）を段階別に丁寧に追わないと気づけません。

INPが悪化しやすい典型的な原因

INPの数値を追いかけるだけでは改善は進みません。何が応答を遅らせているのかを知っておくと、原因の見当をつけやすくなります。

メインスレッドを長時間占有するJavaScript

ブラウザは基本的に、画面の描画とJavaScriptの実行を同じ一本の処理の流れ（メインスレッド）の上でこなしています。クリックのイベントを受け取っても、その直前に重い処理が走っていれば、処理が終わるまで反応を返せません。

大きなリストの並べ替えや、フォーム入力のたびに走る検証処理など、一度に大量の計算をまとめて行う処理が典型的な原因です。処理を細かく分割し、ブラウザに描画のすきまを与えられるかどうかが分かれ目になります。

積み重なると重くなる小さな処理

ウェブ性能の分野では、メインスレッドを50ミリ秒を超えて占有し続ける処理のかたまりを、まとめて長いタスクと呼ぶことがあります。1つ1つは無害に見える処理でも、続けて実行されると合計の占有時間が伸び、その間に来た操作への応答はすべて後回しになります。

つまり原因は必ずしも一つの巨大な処理とは限りません。小さな処理が途切れず連続していないか、という視点も見落とせません。

積み重なったサードパーティスクリプト

広告タグ、アクセス解析、チャットウィジェットなど、外部から読み込むスクリプトは1つずつは軽くても、積み重なるとメインスレッドを奪い合います。特にページを開いた直後は、これらが一斉に初期化処理を走らせるため、最初の数秒の応答が特に悪化しやすい時間帯になります。

計測タグ自体がこの問題の原因になっているケースも珍しくありません。皮肉なことに、サイトを良くするために入れた計測タグが、体験を悪化させているということが起こり得るわけです。導入するツールの数は、効果と体験のトレードオフとして見ておく必要があります。

自社サイトのINPを確認し、改善の優先順位をつける

フィールドデータとラボデータを使い分ける

INPの計測方法には、大きく分けて二つの性質があります。実際の訪問者の端末から集めたフィールドデータと、決まった条件で再現テストを行うラボデータです。

フィールドデータは実態に忠実な一方、原因までは教えてくれません。逆にラボデータは原因の切り分けに向きますが、実際の訪問者の体験そのものではない点に注意が必要です。現状把握はフィールド、原因調査はラボという役割分担で使うのが実務的です。

手元にあるツールの役割分担を知っておく

INPを測るツールを一から揃える必要はありません。Googleが無償で提供しているPageSpeed InsightsとSearch ConsoleのCore Web Vitalsレポートだけでも、最初の一歩には十分です。

前者は特定の1ページに絞って、フィールドデータとラボデータの両方を一度に見られる点が強みです。後者はサイト全体のページを自動でグループ分けし、どのグループが基準を満たしていないかを俯瞰できます。まず後者で悪化しているグループを見つけ、前者で該当ページを掘り下げる、という順で使うと迷いません。

数値の悪化を、行動の異常とつなげて見る

INPの数値だけを眺めていても、次に何を直すべきかは分かりません。数値が悪化したページや操作を特定したら、そこで実際に何が起きているかを確認する工程が欠かせません。

ここで役立つのが、実際の訪問の様子を録画のように振り返れる仕組みです。MonaLensのセッションリプレイは入力内容を完全にマスクした状態で記録するため、個人情報に触れる心配なく、応答が遅れた瞬間に訪問者がどう反応したか（連打していないか、離れていないか）を目視で確認できます。数値上の異常と、実際の行動の異常を突き合わせることで、直すべき箇所の優先順位がはっきりします。

改善の順番をどう決めるか

すべてのページのINPを一度に直すのは現実的ではありません。優先順位づけには、次の観点を組み合わせるとよいでしょう。

• 到達数が多いページから着手する：LP（ランディングページ）や申込フォームなど、訪問者の多くが通る場所を優先します。
• モバイルを軽視しない：メインスレッドの余力が小さい端末ほど応答遅延は起きやすく、モバイルでのコンバージョン低下の一因になっている可能性があります。
• 数値の悪化と行動の異常が重なる箇所を優先する：異常クリックの増加とINPの悪化が同時に見られる操作は、体験への影響が大きいと判断できます。

優先順位は一度決めたら終わりではありません。改善のたびに数値を測り直し、次に何が最も足を引っ張っているかを見直す。この繰り返しが、応答速度の改善を一過性の施策で終わらせないコツです。

新機能を追加したりサードパーティスクリプトを増やしたりするたびに、応答速度は少しずつ悪化しやすい方向に傾きます。リリースのたびに数値を見直す運用を最初から組み込んでおくと、あとから重くなったページを一気に直す事態を避けられます。小さな悪化のうちに気づけるかどうかが、後の作業量を大きく左右します。

表示速度の次に来る、応答速度という視点

Core Web Vitalsは長らく表示の速さを測る指標として語られてきました。しかしINPの登場は、速く表示されることと、押したときにきちんと反応することが別の問題であることを明確にしました。

表示は一瞬で終わるページでも、操作のたびに引っかかりを感じさせるページは、訪問者の記憶には重いサイトとして残ります。逆に、多少の表示待ちがあっても、押した操作に確実に応答するページは、訪問者に安心感を与えます。

数値としてのINPを追いかけることは出発点にすぎません。その数値の裏で、実際に何人の訪問者がどんな行動の途中で足止めされているのかまで見えて初めて、改善の優先順位は正しく決まります。

表示速度の改善だけに満足せず、操作への応答という一段階先の視点を、ぜひ計測の対象に加えてみてください。数値と行動の両方を見る習慣が、遠回りに見えて一番確実な近道になります。