INP（Interaction to Next Paint）は、クリックやタップに対してページが次の描画を返すまでの応答性を測るCore Web Vitalsの指標です。2024年3月12日にFID（First Input Delay）と入れ替わって正式指標になりました。良好とされるのは200ミリ秒以下です。この記事では、判定の対象になる操作と代表値の選ばれ方、入力遅延・処理時間・表示遅延という3区間の切り分け、遅い原因のスクリプトを特定する手順、区間ごとの直し方を、公式ドキュメントとChrome 156での実測値に沿って整理します。なお、同じつづりの化合物半導体であるインジウムリン（InP）は本記事では扱いません。
まとめ：INPの基準と改善の着手順
- 良好は200ミリ秒以下、500ミリ秒超は不良です。判定には実ユーザーのフィールドデータの75パーセンタイルを使います。
- 対象はマウスクリック、タッチのタップ、キー押下の3種類です。スクロールとホバーは対象外です。
- ページのINPは通常、最も遅い操作の所要時間です。操作が多いページでは50回ごとに最も遅い1件を除外します。
- 1回の操作は入力遅延・処理時間・表示遅延の3区間に分かれます。改善は最も長い区間から着手します。
- 原因のスクリプトは、web-vitals の attribution ビルドが返す
longestScriptを手掛かりに絞り込めます。Chromium系ブラウザでは、呼び出し元・ファイル・関数名と、それがどの区間で走ったかが記録されます。 - ページ読み込みだけを観測するLighthouseに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指標をまとめた判定やCrUX APIでの取得はCore Web Vitalsとは：LCP・INP・CLSの基準値とweb-vitalsでの計測・改善手順で扱っています。
対象になる操作とならない操作
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.0.0（2024年5月）からで、inputDelay・processingDuration・presentationDelay の3つが同時に追加されました。v3以前を前提にした古いコードでは3区間の内訳が取れません。
表示遅延（presentation delay）の計測範囲と原因
コールバックの実行が終わってから、結果を反映したフレームが画面に出るまでの時間です。web-vitals のREADMEは、この区間に requestAnimationFrame() のコールバック、ResizeObserver と IntersectionObserver のコールバック、スタイルとレイアウトの計算、さらにコンポジターやGPUの処理まで含まれると説明しています。JavaScriptのハンドラーを削っても数値が動かないときは、ここを疑います。
FIDとの違いと移行後に残る計測の穴
FIDとINPの測定範囲の違い
FIDが測っていたのは、ページ読み込み後の最初の1回の操作について、コールバックが始まるまでの遅延だけでした。INPとの差は2点あります。対象が最初の1回からページ滞在中のすべての操作へ広がったことと、計測の終点が「処理が始まるまで」から「結果が描画されるまで」へ伸びたことです。
FIDは、INPでいう入力遅延を最初の1回だけ測った値に近いものです。「FIDの改善」を調べている場合は、この記事の入力遅延の改善がそれに当たります。ただし、INPではその後のハンドラー実行と描画まで測られるため、FIDで合格していたページがINPで不良になる例は普通に起きます。
2024年9月に止まったFIDの供給元
移行は2024年中に終わっています。2024年3月12日にINPがCore Web Vitalsの正式指標になり、Search ConsoleからはFIDが同日に外れました。CrUXとPageSpeed InsightsのAPIには移行期間が設けられ、CrUXのリリースノートは、FIDが2024年9月9日にCrUXを含むChromeのツールから削除されると予告していました。翌9月10日の告知が「本日をもってFIDはChromeのツールでサポートされなくなった」と終了を宣言しています。web-vitals ライブラリからも、v5.0.0（2025年5月）で onFID() が削除されました。
同じ告知は「変わらないのは、PerformanceObserver APIにおける first-input エントリのChromiumサポート」とも述べており、自前計測でFIDを取り続けることはできます。CrUXのBigQueryにも過去のFIDデータは残るため、FIDを表示し続けている社内ダッシュボードは、値が自前計測か履歴データかを確認してください。
INPの計測手段
INP計測におけるフィールドとラボの役割
最短の確認手段はPageSpeed InsightsでURLを入力することです。上部の実ユーザー環境での評価がCrUX由来のフィールドデータで、ここにINPが出ます。下部のLighthouseによる診断はラボデータで、INPは含まれません。web.dev のラボツール対応表でも、Chrome DevToolsはLCP・INP・CLSの3つとも計測できる一方、LighthouseはINPだけがバツ印で、注釈は「Lighthouseのように、ユーザーのいないシミュレーション環境でページを読み込むツールは、ユーザー入力が存在しないためINPを計測できない」と書いています。代わりにTotal Blocking Time（TBT）が挙げられますが、同ドキュメントは「TBTはINPそのものの代用にはならない」とも釘を刺しています。TBTの位置づけはWebパフォーマンス指標の一覧と使い分け｜TTFB・FCP・TBT・Speed Indexの基準と測り方、Lighthouseの採点はLighthouseのSEOスコア・Best Practicesの配点と見方｜5カテゴリの採点基準【v13.5.0】で整理しています。
ラボで遅い操作を再現するなら、Chrome DevToolsのパフォーマンスパネルを使います。Chrome 129で入ったライブ指標により、パネルを開いた直後の画面が自分の操作で発生したINPをその場で表示し、Interactions タブに操作ごとの要素・時間・区間を並べます。同じ画面でCrUXのフィールドデータを取得して自分の値と比べることもできます。操作を含めて記録すれば INP breakdown インサイトが最も遅い操作を3区間に分解し、そのドキュメントは実機より非力な環境を再現するために「CPUスロットリングを有効にする」ことを勧めています。
Search ConsoleでのINPの表示と改善の検証期間
Search Consoleのコアウェブバイタルレポートは、URLグループのステータスを3指標のうち最も悪い指標で決めます。公式の説明では、掲載の条件はLCPとCLSの両方に一定量のデータがあることで、INPは条件に挙がっていません。操作の少ないサイトでは、INPの値が無いままLCPとCLSだけで「良好」と表示されることがあります。レポートに問題が出ていないことは、INPが良好であることの証明になりません。
修正後に［修正を検証］からトラッキングを始めると28日間の監視が走り、その間どのURLにも問題が出なければ修正済みと判定されます。CrUX APIの値は直近28日分の集計を毎日更新したものなので、直した直後は古い期間のデータが多く残り、改善がすぐには表れません。サーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】ではレポートの開き方から扱っています。
web-vitalsライブラリでの自前計測
自社サイトに計測を埋め込むなら、Googleが公開している web-vitals ライブラリを使います。npm registryで確認した2026年11月5日時点の最新版は6.2.3（2026年10月5日公開）で、INPの後始末処理によるメモリリークの修正が入っています。attribution ビルドを読み込むと、遅かった操作の要素、3区間の内訳、原因スクリプトの情報まで受け取れます。次のコードはバンドラーで処理するブラウザ向けの例で、結果はコンソールに出すだけでサーバーへは送りません。
import { onINP } from 'web-vitals/attribution';
onINP(({ value, attribution: a }) => {
console.log(value, a.interactionTarget, a.inputDelay, a.processingDuration, a.presentationDelay);
const s = a.longestScript;
if (s) {
console.log(s.subpart, Math.round(s.intersectingDuration), s.entry.invoker, s.entry.sourceURL, s.entry.sourceFunctionName);
}
});コールバックは操作のたびには呼ばれず、web-vitals のREADMEのとおり、ページの visibilityState が hidden に変わった時点（タブの切り替えや画面を閉じる操作）で呼ばれます。仕込んだ直後にコンソールが空でも不具合ではありません。開発中に値の変化を見たいときは、第2引数に { reportAllChanges: true } を渡すと、INPが更新されるたびに呼ばれます。
SafariとFirefoxでのINP計測
INPを計算するにはEvent Timing APIの interactionId が必要です。MDNの互換性データでは、ChromeとEdgeが96、Firefoxが144、Safariが26.2（iOS版も26.2）で対応しています。WebKitのSafari 26.2の告知は、Event Timing APIの追加で「INPの計測が可能になる」と説明しています。web-vitals のREADMEも onINP() の対応ブラウザをChromium、Firefox、Safariと記載しています。現在は自前計測でSafariとFirefoxのINPも集められます。
一方、Googleの評価に使われるCrUXはChromeの利用者から集めたデータで、SafariやFirefoxの値は入りません。iPhone利用者が多いサイトでは、自前計測のINPがCrUXより悪く（または良く）出ることがあります。ブラウザ別に分けて集計し、CrUXと比べるのはChromeの値だけにします。実ユーザー計測の仕組み全般はリアルユーザーモニタリング（RUM）とは｜実ユーザー計測の仕組み・合成監視との違い・導入判断を実装目線で解説で比較しています。
INPが出ない・ツール間で値が食い違う場合の読み方
INPが報告されない3つのケース
web.dev は、ページがINP値を返さない理由として3つを挙げています。ページは読み込まれたがユーザーがクリック・タップ・キー押下のいずれも行わなかった場合、スクロールやホバーのような計測対象外の操作しかしなかった場合、検索クローラーやヘッドレスブラウザのようなボットが操作をスクリプト化せずにアクセスした場合です。
記事ページや会社案内のように読むだけで完結する導線では、1つ目と2つ目が日常的に起きます。PageSpeed InsightsでINPだけ空欄になるのは、多くの場合サイトの不具合ではなくデータ不足です。空欄だけでは改善の優先度を決められないので、検索・メニュー・問い合わせなどの主要操作をDevToolsで実測し、LCPやCLSの問題と影響の大きさを比べます。
CrUXと自前計測がずれる2つの理由
対象ユーザーや集計期間の違いに加えて、計測仕様に由来する要因が2つあります。1つ目は iframe です。公式ドキュメントは、埋め込み動画の再生ボタンを押すような iframe 内の操作もINPの対象だとしたうえで、「JavaScriptのWeb APIは iframe の中身にアクセスできないため、これがCrUXとRUMの差として現れることがある」と説明しています。埋め込み先で遅い操作が起きている場合、自前計測は応答性を実態より良く見せます。
2つ目は報告のしきい値です。PerformanceObserverでは、104ミリ秒未満の event エントリが既定では報告されません。登録時の durationThreshold で下げられますが、最小値は16ミリ秒です。また、Event Timingの duration は8ミリ秒単位に丸められます（web-vitals のREADME）。INPは平均値でもないため、独自実装より web-vitals を使うほうが確実です。
CrUXとRUMの評価・診断での使い分け
Googleの評価として見る数値はCrUX（PageSpeed InsightsとSearch Console）に限り、自前計測は「どの操作・どのスクリプトが遅いか」を特定する道具として使います。両者を同じ精度の数値として並べると、改善したのに評価が動かない理由を説明できなくなります。
ReactやVue.jsのようなSPAでは、画面遷移でページを読み込み直さないため、従来のINPは最初のURLに滞在中の全操作がまとめて計上されていました。Chromeの解説によると、Chrome 151からはURL変更を伴う画面遷移（ソフトナビゲーション）が既定で検出され、CrUXでも遷移ごとの値が試験的な指標として公開されています（2027年5月に正式な指標へ移す計画）。web-vitals v6で reportSoftNavs を有効にするとINPは遷移ごとにリセットされます。集計の組み方は前述の「Core Web Vitalsとは：LCP・INP・CLSの基準値とweb-vitalsでの計測・改善手順」で扱っています。
遅い原因のスクリプトを特定する手順（LoAFとlongestScript）
3区間の内訳が分かっても、どのスクリプトが時間を使ったかが分からなければ直せません。そこで使うのがLong Animation Frames API（LoAF）です。Chromeの解説によると、LoAFはChrome 116〜122のオリジントライアルを経てChrome 123で正式に搭載されました。50ミリ秒を超えたフレームについて、5ミリ秒を超えたスクリプトごとに呼び出し元（invoker）、ファイル（sourceURL）、関数名（sourceFunctionName）を記録します。MDNの互換性データではChromeとEdgeのみの対応で、FirefoxとSafariには実装がありません。
longestScriptで分かる呼び出し元と区間
web-vitals の attribution ビルドは、INPの操作と重なったLoAFの中から最も長いスクリプトを longestScript にまとめ、そのスクリプトが3区間のどこで走ったか（subpart）まで返します。この項目はv5.0.0で追加されました。2026年11月5日に、macOS上のGoogle Chrome 156.0.8078.80（ヘッドレス）とweb-vitals 6.2.3で、前節と同じ項目を reportAllChanges: true 付きで記録するページを作り、2つの典型的な遅延を3回ずつ再現した結果が次の表です。
| 再現した状況 | INP | 長かった区間 | invoker | subpart |
|---|---|---|---|---|
| clickのハンドラーで300ms処理 | 304〜312ms | 処理時間 302〜303ms | BUTTON#btn.onclick | processing-duration |
| クリック直前に300msのタイマー処理 | 264〜280ms | 入力遅延 254〜270ms | TimerHandler:setTimeout | input-delay |
2つ目の状況ではハンドラー自体は1〜2ミリ秒で終わっており、3区間だけを見ると「ボタンの処理に問題は無い」としか分かりません。longestScript は、原因が別のタイマー処理であることと、その関数名（sourceFunctionName）まで返しました。入力遅延が長いときに見るべきなのはイベントハンドラーではなく、この呼び出し元です。
サードパーティスクリプトが原因のときの判断
sourceURL が自社ドメイン以外を指していれば、広告・計測・チャットなどの外部タグを疑います。ただし自社のコードを外部のCDNから配信している場合もあるため、ドメインだけで断定せず、配信元とスクリプトの用途を確かめてから判断します。web.dev の入力遅延の最適化ガイドは、自社コードのタイマーなら必要性を見直して作業を減らせる一方、「サードパーティスクリプトのタイマーは話が別」だとし、そのスクリプトが本当に必要かを関係者と判断し、必要なら提供元に改善を求めることになると書いています。
外部タグの中身を自社で直せない場合の選択肢は、外す、読み込みや発火の条件を絞る、タグ管理画面や提供元の設定で処理を軽くする、提供元に改善を求める、のいずれかです。CrUXで不良が出ているページに、売上や問い合わせの計測に使っていないタグが残っているなら、まず外します。用途や必要性が分からないタグは、導入した広告・分析の担当者に確認してから扱いを決めます。タグの整理を含めたサイト改善の進め方は、一創のWebコンサルティング・アクセス解析でも支援しています。
区間別のINP改善手順
着手順は数値の大きさで決めます。INP breakdown のドキュメントが述べるとおり「最も長い区間の時間を削ることに集中する」のが原則で、3区間に均等に手を入れるのは非効率です。
入力遅延の改善：長いタスクの分割と制御の返却
入力遅延が支配的なら、操作を受ける前にメインスレッドを塞いでいる処理が原因です。web.dev は50ミリ秒を超えるタスクを長いタスク（long task）と定義しており、これを分割して合間にメインスレッドへ制御を返します。
制御を返す手段として推奨されているのは scheduler.yield() です。MDNの互換性データでは、Chrome 129（2024年9月17日に安定版）、Edge 129、Firefox 142で対応し、Safariは未対応です。setTimeout() で分割すると残りの処理はタスクキューの最後尾に回されますが、scheduler.yield() は中断した続きが優先して再開されます。web.dev の長いタスクの最適化ガイドは、未対応ブラウザでは setTimeout() に切り替える次の関数を示しています。
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}
// button と status は取得済みのDOM要素、saveToServer と sendAnalytics はアプリ側で定義した関数
button.addEventListener('click', async () => {
// 画面に出す更新だけを先に行う
status.textContent = '保存中';
// ここで描画の機会を渡す
await yieldToMain();
// 見えない処理は後続のタスクで行う
saveToServer();
sendAnalytics();
});前節と同じ300ミリ秒の処理を、表示更新のあと yieldToMain() を挟んでから実行するように変えたところ、Chrome 156でのINPは3回とも8ミリ秒になりました。ハンドラーは表示を書き換えた時点で制御を返し、次の描画が先に行われたためです。ただし、300ミリ秒の処理そのものは後続のタスクで走り続けます。その最中に次のクリックが来れば、今度はそのクリックの入力遅延になります。yield は処理を消す手段ではなく、ブラウザに描画などの機会を渡す手段で、後続の処理より先に描画されることを常に保証するものでもありません。重い処理そのものを減らすか、後述のWeb Workerへ移す作業は別に要ります。
かつて紹介されていた isInputPending() で「入力が来ているときだけ譲る」書き方は、公式に「このAPIの使用はもはや推奨しない」と撤回されています。入力の有無にかかわらず譲るのが現在の推奨です。
処理時間の改善：イベントハンドラーの作業量削減とWeb Worker
処理時間が長いなら、ハンドラーの中身そのものが重い状態です。公式の指針は「イベントコールバックの中では可能な限り作業を少なくする」ことで、ユーザーに見せる更新だけを同期的に行い、ログ送信・集計・先読みは前述の yield の後ろへ回します。
レイアウトに影響するスタイルを書き込んだ直後に offsetWidth のようなレイアウト値を読むと、ブラウザはその場でレイアウトを計算し直します（強制同期レイアウト）。ループの中で書き込みと読み取りを交互に繰り返すと、これが何度も起きるレイアウトスラッシングになります。読み取りをまとめてから書き込むように順序を分けます。
画像処理、大きなJSONの変換、検索インデックスの構築のようにDOMに触れない計算は、Web Workerでメインスレッドの外へ出せます。web.dev もINP改善の手段として「Web Workerを使ってJavaScriptをブラウザのメインスレッドの外で実行する」ことを挙げています。WorkerからはDOMを操作できず、データの受け渡しにコピーのコストがかかるため、移すのは計算だけにします。送れるデータの制約はWeb Workerとは？使い方とService Workerとの違い、送れるデータの制約を3ブラウザで実測で実測しています。
表示遅延の改善：DOM規模とレンダリング範囲の縮小
表示遅延が支配的なら、描画そのものが重い状態です。web.dev は大きなDOMが問題になる場面として、初回レンダリング時と、操作への応答としてのレンダリング更新が非常に高くつく場合の2つを挙げています。レンダリングの作業量はDOMサイズに単純比例するわけではありませんが、大きくなるほど増える傾向にあるため、無限スクロールや巨大なテーブルを持つ画面では要素数の削減が効きます。
画面外の要素には content-visibility による遅延レンダリングが公式に推奨されています。長いページで画面外のセクションの描画を後回しにでき、操作時のレンダリングコストを下げられます。JavaScriptでHTML文字列を組み立てて大量に挿入する実装も、描画コストが高くつくと指摘されています。
操作の少ない記事ページで、主要なリンクやメニューに遅い操作が見つからなければ、INPより他の改善を優先します。LCPやCLS、テクニカルSEOとは？施策一覧と進め方・チェックリスト【2026年版】で扱うクロールとインデックスの問題と並べ、支障の大きい順に着手します。
よくある質問
INPの目標値は何ミリ秒ですか？
200ミリ秒以下が良好、500ミリ秒超が不良です。判定はラボ計測の1回の値ではなく、実ユーザーのフィールドデータの75パーセンタイルで行われます。
スクロールが重いとINPは悪化しますか？
スクロール自体は計測対象外です。ただし、スクロールに伴う重い処理がクリックなどを待たせると、そのクリックの入力遅延としてINPが悪化します。スクロールの滑らかさそのものはINPとは別に追う必要があります。
INPを改善すると検索順位は上がりますか？
上がることはありますが、保証はされません。Googleのページエクスペリエンスの解説は「Core Web Vitalsはランキングシステムで使われている」と認める一方で、Search Consoleのコアウェブバイタルレポートなどで良い結果が出ても「Google検索の上位に表示されることを保証するものではない」と書き、内容の関連性を優先すると明記しています。差が付くのは、関連性の近いページが多数ある検索です。
FIDはもう見なくてよいのですか？
Core Web Vitalsの応答性指標はINPに置き換わりました。FIDは2024年9月9日を期限にCrUXなどChromeのツールから削除され、CrUXやPageSpeed InsightsのAPIからは取得できません。PerformanceObserver の first-input エントリは引き続き使えるため、自前計測で取り続けることは可能です。
INPが遅いとき、最初にどこを見るべきですか？
入力遅延・処理時間・表示遅延のうちどれが最も長いかを先に特定します。DevToolsのパフォーマンスパネルで操作を記録するか、web-vitals の attribution ビルドで longestScript が取れていればその呼び出し元と区間を見ます。スクリプト以外の描画負荷はDevToolsの記録で調べます。入力遅延が長ければ操作の直前に走っていた処理、処理時間が長ければイベントハンドラー、表示遅延が長ければレンダリングを直します。
