Mobilistica

改善事例

INPとは？改善の手順と原因の切り分け【自社実測データ付き】

・約13分で読めます

INP（Interaction to Next Paint）とは、クリックやタップなどの操作から、画面に最初の反応が描かれるまでの待ち時間を測る指標です。Core Web Vitalsのうち「応答の速さ」を受け持ちます。

web.devの基準は、下の表の3段階です。PageSpeed Insightsで、他の項目は緑なのにINPだけ黄色か赤、あるいは欄そのものが空の方もいるはずです。Mobilisticaが、原因の切り分け方と改善の順番をまとめました。2026年9月29日にweb.devとGoogle検索セントラルの公開ドキュメントを読み直し、内容を更新しています。

判定 INPの値 意味
良好 200ミリ秒以下 操作にすぐ反応する状態
要改善 200ミリ秒超〜500ミリ秒以下 反応の遅れを感じ始める水準
不良 500ミリ秒超 操作がもたつく状態

※上の3段階はweb.devの「Interaction to Next Paint (INP)」に載っている基準です。

この記事でわかること：

  • INPの定義と、旧指標FIDとの違い
  • PageSpeed InsightsにINPが出ないときの見方と、代わりに使うTBTの限界
  • 入力遅延・処理時間・表示遅延の3つに分けて原因を探す手順と、対策の一覧

INPとは？基準値・FIDとの違い・検索との関係

INPは、ページを開いている間に起きたクリック・タップ・キー入力のうち、反応が最も遅かった操作の待ち時間を、そのページの代表値にする指標です。

web.devによると、Chromeの利用データではユーザーがページで過ごす時間の90%が読み込み完了後に費やされます。だから、読み込み速度だけでなく、開いた後の操作への反応も測る指標が要るわけです。

数え方には細かい決まりがあります。操作が多いページでは、50回ごとに最も遅い1回が除外される仕組みです。最終的な判定に使うのは、ページ表示全体の75パーセンタイル値。

INPは、ユーザーがページ上で行ったすべての操作の待ち時間を観察し、すべて（またはほぼすべて）の操作がそれを下回る1つの値を報告する。（訳はMobilistica）
出典：web.dev「Interaction to Next Paint (INP)」

FIDとの違い

FID（First Input Delay）は、最初の1回の操作の「入力遅延」だけを見ていました。INPは全ての操作を対象にし、入力遅延から、処理の実行、次の描画までを丸ごと測ります。

web.devの告知どおり、INPは2024年3月12日にFIDに代わってCore Web Vitalsに採用されました。告知記事では、FIDは非推奨になると明記されています。

計測の対象になる操作

対象は、マウスのクリック、タッチ画面のタップ、キーボードのキー入力の3種類です。ホバー、ズーム、スクロールは含まれません。埋め込み動画の再生ボタンのように、iframeの中で起きた操作もページのINPに数えられます。

検索順位との関係

Google検索セントラルは、Core Web Vitalsを「読み込み・操作性・表示の安定性を測る、実際のユーザー体験の指標群」と位置づけています。良好な状態は、コアランキングシステムが評価しようとするものと沿っているとも説明しています。INPの目安は200ミリ秒です（Google検索セントラル「Core Web Vitalsと検索結果について」）。

ただし、ここで書かれているのは「目指すとよい水準」です。INPだけで順位が決まるとは書かれていません。LCPやCLSと合わせた3指標の全体像は、Core Web Vitalsとは？LCP・INP・CLSの合格ラインと改善手順にまとめています。

INPの3つの内訳｜入力遅延・処理時間・表示遅延

INPの待ち時間は、入力遅延、処理時間、表示遅延の3つを足したものです。改善は、どこが長いのかを先に特定してから始めます。

web.devのINP最適化ガイドは、操作の中身を次の3つに分けています。

内訳 どこの時間か 遅くなる主な原因
入力遅延 操作した瞬間から、イベント処理が始まるまで メインスレッドが別の処理で塞がっている
処理時間 イベントの処理が終わるまで クリック時に動くコードが重い
表示遅延 処理の終了から、次の画面が描かれるまで 描画し直す範囲が広い

3つを足した値が、1回の操作にかかる待ち時間です。そのうち最も長かった操作が、INPとして表に出ます。「メニューを開くのが遅い」と感じたとき、原因が読み込み中の重い処理なのか、クリック後の処理なのかで打つ手は変わります。

INP改善の手順（4ステップ）

改善の流れは、フィールドデータの確認、TBTでの暫定診断、3つの内訳での切り分け、対策と再計測の順です。

INP改善の4ステップをイメージした図
フィールドデータ確認→TBTで暫定診断→原因の切り分け→対策・再計測、という4ステップの流れ

  1. ステップ1：フィールドデータでINPの数値を確認する

    PageSpeed InsightsにURLを入れ、実ユーザーのデータ（CrUX）の欄でINPを見ます。モバイルとデスクトップは切り替えられるので、両方を確認してください。

    数値が出ないことは珍しくありません。PageSpeed Insightsの公式説明によると、公開して間もないページや実ユーザーの標本が少ないページは、十分なデータがないためURL単位では表示されません。その場合はドメイン全体の集計に切り替わり、それも足りなければ何も表示されません。

  2. ステップ2：TBTで暫定診断する

    INPが出ないときは、ラボ計測のTBT（Total Blocking Time：合計ブロック時間）で代用します。TBTは、50ミリ秒を超える長いタスクのうち、50ミリ秒を超えた部分を合計した値です。

    web.devのTBT解説は、一般的なモバイル端末で200ミリ秒未満を目安にしています。なお、TBTはINPの代わりにはなりません。理由は「つまずきやすいポイント」で説明します。

  3. ステップ3：3つの内訳のどこが長いかを切り分ける

    Chrome DevToolsのパフォーマンスパネルを開くと、ライブメトリクスの画面で操作を試せます。操作するたびにインタラクションのログが出て、フェーズ別の内訳も展開して見られる仕組みです。詳しい原因の調査は、同じパネルのトレース記録の役目。手順はweb.devの「ラボで遅い操作を手動で診断する」にあります。

    試す操作は、ユーザーがよく通る流れから選ぶとよいでしょう。ECならカートへの追加や決済の入力、メディアならメニューの開閉や検索が候補です。web.devは、読み込み中の操作も試すよう勧めています。この時間帯はメインスレッドが最も忙しいためです。

  4. ステップ4：対策を1つずつ試し、同じ条件で再計測する

    次の章の一覧から該当する対策を選び、1回に1つだけ適用します。修正のたびに、同じ端末条件で計測し直してください。

    フィールドデータは、PageSpeed Insightsでは直近28日間の集計です。修正の効果が数値に反映されるまで時間がかかる点は、あらかじめ織り込んでおく必要があります。

フィールドデータが出ないサイトでの読み方は、フィールドデータが出ないサイトのCore Web Vitalsの読み方【16サイト実測】で詳しく扱っています。

自社4ドメインの実測｜TBTが低くてもLCPは遅かった

Mobilisticaが運営する4ドメインを、2026年8月12日にPageSpeed Insightsのモバイル・ラボデータで計測すると、TBTはすべて50ミリ秒以下でした。

ドメイン TBT（合計ブロック時間） LCP（参考）
toshidensetsu-labo.net 0ミリ秒 2.3秒
erii-waso.com 30ミリ秒 7.1秒
mobilistica.com 40ミリ秒 3.2秒
tabi-no-tetsuzuki.com 50ミリ秒 7.0秒

web.devが示すTBTの目安（200ミリ秒未満）を、4件とも大きく下回っています。一方でLCPは、erii-waso.comが7.1秒、tabi-no-tetsuzuki.comが7.0秒でした。Google検索セントラルが挙げる2.5秒の3倍近い値です。

読み取れるのは、TBTの低さがほかの指標の良さを約束しない、という点です。この表はラボの単発計測なので、実ユーザーのINPを示すものではありません。LCPの見方はLCP改善の手順で扱っています。

原因別の対策一覧｜内訳ごとに打つ手が違う

対策は、入力遅延・処理時間・表示遅延のどこが長いかで選びます。下の表は、web.devの最適化ガイドをもとに整理したものです。

内訳 よくある原因 主な対策
入力遅延 読み込み中のスクリプトの解析・実行が長いタスクになる 不要なスクリプトを減らし、長いタスクを分割する
入力遅延 外部サービスのスクリプトが、タイマーなどで処理を走らせる 本当に必要かを見直し、必要なら提供元に改善を依頼する
処理時間 イベントの中で、画面更新と関係のない処理まで実行している 画面更新に要る処理を先に済ませ、残りは後続のタスクに回す
処理時間 スタイルを変えた直後に、同じ処理の中で値を読み取っている（レイアウトスラッシング） 書き込みと読み取りの順序を見直す
表示遅延 DOMが大きく、描画し直す範囲が広い DOMを減らす、CSSのcontent-visibilityで画面外の描画を後回しにする
表示遅延 JavaScriptで大量のHTMLを描画している サーバーから届くHTMLを活用し、クライアント側の描画量を減らす

外部サービスのスクリプトについて、web.devの入力遅延の解説は、中身を自分では制御できないことが多く、必要性の判断と提供元との調整が要ると述べています。広告タグや解析タグを入れているページは、まずここから疑うのが早道です。

処理を分割して「待たせない」書き方

処理時間の対策で中心になるのは、長い処理を複数のタスクに分け、間でブラウザに描画の機会を渡すことです。web.devの長いタスクの最適化が挙げるscheduler.yield()が、その手段として使えます。

使い方は単純です。入力チェックやスピナー表示のような見える更新を先に書き、await scheduler.yield()を挟みます。保存や計測の送信といった見えない処理は、その後ろに置きます。web.devの掲載例もこの形です。すると、見える処理と見えない処理が別のタスクになり、描画が先に進みます。

ただしscheduler.yield()は、2026年9月29日に確認したweb.devの対応表でSafariが未対応でした。対応していないブラウザ向けには、setTimeoutで後続の処理を新しいタスクにする方法が使えます。

つまずきやすいポイント・注意点

最もつまずきやすいのは、TBTを下げればINPも下がると思い込むことです。web.devは、両者の関係を次のように説明しています。

TBTはラボでのINPの代理指標としては妥当かもしれないが、それ自体がINPの代わりになるわけではない。（原文の趣旨は「not a substitute for INP」。訳はMobilistica）
出典：web.dev「Total Blocking Time (TBT)」

同じ解説によると、TBTは操作が起きない時間帯の問題まで拾うことがあり、ラボでは操作で起きる問題を見逃すこともあります。最終的な確認は、実ユーザーのINPで行うのが筋です。

ほかに覚えておきたい注意点は3つです。

  • iframeの中も対象になる：埋め込みの動画や広告枠で遅い操作があると、ページ全体のINPに響く。iframeにはそれぞれ独自のメインスレッドがあるので、どの枠の操作かを確かめてから調べる。
  • 1つ直すと次が見つかる：web.devは、INPの改善を繰り返しの作業と位置づけています。遅い操作を直すと、別の遅い操作が見えてくるためです。
  • ほかの指標も確認する：LCPとCLSは別々に評価される。INPを直した後は、LCPとCLSの変化も見てください。

もう一つの見落としが、ラボ計測の限界です。web.devのラボとフィールドの違いの解説は、INPが「ユーザーが実際に操作を選んだタイミング」で測られる指標だと述べています。ラボの計測では、ユーザーがいつ操作するかを予測できないという理屈です。

よくある質問（INP FAQ）

INPとはどういう指標ですか？

クリックやタップなどの操作をしてから、画面に反応が描かれるまでの待ち時間を測る、Core Web Vitalsの指標です。ページを開いている間の全操作を見て、最も遅い操作（外れ値を除く）を代表値にします。

INPはどれくらいの数値を目指せばいいですか？

web.devの基準では、200ミリ秒以下が「良好」です。200ミリ秒超500ミリ秒以下は「要改善」、500ミリ秒超は「不良」とされています。判定は、ページ表示全体の75パーセンタイル値で行います。

PageSpeed InsightsでINPが表示されないのはなぜですか？

実ユーザーのデータが十分に集まっていないためです。PageSpeed Insightsは、URL単位のデータが足りなければサイト全体の集計に切り替え、それも足りなければ何も表示しません。また、操作をしないbotの訪問だけではINPが記録されません。

TBTを改善すればINPも改善しますか？

近づく傾向はありますが、保証はされません。web.devも、TBTは読み込み中の処理の詰まりを測る指標で、INPの代わりにはならないとしています。TBTの改善は、あくまでINP改善の土台です。

FIDとINPは何が違いますか？

FIDは最初の操作の入力遅延だけを測っていました。INPはすべての操作を対象にし、入力遅延から次の描画までを測ります。2024年3月12日に、INPがFIDに代わってCore Web Vitalsになりました。

まとめ｜INPは「どこが長いか」を分けてから直す

ポイントは次の3つです。

  • INPは200ミリ秒以下が良好、500ミリ秒超が不良で、判定は75パーセンタイル値で行う
  • PageSpeed InsightsにINPが出ないときはTBTで暫定診断し、最終確認は実ユーザーのデータで行う
  • 原因は入力遅延・処理時間・表示遅延の3つに分けて探し、対策は1つずつ試して同じ条件で測り直す

Mobilisticaの4ドメインの計測では、TBTがすべて50ミリ秒以下でも、LCPには7秒台のページが残りました。応答性と表示速度は別の指標として、原因の探し方から別々に進めるのが近道です。着手の順番から知りたい方は、表示速度改善の進め方：効果が大きい施策から着手する方法も役に立ちます。

INPの計測結果が新しく取れたら、Mobilisticaでこの記事の表に書き足す予定です。

※本記事は一般的な情報提供を目的としており、個人の見解を含んでいます。実際の改善効果はページの構成によって異なるため、ご自身のページで再計測してください。
※自社の計測値は、2026年8月12日のPageSpeed Insights（モバイル・ラボデータ）による単発の結果。測定環境やタイミングで変動する。
※基準値と手順の出典は、2026年9月29日に確認したweb.devとGoogle検索セントラルの公開ドキュメント。
最終更新: 2026年9月29日（初版の内容を見直し、追記・改善しました）
運営者情報 ｜ プライバシーポリシー ｜ お問い合わせ