Interaction to Next Paint（INP）

TL;DR — INPは、誰かがクリック、タップ、入力をしたとき、ページがどれだけ速く反応するかを測定します。ブラウザーは、訪問全体を通じてインタラクションから次の視覚更新までの間隔を計測し、おおむね最も遅いものを報告します。200 msms未満は良好、500 msms超は不良です。3つのCore Web Vitalsの1つであり、2024年にFirst Input Delayという古い指標に置き換わりました。

INPが実際に測定するもの

ボタンをクリックしたり、メニューをタップしたり、入力欄に文字を入力したりすると、ページが反応することを期待します。メニューが開き、チェックボックスにチェックが入り、テキストが表示される、といった反応です。**Interaction to Next Paint（INP）**は、その処理にかかる時間、つまりインタラクションから、変化を示す次のフレームをブラウザーが描画するまでの時間を測定します。

重要なのはここです。INPは1回のインタラクションだけを見るのではありません。訪問全体のすべてのクリック、タップ、キーボード入力を監視し、（ほぼ）最も遅いものを報告します。そのため、入力するたびに検索ボックスが0,5秒固まるような、たった1回のぎこちないインタラクションでも、全体のスコアを下げることがあります。

スクロール、ホバー、ズームは対象外です。測定されるのはクリック、タップ、キーボード操作だけです。

しきい値

INPはミリ秒単位で報告され、Googleは次の3段階に分類します。

• 良好（Good） — 200 msms以下
• 改善が必要（Needs improvement） — 200 msms超、500 msms以下
• 不良（Poor） — 500 msms超

文脈として、200 msmsは速いものの、余裕が大きい数字ではありません。クリックへの応答としてコードが行うすべての処理と、結果をブラウザーが描画する時間を、その中に収める必要があります。

FIDに取って代わった理由

以前の応答性指標は**First Input Delay（FID）**でした。FIDが測定したのは、ページで最初のインタラクションの処理が始まる前の遅延だけで、処理が始まった瞬間に計測を止めていました。その処理に実際どれだけ時間がかかったか、画面の更新にどれだけ時間がかかったかは数えていません。

INPはこれらをすべて解決しました。最初だけでなくすべてのインタラクションについて、開始から視覚的な更新までの全体の時間を測定します。Googleは2024年3月12日に切り替えを正式に行い、FIDは2024年9月までにツールから完全に消えました。 Evidence for this claim INP observes click, tap, and keyboard interaction latency throughout a page visit rather than measuring only the first input delay. Scope: Current web.dev INP definition and qualifying interaction types. Confidence: high · Verified: 2026-07-14 web.dev: Interaction to Next Paint

INPが悪化する理由を平易に説明すると

ほとんどの場合、JavaScriptがメインスレッドを占有していることが原因です。ブラウザーはそのスレッドで一度に1つの処理しかできないため、スクリプトの一部が実行中なら、クリックは順番待ちになります。よくある原因は次のとおりです。

• クリック／タップのハンドラー内で重い処理を実行している。
• 大きなJavaScriptの「長いタスク」がすべてをブロックしている。
• サードパーティースクリプト — アナリティクス、Cookie同意バナー、チャットウィジェット、タグマネージャー。単純なコンテンツサイトでも、最も悪影響の大きい原因の一部です。

大まかな解決策は、誰かが操作したときの処理を減らし、大きな仕事を小さな単位に分けて、ブラウザーがその間にインタラクションを処理できるようにすることです。

3つに分かれる遅延の内訳、75パーセンタイルの計算、原因ごとの正確な修正方法、SEOとの関係を知りたい場合は、Advancedタブへ切り替えてください。

TL;DR — INPは応答性を測るCore Web Vitalです。訪問全体にわたるすべてのクリック、タップ、キーボード操作の遅延を観察し、75パーセンタイル（50回のインタラクションごとに外れ値を1つ除外）を報告します。FIDのように最初の入力だけを見るのではありません。インタラクションの遅延 = 入力遅延 + 処理時間 + 表示遅延です。フィールドデータのp75で判定し、良好は≤ 200 msms、不良は> 500 msmsです。2024年3月12日にFIDに置き換わり、FIDは2024年9月にツールから完全に削除されました。長いタスクを分割し、scheduler.yield()でメインスレッドに制御を返し、イベントハンドラーの処理を減らし、DOMを小さくし、サードパーティースクリプトを遅延させて修正します。フィールド指標であり、Total Blocking Timeはラボでの代理指標ですが、両者が常に一致するわけではありません。

INPの測定内容とFIDとの違い

Googleの定義は正確です。INPは*“assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.”* (翻訳)「ユーザーのページ訪問期間全体で発生するすべてのクリック、タップ、キーボード操作の遅延を観察することで、ページのユーザー操作に対する全体的な応答性を評価します。」 Evidence for this claim INP observes click, tap, and keyboard interaction latency throughout a page visit rather than measuring only the first input delay. Scope: Current web.dev INP definition and qualifying interaction types. Confidence: high · Verified: 2026-07-14 web.dev: Interaction to Next Paint この「訪問期間全体にわたるすべてのインタラクション」という表現が核心です。INPは読み込み時間ではなく訪問単位の指標です。Googleの理由は、ユーザーがページで過ごす時間の大半は読み込み後に発生するため、最初の印象だけでなく利用中の応答性の方が重要だということです。

First Input Delayとの対比が、理解する最も簡単な方法です。“FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (翻訳)「FIDはページで最初に行われたインタラクションの入力遅延だけを測定しました。INPは、入力遅延からイベントハンドラーの実行にかかる時間まで、ページ上のすべてのインタラクションを観察することでFIDを改善します。」FIDが1つのインタラクションについて計測したのは、ハンドラーが始まるまでの待ち時間だけでした。ハンドラーの実行時間も、画面の更新時間も無視していました。INPはすべてのインタラクションの全体遅延を測定します。

よくある神話なので、正確に理解しておきたい注意点があります。INPは文字どおり最悪のインタラクションではありません。1回だけ偶然発生した急上昇でページを罰しないよう、ブラウザーは50回のインタラクションごとに外れ値を1つ落とし、ページビューの75パーセンタイルの値を報告します。インタラクションが少ない訪問では最も遅いインタラクションが該当しますが、多い訪問では先にいくつかの外れ値が除外されます。

インタラクションの定義も、一般に考えられているより狭いものです。測定されるのはクリック、タップ、キーボード入力だけです。スクロール、ホバー、ズームは明示的に除外されます。1回のジェスチャーが複数のイベントを発生させることもあります。タップはpointerdown、pointerup、clickを発生させますが、INPはこれを3つではなく1つのインタラクションにまとめます。そのグループ内では、すべての合計ではなく個々のイベントで最も長い処理時間を採用します。つまり、速いpointerdownと遅いclickが並んでいても、遅いイベントの長さによる1つのインタラクションとして報告されます。訪問中に対象となるインタラクションがなければ、INPはそのページについて報告されません。

インタラクション遅延を構成する3つの部分

すべてのインタラクションの遅延は、連続する3つの部分に分かれます。これは覚えておくべきモデルで、それぞれの部分が異なる修正方法を示します。

Interaction latency = Input delay + Processing duration + Presentation delay

1. 入力遅延（Input delay） — イベントハンドラーが実行を開始することさえできない前の時間です。通常は、メインスレッドが長いタスクを終えるのに忙しいことが原因です。
2. 処理時間（Processing duration） — すべてのイベントハンドラーのコールバックを実行するのにかかる時間です。
3. 表示遅延（Presentation delay） — ハンドラーの処理が終わってから、ブラウザーが画面上に次のフレームを描画するまでの時間です。

web-vitalsのattributionビルドは、この3つ（inputDelay、processingDuration、presentationDelay）をすべて公開するため、実際のインタラクションでどの部分が支配的かを確認できます。Web Almanacの2024年データによると、中央値では表示遅延が最大の単一要素であることが多いものの、最適化の余地が通常あるのは処理時間です。作りの悪いページでは、処理時間が膨らむためです。

しきい値とp75フィールドデータの注意点

Google Search Centralは目標を明確に示しています。“an INP of less than 200 milliseconds” (翻訳)「200ミリ秒未満のINP」です。また、プログラム全体を*“We highly recommend site owners achieve good Core Web Vitals for success with Search.”* (翻訳)「検索で成功するため、サイト所有者には良好なCore Web Vitalsを達成することを強く推奨します」と位置付けています。ブラウザーは60 fpsで約16,7 msmsごとにフレームを必要とするため、200 msmsの予算は実際に厳しいものです。ハンドラーの処理と描画を合わせて収める必要があります。 Evidence for this claim INP is good at 200 milliseconds or less and poor above 500 milliseconds, assessed at the 75th percentile. Scope: Current web.dev INP thresholds for field measurement. Confidence: high · Verified: 2026-07-14 web.dev: Interaction to Next Paint

INPがフィールド指標であり、ラボデータだけでは不十分な理由

多くのSEO担当者が陥る落とし穴です。Lighthouseのスコアが緑でも、INPが良好とは限りません。 ただし「LighthouseはINPを測定できない」という話には、3つの別々のケースがあります。1つにまとめると、自分のツールを読み違えます。

1. 標準的な非インタラクティブのLighthouse実行では、INPはまったく報告されません。 ページの読み込みだけを観察し、クリック、タップ、入力をしないため、時間を測るインタラクションがありません。代わりにLighthouseは、読み込み時間の代理指標として**Total Blocking Time（TBT）を使います。Google自身の説明は、“Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (翻訳)「TBTはINPとよく相関するため、TBTが高いページは読み込み中のINP値も高い可能性を示す妥当な指標です」です。重要なのは”during load.” (翻訳)「読み込み中」という言葉です。遅延読み込みされたウィジェットが10秒後に動いて悪化させるインタラクションについて、TBTは何も示しません。代理指標であって、代替でも変換式でもありません。
2. 手動または合成的に実行したインタラクション、つまりDevToolsで実際のボタンをクリックしたり、ラボツールでクリックをスクリプト化したりすると、その1回のインタラクションについて実際のINP型の遅延値が得られます。 特定のバグを再現するには有用です。しかし、1台のデバイスでの1つのスクリプト経路にすぎません。実際のデバイス、ユーザー、対象、訪問全体の時間が混ざったフィールドデータの代わりにはなりません。Googleが述べるように、結果の値は「測定期間中にどのインタラクションが実行されたか」に依存し、実際のユーザー行動は1回のラボ実行で表すには変動が大きすぎます。
3. フィールド分布こそが、INPの実体です。 そのため権威ある情報源はフィールドデータです。Chrome User Experience Report（CrUX）がPageSpeed InsightsとSearch ConsoleのCore Web Vitalsレポートに表示されます。“Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (翻訳)「実際のユーザーにとってどのインタラクションが問題かを理解するには、フィールドデータが利用できる最良の情報源です」。

ラボ（ケース1と2）は遅いインタラクションを見つけて再現するために使い、フィールド（ケース3）は実際の訪問者のスコアを本当に下げているか確認するために使います。

INPスコアが低い理由

ほぼすべてのINPの問題は、ユーザーが操作したときにメインスレッドがブロックされていることに行き着きます。典型的な原因は次のとおりです。

• 長いタスク。 メインスレッドで50 msmsを超えるタスクは長いタスクです。50 msmsを超えた分が「ブロッキング期間」になります。実行中はインタラクションを処理できません。最大の原因です。
• 重いイベントハンドラー。 クリック／入力ハンドラー内で同期的に処理しすぎると、処理時間が直接増えます。
• 大きなDOMサイズ。 DOMが大きいほど描画コストが増え、入力遅延と表示遅延の両方が膨らみます。
• サードパーティースクリプト。 Web Almanacによると、同意管理、タグマネージャー、アナリティクス、チャットウィジェットが主な原因です。単純なコンテンツサイトにも影響します。自分で作っていないページなら、最初に確認する場所です。
• 読み込み後のJavaScript。 ページが描画されたからといって読み込みが完了したとは限りません。最初の描画後に評価されるスクリプトが、初期のインタラクションをブロックすることがあります。

修正方法

影響が大きい順のおおまかな戦略は次のとおりです。

1. 長いタスクを分割する。 Googleがハンドラーについて示す基本的な助言は*“do as little work as possible in them.”* (翻訳)「ハンドラー内ではできるだけ処理を少なくする」です。大きな仕事を小さなタスクに分け、ブラウザーがその間にユーザーのインタラクションを処理できるようにします。タスクを分割すると、“the browser can respond to higher-priority work much sooner — including user interactions.” (翻訳)「ブラウザーは、ユーザーのインタラクションを含む優先度の高い処理に、はるかに早く応答できます」。

2. メインスレッドに制御を返す。 現代的で推奨される方法は**scheduler.yield()です（Chrome 129以降、Firefox 142以降）。await scheduler.yield()でコードを一時停止し、ブラウザーに保留中の処理を任せ、優先度付きで続行します。そのため、ほかのタスクが継続処理より先に割り込むことはありません。従来のフォールバックはsetTimeout(..., 0)で、今も動きますが、コードをタスクキューの最後へ送ります（ブラウザーはネストした呼び出しが何度か続くと5 msmsの下限を適用します）。やめるべきなのはisInputPending()です。Googleは現在、“we no longer recommend using this API.” (翻訳)「このAPIの使用はもはや推奨しません」と述べています。パターンはScripts**タブを見てください。

3. イベントハンドラーの処理を減らし、重要でない仕事を遅延させる。 次のフレームに必要な視覚更新だけを同期的に実行し、それ以外（保存、スペルチェック、アナリティクス、単語数の計算）はrequestAnimationFrame + setTimeoutまたはyieldの後ろに送ります。ユーザーにはすぐ反応が見え、記録処理はその後に行われます。

4. レイアウトのスラッシングを避ける。 同じタスク内でスタイルを書いた直後にレイアウトプロパティを読むと、本来まとめて処理できた同期レイアウトをブラウザーに強制します。読み取りをまとめ、その後に書き込みます。

5. DOMサイズを小さくする。 ツリーが小さいほど描画は速くなります。content-visibilityを使うと、画面外の要素を遅延描画でき、読み込みやインタラクション中のコストを抑えられます。

6. サードパーティースクリプトを監査して遅延させる。 実サイトで最も効果の大きいSEO修正です。同意、タグ、アナリティクスのスクリプトを遅延読み込みし、インタラクションを条件に実行するか、クリティカルパスから外します。「軽量な」コンテンツページでも、重い埋め込みウィジェットだけが原因でINPに失敗することがあります。

INPはランキングに影響するか

はい。INPは3つのCore Web Vitalsの1つであり、Core Web VitalsはGoogleのページエクスペリエンスシグナルの一部です。ただし、軽量なシグナルです。主要なランキング要因ではなく、関連性が同程度の結果間でのタイブレーカーです。コンテンツや関連性を犠牲にして完璧なINPスコアを追わないでください。

実務上のSEOポイントは2つあります。第一に、モバイルが重要な数字です。 2024年のWeb Almanacでは、INPに合格したサイトはモバイルで約74%、デスクトップで約97%でした。Googleはモバイルファーストでインデックスするため、重要なのはモバイルの数字です。第二に、複雑なサイトほど悪化します。 上位1 000サイトでは合格率が約53%にとどまりました。機能の多いページほどメインスレッドをブロックするJavaScriptを多く配信するためです。機能を重くする開発はINPのリスクになり、商品ページ、チェックアウト、検索結果、フォームなどインタラクションの多いページは、静的なコンテンツよりはるかに影響を受けます。

INPとFID — 全体像

FIDはなくなりました。INPが開始された日にSearch Consoleから削除され、2024年9月までにCrUXのBigQuery／APIからも削除されました。ツールや監査がまだFIDを参照しているなら、古い情報です。

INPのデータが食い違うエッジケース

「なぜRUMとCrUXが一致しないのか」という疑問の大半は、いくつかのライフサイクル上の癖で説明できます。

• インタラクションがなければINPもありません。 訪問中にクリック、タップ、キー入力が一度もなく、スクロールやホバーのような除外ジェスチャーしかなければ、そのページビューにINP値はありません。読み取り専用のコンテンツページでは正常であり、監視のバグではありません。
• iframeは指標に含まれますが、自分のJavaScriptは中を見られません。 埋め込まれたiframe（広告、ウィジェット、埋め込みフォーム）内のインタラクションはページのINPに加わります。しかし、ファーストパーティーのRUMスクリプトは、ブラウザー自身の指標のようにクロスオリジンiframeのイベントを読めません。そのため、サードパーティーの埋め込みがあるページでは、CrUXと同一オリジンのRUMが正当に一致しないことがあります。RUMとフィールドの不一致をバグとして扱わず、この差を記録してください。
• Back/forward cacheの復元はINPをゼロにリセットします。 bfcacheから戻ったページ（たとえば戻るボタン）は新しいINPのカウントを開始し、離脱前のインタラクションは引き継ぎません。
• 長時間開いたバックグラウンドタブも報告が必要です。 特にモバイルではOSがタブを終了するだけで、正式なアンロードが発生しないまま何時間も開いていることがあります。INPはアンロード時だけでなくページが非表示になった時点で取得すべきです。unloadでしか送信しないRUM設定は、こうした訪問のデータを静かに失います。

これはどこに位置づくか

INPはCore Web Vitalsの一部であり、読み込みのLargest Contentful Paintと視覚的安定性のCumulative Layout Shiftと並びます。PageSpeed InsightsとSearch Consoleのレポート（フィールド）で確認し、Lighthouse／Chrome DevTools（TBTを代理指標とするラボ）でデバッグします。すべての基礎となるデータはCrUXから来ます。

AI要約

Advanced版の要点をまとめます。

• INPは応答性を測るCore Web Vitalです。 訪問全体のすべてのクリック、タップ、キーボード操作の遅延を観察し、75パーセンタイル（50回のインタラクションごとに外れ値を1つ除外）の値を報告します。FIDのように最初の入力だけを見るのではありません。
• 遅延 = 入力遅延 + 処理時間 + 表示遅延です。それぞれが異なる修正方法を示し、通常は処理時間に最も改善余地があります。
• しきい値（フィールド、p75）： 良好≤ 200 msms、改善が必要≤ 500 msms、不良> 500 msmsです。
• 数えるのはクリック、タップ、キーボードだけです。スクロール、ホバー、ズームは除外され、1回のジェスチャーに含まれる複数イベントは1つのインタラクションにまとめられます。
• 2024年3月12日にFIDに置き換わりました（FIDは2024年9月にツールから完全削除）。FIDが測定したのは最初のインタラクションの入力遅延だけです。
• フィールド指標であり、「Lighthouseは測定できない」には3つのケースがあります。 標準的な非インタラクティブ実行はINPを報告せず、読み込み時間の代理としてTotal Blocking Timeに頼ります。手動で操作したラボのインタラクションは1回分の実際の遅延を出せますが、フィールドの母集団の代わりにはなりません。権威があるのはCrUX、PageSpeed Insights、Search Consoleのフィールドデータだけです。
• 原因： 長いタスク（> 50 msms）、重いイベントハンドラー、大きなDOM、特にサードパーティースクリプト（同意、タグマネージャー、アナリティクス、チャット）です。
• 修正： 長いタスクを分割し、scheduler.yield()（setTimeoutフォールバック。isInputPending()は推奨されなくなりました）で制御を返し、ハンドラーの処理を減らし、レイアウトのスラッシングを避け、DOMを小さくし、サードパーティースクリプトを遅延させます。
• エッジケース： 対象となるインタラクションがなければINP値はなく、iframeのインタラクションは指標に含まれますが同一オリジンのRUMスクリプトは中を見られません。bfcacheの復元はINPをリセットし、長時間開いたバックグラウンドタブはアンロード時だけでなく非表示時に報告すべきです。
• SEO： 軽量なランキングシグナルです。モバイルファーストインデックスではモバイル（合格率は約74%、デスクトップは約97%）の数字が重要で、インタラクションの多いページほど影響を受けます。

公式ドキュメント

GoogleとChromeチームによる一次情報源のドキュメントです。

web.dev — INPの参考資料

• Interaction to Next Paint (INP) — 測定内容、3つの遅延の内訳、インタラクションの種類、しきい値を説明する決定版の定義です。
• Optimize Interaction to Next Paint — ハンドラーの処理を減らす、重要でない処理を遅延させる、レイアウトのスラッシング、DOMサイズ、content-visibilityを扱う最適化プレイブックです。
• Interaction to Next Paint officially becomes a Core Web Vital — 2024年3月12日の開始記事（Jeremy WagnerとRick Viscomi）とFID廃止の時系列です。
• First Input Delay (FID) — 廃止された指標、その測定内容、置き換えられた理由です。
• A new responsive metric: seeking your feedback — FIDの設計上の限界とINPの改善です。
• Optimize long tasks — 50 msmsの長いタスクの定義、scheduler.yield()、setTimeoutフォールバック、isInputPending()が推奨されなくなった理由です。
• Script evaluation and long tasks — INPの代理指標としてのTBTとスクリプトサイズのガイダンスです。
• Find slow interactions in the field — web-vitalsのattributionビルドとLong Animation Frames（LoAF）APIです。

Chrome／Google検索

• Performance features reference (Chrome DevTools) — Interactionsトラック、Live Metrics、200 msmsの警告です。
• CrUX release notes — 2024年9月にBigQuery／APIからFIDが削除されたことを確認できます。
• Core Web Vitals & Google Search results — ページエクスペリエンスシグナルの一部としてのINPと、≤ 200 msmsの目標です。

出典からの引用

Google／Chromeチームによる記録に残る発言です。各リンクは、出典ページの引用箇所へ移動するディープリンクです。

INPの測定内容とFIDとの違い

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (翻訳)「INPは、ユーザーのページ訪問期間全体で発生するすべてのクリック、タップ、キーボード操作の遅延を観察することで、ページのユーザー操作に対する全体的な応答性を評価するCore Web Vitals指標です。」 — web.dev、Interaction to Next Paint (INP)。 引用へ移動
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (翻訳)「FIDはページで最初に行われたインタラクションの入力遅延だけを測定しました。INPは、入力遅延からイベントハンドラーの実行時間まで、ページ上のすべてのインタラクションを観察することでFIDを改善します。」 引用へ移動
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (翻訳)「First Input Delay（FID）はもはやCore Web Vitalではなく、Interaction to Next Paint（INP）指標に置き換えられました。」 — web.dev、First Input Delay (FID)。 引用へ移動

FIDからINPへの切り替え

• “FID will be deprecated.” (翻訳)「FIDは廃止されます。」 — Jeremy WagnerとRick Viscomi、web.devブログ、Interaction to Next Paint officially becomes a Core Web Vital。 引用へ移動
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (翻訳)「3月12日にINPがCore Web Vitalになると同時に、FIDはGoogle Search Consoleから削除されます。」 引用へ移動

長いタスク — 主な原因

• “Any task that takes longer than 50 milliseconds is a long task.” (翻訳)「50ミリ秒を超えるタスクは長いタスクです。」 — web.dev、Optimize long tasks。 引用へ移動

フィールドデータが第一

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (翻訳)「実際のユーザーにとってどのインタラクションが問題かを理解するには、フィールドデータが利用できる最良の情報源です。」 — web.dev、Find slow interactions in the field。 引用へ移動

Google検索

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (翻訳)「検索で成功するため、サイト所有者には良好なCore Web Vitalsを達成することを強く推奨します。」 — Google Search Central、Core Web Vitals & Google Search results。 出典

INP修正チェックリスト

上から順番に進めます。上の項目ほど数字を動かしやすい傾向があります。

• ラボスコアだけでなくフィールドのINP（PageSpeed Insights／Search Console CWVレポート）を取得し、モバイルを別に確認する。
• web-vitalsのattributionビルドまたはChrome DevToolsのInteractionsトラックで、200 msmsを超える遅いインタラクションを特定する。
• 長いタスク（メインスレッドで50 msms超）を見つけて分割する。
• 長いループ内でメインスレッドに制御を返す。scheduler.yield()を使い、setTimeout(..., 0)をフォールバックにする（isInputPending()の使用はやめる）。
• 各ハンドラー内では描画に必要な更新だけを同期的に実行し、保存、検証、スペルチェック、アナリティクスをrAF + setTimeoutの後ろに遅延させる。
• レイアウトのスラッシングを確認する。同じタスクでスタイルを書いた直後にレイアウトを読んでいないか確認し、読み取りをまとめてから書き込む。
• サードパーティースクリプト（同意、タグマネージャー、アナリティクス、チャット）を監査する。遅延、遅延読み込み、またはインタラクションを条件に実行する。通常、最大の改善が得られる項目です。
• DOMサイズを小さくし、画面外のセクションにcontent-visibilityを適用する。
• 重要でないJavaScriptを遅延またはコード分割し、読み込み後のスクリプトが初期インタラクションをブロックしないようにする。
• デプロイ後にフィールドで再測定する。CrUXは28日間の移動ウィンドウなので、スコアはゆっくり変わります。

INPとFID — チートシート

早見表

• しきい値（フィールド、p75）：良好≤ 200 msms・改善が必要≤ 500 msms・不良> 500 msms。
• 対象：クリック、タップ、キーボード。**除外：**スクロール、ホバー、ズーム。
• 遅延 = 入力遅延 + 処理時間 + 表示遅延。
• 長いタスク = メインスレッドで**> 50 msms**のタスク。
• ラボの代理指標：Total Blocking Time。相関はありますが、読み込み時間のブロッキングだけを反映します。権威ある情報源はフィールドデータ（CrUX）です。
• モバイルの合格率（約74%）はデスクトップ（約97%）を大きく下回り、SEOで重要なのはモバイルです。

メインスレッドに制御を返す

長いループ（大きなリストの描画やクリック時のデータ処理など）がある場合は、定期的に制御をブラウザーへ返し、保留中のユーザーインタラクションを処理できるようにします。現代的なAPIは**scheduler.yield()**です。対応していない場合はsetTimeoutにフォールバックします。

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

いくつか注意点があります。

• scheduler.yield()は将来のタスクで解決するPromiseを返し、その継続処理には優先度が付きます。キューにあるほかのタスクが、再開したコードより先に割り込むことはありません。
• setTimeout(..., 0)はどこでも動きますが、継続処理をキューの最後へ送ります（ブラウザーはネストした呼び出しが何度か続くと約5 msmsの下限を適用します）。
• isInputPending()には頼らないでください。Googleは*“no longer recommend[s] using this API.”* (翻訳)「このAPIはもはや推奨しない」と述べています。

ハンドラー内の重要でない処理を遅延させる

次のフレームに必要な処理だけを実行し、残りは描画の後ろに送ります。

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

INPを測定・修正するツール

フィールド（権威あり — Googleがスコア化するデータ）

• PageSpeed Insights — URL／オリジンのCrUXフィールドINPをモバイルとデスクトップに分けて表示し、ラボ診断も行います。
• Search Console — Core Web Vitalsレポート — フィールドデータに基づき、URLのINP状態を問題別にまとめます。
• CrUX — 基盤となるChrome User Experience Reportデータセットです（CrUX API／BigQueryからもクエリできます）。

ラボ／デバッグ

• Chrome DevTools — Performanceパネル — Interactionsトラックが各インタラクションの入力遅延、処理時間、表示遅延を測定し、200 msms超を示します。Live Metricsはクリックするたびに更新されます。
• Lighthouse — INPを直接測定できず、ラボの代理指標としてTotal Blocking Timeを報告します。

リアルユーザーモニタリング（RUM）

• web-vitals JavaScriptライブラリ — 値にはonINP()を使います。attributionビルド（web-vitals/attribution）はinputDelay／processingDuration／presentationDelay、interactionTargetセレクター、LoAFエントリを公開し、遅いインタラクションの原因となったスクリプトと要素を正確に確認できます。どのRUM設定を使う場合も、サンプリング率とattributionの対象範囲を記録してください。その文脈なしに引用したRUMの数字はCrUXのフィールドp75と比較できず、集計指標のようにクロスオリジンiframeの中を見ることもできません（Advancedタブのエッジケースを参照）。

ツール自体のスコアの付け方

このページが説明する指標の実例として、著名なページ速度・監視サービスを、それぞれの実ユーザーモバイルINP（Chrome UX Reportのフィールドデータ）で順位付けしたものがあります。

INPで見当違いになりやすい修正

最初のインタラクションだけを最適化する

INPは最初の入力だけでなく、訪問全体のインタラクションを評価します。ページが応答性を持つと判断する前に、メニュー、検索、フィルター、フォーム、その他の繰り返し使う操作を実行してください。

Total Blocking Timeを結果として扱う

TBTは長いメインスレッドタスクを見つけられるため有用なラボ代理指標ですが、フィールドのINPではありません。候補を見つけるために使い、フィールドデータまたはインタラクションのトレースで実際の操作を検証してください。

すべての処理を1つの遅延コールバックへ移す

大きなブロックを遅延させるだけでは、フリーズを移動したにすぎません。仕事を小さなタスクに分け、yieldしてブラウザーがその間に描画できるようにします。

ハンドラーを短くするために視覚的なフィードバックを削除する

反応を示さずに処理するコントロールは、依然として壊れているように感じられます。まず即時の状態変化を描画し、その後に重要でないフォローアップ処理を遅延させます。

3つの遅延モデルでINPを診断する

遅いインタラクションには、調べる場所が3つあります。

1. 入力遅延： 先行するメインスレッドの処理がまだ実行中で、イベントが待たされました。ハンドラーが始まる前の長いタスクとサードパーティーJavaScriptを監査します。
2. 処理時間： イベントハンドラー自体が処理しすぎています。同期処理を減らし、ループを分割し、次のフレームに不要な処理を後回しにします。
3. 表示遅延： ハンドラーの後にスタイル、レイアウト、描画に時間がかかっています。DOMの複雑さを減らし、レイアウト計算を繰り返し強制しないようにします。

トレースで最も大きい段階から始めます。変更するたびに同じインタラクションを再記録し、速くなったハンドラーが新しい表示ボトルネックを隠していないことを確認します。

INPの変更でインタラクションが改善したことを証明する

ハンドラーのyieldテスト

実行するテスト： Performanceパネルで対象のインタラクションを、長い処理を分割またはyieldする前後に記録します。期待結果： インタラクションの処理区間が短くなるか、描画によって分割されます。失敗の解釈： 高コストの処理が別の場所にあるか、依然として同期的に実行されています。監視期間： 繰り返しのトレースでは直ちに確認します。ロールバックの条件： コントロールの更新順が崩れる、状態を失う、新しい入力エラーが発生する。

表示テスト

実行するテスト： イベントハンドラーの後に、同じトレースのスタイル、レイアウト、描画処理を確認します。期待結果： より大きなレイアウトタスクを発生させずに、次の描画が早く到着します。失敗の解釈： DOMサイズまたは強制レイアウトが依然としてボトルネックです。監視期間： ラボのトレースでは直ちに確認します。ロールバックの条件： 視覚的な応答が不完全または不安定になる。

フィールドでの確認

実行するテスト： 変更したインタラクションとテンプレートについて、リリース後のonINP()のattributionをベースラインと比較します。期待結果： p75 INPが改善し、対象要素が遅いイベントを支配しなくなります。失敗の解釈： ラボのケースが実際のデバイスまたは訪問経路を表していませんでした。監視期間： 訪問が届く間はRUMで、CrUXでは移動する28日間で確認します。ロールバックの条件： デプロイ後、応答性またはインタラクションの完了が一貫して悪化する。

追跡する価値のあるINP指標

p75の実ユーザーINP

指標： テンプレートとデバイスクラス別の75パーセンタイルINP。分かること： 実際の訪問が全行程を通じて応答性を持つかどうか。取得方法： CrUX、PageSpeed Insights、またはweb-vitals RUM。ベンチマーク／現実的な範囲： 200 msms以下は良好、500 msms超は不良。頻度： JavaScriptのリリース後に監視し、移動するフィールドの傾向を毎月確認します。

遅いインタラクション率

指標： 対象別に集計した、200 msmsを超える測定済みインタラクションの割合。分かること： ページレベルのp75が合格していても、どのコントロールがユーザーに見える遅延を最も多く生むか。取得方法： web-vitalsのattributionビルド、またはRUMのEvent Timingデータ。ベンチマーク／現実的な範囲： 訪問経路ごとにベースラインを設定し、発生量が最も多い原因を減らします。頻度： アプリケーション型テンプレートでは毎週。

遅延段階の割合

指標： 遅いインタラクションの入力遅延、処理時間、表示遅延。分かること： 主な制約がスケジューリング、ハンドラーコード、描画のどれか。取得方法： DevToolsのトレースとINPのattribution。ベンチマーク／現実的な範囲： 健全な普遍的割合はありません。各段階を自身のベースラインと、合格基準である合計200 msmsに対して比較します。頻度： 集中的なパフォーマンス調査のたびに。

時間を使う価値のあるリソース

Google／Chrome（基本資料）

• Interaction to Next Paint (INP) — まずここから。
• Optimize Interaction to Next Paint — 修正方法。
• Optimize long tasks — yieldとscheduler.yield()。
• Find slow interactions in the field — LoAFとattributionによるデバッグ。
• INP becomes a Core Web Vital — 2024年3月12日の開始。

データ

• Web Almanac 2024 — Performance — 実環境でのINP合格率とサブパートの中央値。

業界の情報源

• INP — MDN Web Docs — Google以外のブラウザー対応と指標定義を確認するのに適したMDNのリファレンスです。
• Scheduler API: scheduler.yield() — MDN — メインスレッドへ制御を返す基本機能のブラウザー対応表と仕様です。
• PerformanceEventTiming — MDN — INPが読み取る基盤のブラウザーAPIで、生のイベントタイミングを調べるときに役立ちます。
• Long Animation Frames API — Chrome Platform Status — web-vitalsライブラリでINPのattributionを支えるLoAFのブラウザー対応状況です。
• INP topic — Search Engine Land — 実務家によるINPの更新、テスト結果、FIDからINPへの移行に関する業界報道です。

引用する価値のある統計

• モバイル約74%対デスクトップ約97%がINPに合格（2024年）。モバイルは大幅に難しく、Googleはモバイルファーストでインデックスするため、SEOで重要なのはこの数字です。 Web Almanac 2024
• 上位1 000サイトの合格率は約53%にすぎない — 機能の多いサイトはメインスレッドをブロックするJavaScriptを多く配信するため、最大規模のサイトほど悪化することがあります。 Web Almanac 2024
• 長いタスク = > 50 msms。 メインスレッドで50 msmsを超える処理は、ブラウザーがインタラクションに応答するのをブロックします。INPが悪化する直接の仕組みです。 web.dev — Optimize long tasks
• サブパートの中央値（2024年）： 表示遅延は中央値で約36 msmsと最大の単一要因になることが多く、入力遅延と処理時間がp75で近くに続きます。どの3分の1から対処するかを判断するのに役立ちます。 Web Almanac 2024

動画

• Google Chrome Developers（YouTube）— ChromeチームによるCore Web VitalsとINPの解説動画で、DevToolsで遅いインタラクションを診断する手順も含みます。チャンネル

自分で試す：Interaction to Next Paint

応答性とINPの診断についての5つの簡単な質問です。それぞれの答えを選び、後で確認してください。

変更履歴