本記事の数値について 指標の定義はGoogleの開発者向けサイト web.dev、世界の実態は HTTP Archive「Web Almanac 2025」（2025年7月の計測）、改善例はweb.devに掲載された2社の事例記事から引用しています。いずれも2026年10月時点で公開されている本文を確認しました。事例は各社の技術者による自己申告で、他の施策と同時に行われたものです。「反応の速さはどれくらい効くのか」を考える材料として紹介します。
メニューを開こうとタップした。でも一瞬、何も起きない。もう一度押したら、2回分動いた。
スマホでサイトを見ていて、こういう経験をしたことがある方は多いと思います。表示は速いのに、触ると引っかかる。この「触ってから動くまで」を測る指標が、2024年からGoogleの速度の基準に入りました。**INP（Interaction to Next Paint）**です。
「要改善」
スマホサイト（世界）
メディアの直帰率
予約サイトの売上
web.dev「Interaction to Next Paint」、Web Almanac 2025（2025年7月）、web.devの事例記事（Economic Times・redBus）より
INPとは何を測っているのか
Googleの説明によれば、INPはページを見ている間のすべてのクリック・タップ・キー入力について、操作してから次に画面が描き変わるまでの時間を観察し、その中で最も遅かったものを、そのページの値として報告する指標です（操作がとても多いページでは、極端に遅い少数は除外されます）。スクロールやホバーは対象になりません。
基準は3段階です。
図① INPの判定基準。実際の利用者の75%がこの範囲に入っているかで、サイト全体の合否が決まる（web.devより）
200ミリ秒は0.2秒です。押してから0.2秒以内に画面が反応しないと、人は「効いていない」と感じて押し直し始めます。冒頭の「2回分動いた」は、これです。
Googleはこの時間を3つに分けて説明しています。
- 入力の遅れ：押した瞬間、ブラウザが別の処理で手一杯で、ボタンの処理を始められない時間
- 処理の時間：ボタンに紐づいた処理（メニューを開く、入力を検証する、など）が終わるまでの時間
- 描画の遅れ：処理が終わってから、画面が実際に描き変わるまでの時間
多くのサイトで問題になるのは1番目です。ページが読み込んだ計測タグやチャット、スライダーなどのプログラムが、裏で長い処理を走らせていると、利用者がボタンを押した瞬間に「順番待ち」が起きます。
2024年3月から、正式な基準になった
それまでGoogleが使っていた指標はFID（最初の操作の入力遅延）でしたが、最初の1回しか見ないなど「操作の快適さを十分に捉えられない」ため、2024年3月12日にINPがFIDを置き換えて、Core Web Vitals の正式な指標になりました。検索での評価に使われる3つの指標のうちの1つが、この日から「反応の速さ」になったということです。
世界のサイトの77%は良好、しかし裏側は悪化している
では、世界のサイトはどれくらい合格しているのか。HTTP Archive の「Web Almanac 2025」によれば、2025年7月時点でスマホでINPが良好なサイトは77%（2024年は74%）。PCでは97%です。前回紹介したメイン表示の速さ（LCP）がスマホで62%だったのに比べると、合格率は高めです。
ただし同じ報告は、合格率の裏で**「メインスレッドの占有が深刻化している」**とも書いています。ページの処理を妨げる時間（TBT）の中央値は、スマホで1,916ミリ秒まで増えました。ブラウザは1本の作業列（メインスレッド）で画面の描画も操作の処理もこなすので、ここが長く塞がるほど、ボタンの処理は後回しになります。
塞いでいるものの多くは、外部から読み込むプログラムです。同じ報告の別の章によれば、ページの90%以上が第三者のサービスを読み込んでおり、スマホ1ページあたりの第三者への通信は中央値で79件。上位はフォント、タグマネージャー、アクセス解析など、どのサイトにも入っているものばかりです。
INPの合格率（世界・スマホ）
- 2024年：74%
- 2025年：77%
- PCは97%
裏側で増えているもの
- 処理を妨げる時間（TBT）中央値：1,916ミリ秒
- 第三者サービスを使うページ：90%以上
- 第三者への通信：中央値79件／ページ
図② Web Almanac 2025（Performance章・Third Parties章）より
直した会社では、何が起きたか
web.devには、INPを改善した会社の事例が載っています。2つ紹介します。
インドの大手経済メディア（The Economic Times）は、トピックページのINPが1,000ミリ秒近くありました。重要でない処理の読み込みを後回しにし、使っていないプログラムとスタイルを削除し、メニューの項目を開いたときだけ描画するよう変えて画面の部品を約1,200個減らし、第三者のプログラムを別の作業列に逃がす、といった対策を重ねています。結果、INPは257ミリ秒（約4分の1）、処理を妨げる時間は3,260から120ミリ秒に。トピックページの直帰率は50%減り、ページビューは43%増えたと報告しています。
インドのバス予約サイト（redBus）は、検索結果ページの反応が遅く、INPが870〜900ミリ秒ありました。1回に取得する結果を30件から10件に減らし、スクロールの処理を間引き、入力欄の文字を1文字ごとに全体へ反映するのをやめて入力が終わったときだけ反映するよう変えています。検索ページのINPは350〜370ミリ秒になり、入力欄の反応は72%改善。会社全体の売上は7%増えたと報告しています。
図③ web.devの事例記事より。どちらも各社の自己申告で、他の施策と同時期の数字
どちらの会社も、やったことは派手ではありません。「一度に処理する量を減らす」「使っていないものを消す」「後回しにできるものを後回しにする」。こうした地道な対策と同じ時期に、利用者の行動の変化が報告されています。
この数字の限界
① 事例は各社の技術者による自己申告です。Economic Times は同じ時期にフレームワークの移行も行っており、INPの改善だけの効果は切り分けられていません。redBus の売上7%も同様です。
② どちらもアクセスの多い大規模サイトです。自社開発のプログラムを直した話で、中小企業のサイトのように「入れているツールの数」が問題になる構造とは少し違います。
③ 世界の77%は、実際の利用者のデータがあるサイトの数字です。アクセスが少なくデータが無いサイトは含まれていません。
自社サイトでどう確かめるか
INPは、表示速度と同じく PageSpeed Insights で確認できます。見る場所が少し違います。
- 上半分「実際のユーザーの環境」の中の INPを見る。これが実際の利用者の反応速度。200ミリ秒以内なら緑
- 下半分のテストには INP そのものは出ない。代わりに「Total Blocking Time（合計ブロック時間）」を見る。長いほど操作が順番待ちになりやすい
- 診断結果の「メインスレッド処理の最小化」「JavaScript 実行時間の低減」「第三者コードの影響を抑える」を開くと、どのプログラムが時間を使っているかが出る
- スマホの実機で、メニュー・タブ・フォームの入力欄を実際に触ってみる。引っかかる場所があれば、それがINPを悪くしている操作
- 後から足した計測タグ・チャット・ヒートマップ・スライダーは、使っていないものを外すだけで効くことが多い
INPは「実際のユーザー」の欄で見る。テスト側では合計ブロック時間と第三者コードの内訳を手がかりにする
まとめ
- INPは、クリック・タップ・キー入力から画面が描き変わるまでの時間。利用者の75%で200ミリ秒以内なら良好、500ミリ秒を超えると不良
- 2024年3月12日から Core Web Vitals の正式な指標。検索での評価に使われる3つのうちの1つ
- 2025年の世界のスマホサイトで良好なのは77%。ただし処理を妨げる時間は増え続けており、第三者のプログラムが90%以上のページに入っている
- Economic Times はINPを約4分の1にし、そのあと直帰率が半減。redBus は検索ページの反応を直したあと売上が7%増（いずれも自己申告で、他の施策と同時期）
- 確認は PageSpeed Insights の「実際のユーザーの環境」で。テスト側は合計ブロック時間と第三者コードの内訳を見る
前回、国内602サイトの実測で「速度の基準で最も多くつまずいているのはINP」という結果をお伝えしました。次の記事では、国内のサイトで何がINPを悪くしているのかを、入っているツールと突き合わせて見ていきます。
コンバージョン偏差値スキャナーでは、表示速度を含む50項目でサイトを採点し、改善の優先順位を示しています。URLを入れるだけで、最短60秒・登録不要で結果が表示されます。
出典：web.dev「Interaction to Next Paint」／web.dev「INP becomes a Core Web Vital on March 12」／HTTP Archive「Web Almanac 2025」Performance・Third Parties／web.dev「Economic Times quest for fixing INP」／web.dev「redBus」
