INP（Interaction to Next Paint）は、クリックやタップに対してページが次の描画を返すまでの応答性を測るCore Web Vitalsの指標です。2024年3月12日にFID（First Input Delay）と入れ替わって正式指標になり、Search Consoleのコアウェブバイタルレポートでも、応答性の評価にはFIDに代わってINPが使われます。良好とされるのは200ミリ秒以下です。この記事では、判定の対象になる操作、ページの代表値がどう選ばれるか、入力遅延・処理時間・表示遅延という3区間の切り分け、そしてツールごとに値が食い違う理由までを公式ドキュメントの記述に沿って整理します。なお、同じつづりの化合物半導体であるインジウムリン（InP）は本記事では扱いません。
まとめ：INPの基準と着手順
- 良好は200ミリ秒以下、500ミリ秒超は不良。判定は実ユーザーのフィールドデータの75パーセンタイルで行います。
- 対象はマウスクリック、タッチのタップ、キー押下の3種類だけです。スクロールとホバーは対象外です。
- ページのINPは通常、最も遅い操作の所要時間です。操作が多いページでは50回ごとに最も遅い1件を除外します。
- 1回の操作は入力遅延・処理時間・表示遅延の3区間に分解できます。改善は最も長い区間から着手します。
- ページ読み込みだけを観測するラボ計測にINPは出ません。読み込み時の阻害要因はTBTで調べ、操作時のINPはChrome DevToolsで再現・計測します。
まず、評価の基準と計測対象を確認します。
INPの判定基準と計測対象
良好と不良を分ける200ミリ秒と500ミリ秒
web.dev のINP解説の定義では、INPが200ミリ秒以下なら応答性は良好、200ミリ秒を超えて500ミリ秒以下なら要改善、500ミリ秒を超えると不良です。他のCore Web Vitals指標と同じく、判定に使うのは実ユーザーから集めたフィールドデータの75パーセンタイルで、モバイルとデスクトップは別々に評価されます。
| 評価 | INPの値 | 判定に使うデータ |
|---|---|---|
| 良好 | 200ms以下 | フィールド（実ユーザー） |
| 要改善 | 200ms超 500ms以下 | 同上 |
| 不良 | 500ms超 | 同上 |
この200ミリ秒という値は、LCPの2.5秒やCLSの0.1と並ぶ合格ラインです。3指標をまとめて確認する手順はコアウェブバイタルとは？3指標（LCP・INP・CLS）の基準と改善方法【2026年版】で扱っています。
対象になる操作とならない操作
INPが観測するのは、マウスでのクリック、タッチスクリーンでのタップ、物理キーボードまたは画面キーボードでのキー押下の3種類です。公式ドキュメントは、ホバー、ズーム、スクロールについて「これらの操作はINPの目的では観測されない」と明記しています。そのため、スクロール性能そのものをINPで追うことはできません。ただし、スクロールに伴う重い処理がメインスレッドを占有し、その最中のクリックを待たせれば、その操作の入力遅延としてINPに表れます。
また、1回の操作は複数のイベントで構成されます。キー押下なら keydown、keypress、keyup、タップなら pointerdown と pointerup です。このうち最も所要時間が長いイベントが、その操作のレイテンシとして採用されます。イベントごとの時間を足し合わせるわけではありません。
ページの代表値と操作数に応じた外れ値除外
ページのINPは通常、最も遅かった操作の所要時間ですが、操作が多いページでは外れ値を除外します。web.dev は「50回の操作ごとに最も遅い操作を1件無視する」と定義しています。
操作数ごとの具体例は次のとおりです。操作が49回以下のページでは最も遅い1件がそのままINPになります。50回から99回なら2番目に遅い操作、100回から149回なら3番目に遅い操作が代表値です。JavaScriptで同じ値を自前計算する場合の実装は、ページのアンロード時に全操作の98パーセンタイルを取る形になります。さらに、フィールド評価では対象集団のページ表示ごとのINPの75パーセンタイルを使います。集計単位は、PageSpeed InsightsではURLまたはオリジン、Search ConsoleではURLグループです。1人のユーザーがたまたま踏んだ極端に遅い1回でサイト全体が不良になることはありません。
INPを構成する3区間と遅い箇所の切り分け
INPは単一の処理時間ではなく、ユーザーが操作してから画面が更新されるまでを3つの区間に分けて合計した値です。どの区間が長いかで打つべき手がまったく変わるため、改善はこの分解から始めます。
| 区間 | 英語名 | 測る範囲 | 長いときの主因 |
|---|---|---|---|
| 入力遅延 | input delay | 操作からコールバック開始まで | メインスレッドの占有 |
| 処理時間 | processing duration | コールバックの実行 | イベントハンドラーの処理量 |
| 表示遅延 | presentation delay | 実行後から描画まで | レンダリングとDOM規模 |
入力遅延（input delay）の計測範囲と原因
ユーザーが操作した瞬間から、その操作に対する最初のコールバックが処理され始めるまでの時間です。Chrome DevToolsの INP breakdown インサイトは、この区間が長い場合を「操作が他のメインスレッド処理によって遅延させられたのであり、遅いINPの直接原因ではない可能性がある」と説明しています。入力遅延が長い場合は、操作直前のスクリプト実行やレンダリングなど、メインスレッドを占有した処理を調べます。読み込み直後に操作されたときに伸びやすい区間でもあります。
処理時間（processing duration）の計測範囲と原因
登録されたすべてのコールバックが実行される時間です。この区間が支配的なら、INP breakdown の記述どおり「イベントハンドラーが遅いINPの直接原因」です。クリック1回で検索・整形・状態更新・再描画要求まで同期的に走らせている実装が典型例です。なお、計測ライブラリ側でこの区間を個別に取得できるようになったのは web-vitals v4 からで、inputDelay・processingDuration・presentationDelay の3つが同時に追加されました。v3以前を前提にした解説では区間の内訳が取れないため、古い記事のコードをそのまま使うと3区間の切り分けができません。
表示遅延（presentation delay）の計測範囲と原因
コールバックの実行が終わってから、その結果を反映したフレームが実際に画面へ出るまでの時間です。INP breakdown は「イベントハンドラーのコードが走った後の描画遅延」と定義しています。JavaScriptの実行時間を削っても数値が動かないときは、ここを疑います。DOMが大きいページほどレンダリング作業が重くなり、この区間が伸びます。
FIDとの違いと移行後に残る計測の穴
FIDとINPの測定範囲の違い
FIDが測っていたのは、ページ読み込み後の最初の1回の操作について、コールバックが始まるまでの遅延だけでした。INPとの差は2点あります。1つは対象が最初の1回からページ滞在中のすべての操作へ広がったこと、もう1つは計測の終点が「処理が始まるまで」から「結果が描画されるまで」へ伸びたことです。
この差は実装上の意味が大きく、FIDでは合格していたページがINPで不良になる例が普通に起きます。FIDではイベントハンドラーの実行時間とその後の描画時間が評価されませんでしたが、INPではその後の処理と描画まで測られるため、見かけだけの対策が効きません。web.dev はINPについて「ページのライフサイクルのどの時点で操作が起きたかにかかわらず、全体的な応答性をより確実に示す指標」と位置づけています。
2024年9月に止まったFIDの供給元
移行スケジュールは終わっています。2024年3月12日にINPがCore Web Vitalsの正式指標となり、Search ConsoleからはFIDが同日に外れました。CrUXとPageSpeed Insightsの各APIには6か月の移行期間が設けられ、期限は2024年9月9日でした。web.dev の告知は「これは最新版APIにおける破壊的変更であり、メジャーバージョン番号は上がらない」と警告していました。翌2024年9月10日の記事で「本日をもってFIDはChromeのツールでサポートされなくなった」と宣言されています。
ただし完全に消えたわけではありません。同じ記事は「変わらないのは、PerformanceObserver APIにおける first-input エントリのChromiumサポート」と述べており、自前計測でFIDを取り続けること自体は可能です。逆に言えば、FIDを前提に組んだ社内ダッシュボードが2024年9月以降も数値を表示している場合、取得元と対象期間を確認してください。CrUXのBigQueryには過去のFIDデータが残るため、表示値が自前計測か履歴データかを区別する必要があります。サーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】で扱うコアウェブバイタルレポートは、LCP・INP・CLSで評価し、URLグループの最も悪い指標に基づいてステータスを判定します。
INPの計測手段
INP計測におけるフィールドとラボの役割
web.dev は「自サイトのINPを測る最善の方法は、実際のユーザーからメトリクスを集めること」としています。最短の確認手段はPageSpeed InsightsでURLを入力することです。ページ上部に表示される実際のユーザー環境での評価がCrUX由来のフィールドデータで、ここにINPが出ます。下部のLighthouseによる診断結果はラボデータで、こちらにINPは含まれません。
ラボ計測でINPが出ない理由は単純で、公式ドキュメントが書くとおり「一部のラボツールは操作を伴わないページ読み込みだけを観測するため、ページのINPを報告しない」からです。web.dev のラボツール対応表はさらに踏み込んで、Chrome DevToolsはLCP・INP・CLSの3つとも計測できる一方、Lighthouseの欄はINPだけがバツ印で「代わりにTBTを使う」と注記されています。注釈の文言は「Lighthouseのように、ユーザーのいないシミュレーション環境でページを読み込むツールは、ユーザー入力が存在しないためINPを計測できない」です。ただし同ドキュメントは「Total Blocking Time（TBT）はINPの妥当な代理指標になり得るが、INPそのものの代用にはならない」とも釘を刺しています。TBTを含むラボ指標の位置づけはWebパフォーマンス指標の一覧と使い分け｜TTFB・FCP・TBT・Speed Indexの基準、Lighthouseの点数構成はLighthouseスコアの見方と改善方法｜Best Practices・SEOの配点と5カテゴリで整理しています。
それでもラボで遅い操作を再現する余地はあります。web.dev が挙げる方針は、よくあるユーザーフローをなぞって途中の操作を試すことと、メインスレッドが最も混雑する読み込み中に操作してみることの2つです。Chrome DevToolsのパフォーマンスパネルで操作を含めて記録すれば、前述の INP breakdown インサイトが最も遅かった操作を3区間に分解して表示します。同インサイトのドキュメントは、実機より非力な環境での挙動を見るために「CPUスロットリングを有効にする」ことも勧めています。
web-vitalsライブラリでの自前計測
自社サイトに計測を埋め込む場合は、Googleが公開している web-vitals ライブラリを使います。2026年9月20日時点の最新版は6.2.2です。attribution ビルドを使うと、遅かった操作の要素や区間の内訳まで受け取れます。以下はweb-vitalsをnpmで導入し、バンドラーで処理するブラウザ向けコードの例です。結果はコンソールに出力し、サーバーへの送信は行いません。
import { onINP } from 'web-vitals/attribution';
onINP((metric) => {
const a = metric.attribution;
console.log(metric.value, a.interactionTarget, a.interactionType);
console.log(a.inputDelay, a.processingDuration, a.presentationDelay);
});このコードは、操作後にタブを切り替えるなどしてページが非表示になった時点でも値をコンソールに出力します。操作のたびに出力する設定ではないため、計測を仕込んだ直後に数値が出ないことを不具合と誤認しないでください。
INPが出ない・ツール間で値が食い違う場合の読み方
INPは定義上ゼロ件になり得る指標で、しかも計測経路によって値がずれます。この2点は現場で最も混乱を招くところなので、公式が挙げている条件を押さえておきます。
INPが報告されない3つのケース
web.dev は、ページがINP値を返さない理由として次の3つを挙げています。ページは読み込まれたがユーザーがクリック・タップ・キー押下のいずれも行わなかった場合、スクロールやホバーのような計測対象外の操作しかしなかった場合、そして検索クローラーやヘッドレスブラウザのようなボットが操作をスクリプト化せずにアクセスした場合です。
記事ページや会社案内のように読むだけで完結する導線では、1つ目と2つ目が日常的に起きます。PageSpeed InsightsでINPだけ空欄になるのは、多くの場合サイトの不具合ではなくデータ不足です。空欄だけでは改善の優先度を判断できません。検索・メニュー・問い合わせなどの主要操作を実測し、LCPやCLSで確認された問題と影響を比較します。
CrUXと自前計測がずれる2つの理由
CrUXとRUMは、対象ユーザーや集計期間、計測方法の違いで値がずれます。ここでは計測仕様に関する2つの要因を説明します。
1つ目は iframe です。公式ドキュメントは、埋め込み動画の再生ボタンを押すような iframe 内の操作もINPの対象だとしたうえで、「JavaScriptのWeb APIは iframe の中身にアクセスできないため、これがCrUXとRUMの差として現れることがある」と説明しています。埋め込み先で遅い操作が発生し、その操作を自前計測で収集できない場合は、応答性を実態より良く評価する可能性があります。
2つ目は報告のしきい値です。パフォーマンスオブザーバーでは、104ミリ秒未満の event エントリが既定では報告されません。この既定値は登録時に durationThreshold パラメータで変更できますが、それでも最小値は16ミリ秒です。短い操作の欠落は自前計測との差の要因になります。また、INPは平均値ではないため、全操作を取得できても単純平均では再現できません。web-vitals ライブラリはこうした差異をWeb APIの制約の範囲で吸収するよう作られており、独自実装よりライブラリを使うほうが確実です。
CrUXとRUMの評価・診断での使い分け
Googleのレポートを確認する際はCrUXを使い、自サイトの改善効果やユーザー体験の確認にはRUMも使います。自前計測は「どの要素が遅いか」を特定するための道具として使い、合否の判断はPageSpeed InsightsとSearch Consoleに出るフィールドデータで行います。両方を同じ精度の数値として並べて報告すると、改善したのに評価が動かない理由を説明できなくなります。
区間別のINP改善手順
着手順は数値の大きさで決めます。INP breakdown のドキュメントが述べるとおり「最も長い区間の時間を削ることに集中する」のが原則で、3区間に均等に手を入れるのは非効率です。
入力遅延の改善：長いタスクの分割と制御の返却
入力遅延が支配的なら、操作を受ける前にメインスレッドを塞いでいる処理が原因です。web.dev は50ミリ秒を超えるタスクを長いタスク（long task）と定義しており、これを分割して合間にメインスレッドへ制御を返します。
制御を返す手段として現在推奨されているのは scheduler.yield() です。2024年9月17日に安定版が出たChrome 129で搭載され、Edge 129以降、Firefox 142以降で利用できます。Safariは未対応です。setTimeout() で分割すると残りの処理はタスクキューの最後尾に回されますが、scheduler.yield() は中断した続きが優先して再開されるため、分割してもユーザー操作以外に割り込まれにくくなります。
なお、かつて紹介されていた isInputPending() を使って「入力が来ているときだけ譲る」書き方は、公式に「このAPIの使用はもはや推奨しない」と撤回されています。入力の有無にかかわらず譲るのが現在の推奨です。古い記事を参考に実装している場合は見直してください。
処理時間の改善：イベントハンドラーの作業量削減
処理時間が長いなら、ハンドラーの中身そのものが重い状態です。公式の指針は「イベントコールバックの中では可能な限り作業を少なくする」ことで、ユーザーに見せる更新だけを同期的に行い、ログ送信・集計・先読みなどは後続のタスクへ逃がします。
あわせて避けるべきなのがレイアウトスラッシングです。スタイルを書き込んだ直後に offsetWidth のようなレイアウト値を読むと、ブラウザが同期的にレイアウトを再計算します。読み取りと書き込みを分離して不要な同期レイアウトを減らし、処理時間が短縮したかを再計測します。
表示遅延の改善：DOM規模とレンダリング範囲の縮小
表示遅延が支配的なら、描画そのものが重いということです。web.dev は大きなDOMが問題になる場面として、初回レンダリング時と、ユーザー操作への応答としてレンダリング更新が非常に高くつく場合の2つを挙げています。レンダリング作業量はDOMサイズと単純な比例関係にはありませんが、大きなDOMでは負荷が増えやすいため、無限スクロールや巨大なテーブルを持つ画面では要素数の削減が直接効きます。
画面外の要素については content-visibility による遅延レンダリングが公式に推奨されています。長いページで画面外のセクションの描画を後回しにでき、操作時のレンダリングコストを下げられます。加えて、JavaScriptでHTMLを組み立てて挿入する実装は描画コストが高くつく点も指摘されています。
採用すべきでない場面も書いておきます。操作の少ない記事ページでは、主要なリンクやメニューに応答性の問題がないか確認し、問題が見つからなければ他の改善を優先します。INPが報告されない場合、データ不足と改善すべき応答性の問題が同時に存在する可能性があります。この場合はLCPやCLS、あるいはテクニカルSEOとは？主要施策と優先順位つきチェックリスト【2026年版】で扱うクロールとインデックスの問題も調べ、確認できた支障の大きさに基づいて着手順を決めます。
よくある質問
INPの目標値は何ミリ秒ですか？
200ミリ秒以下が良好、500ミリ秒超が不良です。この判定はラボ計測の1回の値ではなく、実ユーザーのフィールドデータの75パーセンタイルで行われます。
スクロールが重いとINPは悪化しますか？
スクロール自体は計測対象外です。ただし、スクロールに伴う重い処理がクリックなどを待たせると、INPが悪化する可能性があります。INPが観測するのはクリック、タップ、キー押下の3種類だけで、公式ドキュメントはホバー・ズーム・スクロールを対象外と明記しています。スクロール性能はINPとは別に追う必要があります。
LighthouseでINPを確認できますか？
通常のページ読み込み計測では確認できません。操作を伴わないラボ計測にはINPが出ないためです。ラボで目安が欲しい場合はTotal Blocking Time（TBT）を代理指標として使い、実際のINPはPageSpeed Insights上部のフィールドデータかSearch Consoleで確認します。操作を含めて記録したい場合は、Chrome DevToolsのパフォーマンスパネルで INP breakdown インサイトを使います。
FIDはもう見なくてよいのですか？
Core Web Vitalsの応答性指標はFIDからINPに置き換わり、LCP・CLSとともに判定に使われます。2024年9月10日にChromeのツールでのFIDサポートは終了しており、CrUXやPageSpeed InsightsのAPIからも取得できません。ただし PerformanceObserver API の first-input エントリは引き続き利用できるため、自前計測で継続取得すること自体は可能です。
INPが遅いとき、最初にどこを見るべきですか？
入力遅延・処理時間・表示遅延のうちどれが最も長いかを先に特定します。入力遅延が長ければスクリプト実行やレンダリングなどがメインスレッドを占有している可能性があり、処理時間が長ければイベントハンドラー自体が、表示遅延が長ければレンダリングが原因です。Chrome DevToolsの INP breakdown インサイトで操作を記録すると、最も遅かった操作をこの3区間に分解して確認できます。
