Interaction to Next Paint（INP）は、Event Timing API のデータを使用してページの応答性を評価する安定版の Core Web Vitals 指標です。INP は、ページに対するすべてのクリック、タップ、キーボード操作のレイテンシをモニタリングし、外れ値を無視して最長の継続時間を報告します。INP が低いということは、ページが大多数のユーザー インタラクションに一貫してすばやく対応できることを意味します。
応答性の良さとは、ページの操作にすばやく反応することを意味します。ページが操作に応答すると、ブラウザはレンダリングする次のフレームに視覚的フィードバックを表示し、操作が成功したことを示します。たとえば、次のようなフィードバックを提供できます。
- オンライン ショッピング カートに追加した商品が実際に追加されているかどうかを示します。
- モバイル ナビゲーション メニューが開かれたかどうか。
- ログインのコンテンツがサーバーによって認証されるかどうか。
操作によっては、当然ながら他の操作より時間がかかることもありますが、特に複雑な操作の場合は、最初の視覚的なフィードバックをすばやく表示して、何が起こっているのかをユーザーに伝えることが重要です。これが最も早い段階は、次のペイントまでの時間です。したがって、INP の目的は、インタラクションのすべての最終的な効果（ネットワークの取得や他の非同期処理による UI の更新など）ではなく、次のペイントがブロックされた時間を測定することです。視覚的なフィードバックを遅らせることで、ページが操作に反応していないとユーザーに思わせることになります。
INP の目標は、ユーザーが開始したすべてのインタラクションまたはほとんどのインタラクションについて、ユーザーがインタラクションを開始してから次のフレームがペイントされるまでの時間を最小限に抑えることです。
INP は、ページで行われたすべてのインタラクションを観測することで計算されます。ほとんどのサイトでは、レイテンシが最も低いインタラクションは INP として報告されます。ただし、インタラクションの数が多いページの場合、ランダムな中断により、レスポンシブ サイトでのインタラクションが異常に長くなる可能性があります。インタラクションが多いほど、この可能性は高くなります。これに対処し、このようなタイプのページの実際の応答性をより正確に測定するために、Google は 50 回のインタラクションごとに最も高いインタラクションを 1 つ無視します。大多数のページ エクスペリエンスでは 50 回を超えるインタラクションがないため、ブラウザはほぼ常に最低のインタラクションを報告します。その後、すべてのページビューの 75 パーセンタイルが通常どおりレポートされます。これにより、一般的なユーザー エクスペリエンスをより正確に表す値に外れ値が除外されます。
インタラクションとは、同じ論理ユーザー ジェスチャー中に呼び出されるイベント ハンドラのグループです。たとえば、タッチスクリーン デバイスでの「タップ」操作には、pointerup、pointerdown、click などの複数のイベントが含まれます。操作は、JavaScript、CSS、フォーム要素などの組み込みのブラウザ コントロール、またはこれらの組み合わせによって行われます。
インタラクションのレイテンシは、ユーザーがインタラクションを開始してから次のフレームに視覚的なフィードバックが表示されるまでの、インタラクションを実行するイベント ハンドラのグループの中で最も長い時間で構成されます。
重要なポイント: INP の測定方法について詳しくは、インタラクションの内容をご覧ください。
良好な INP スコアとはどのようなものですか？
優れた応答性でユーザー エクスペリエンスを提供するには、フィールドで記録されたページ読み込みの 75 パーセンタイルを、モバイル デバイスとデスクトップ デバイスでセグメント化して測定するしきい値として適しています。
- INP が 200 ミリ秒以下であれば、ページの応答性が良好であることを意味します。
- INP が 200 ミリ秒～500 ミリ秒の場合、ページの応答性は改善が必要です。
- INP が 500 ミリ秒を超える場合は、ページの応答性が低いことを意味します。
インタラクションとは
多くの場合、インタラクティビティの主な要因は JavaScript です。ただし、ブラウザは、チェックボックス、ラジオボタン、CSS をベースとするコントロールなど、JavaScript に頼らないコントロールを通じてインタラクティビティを提供します。
INP では、次のインタラクション タイプのみが認められます。
- マウスでクリックする。
- タッチスクリーンでデバイスをタップする。
- 物理キーボードまたは画面キーボードのキーを押す。
キーポイント: ホバーとスクロールは INP には含まれません。ただし、キーボードによるスクロール（Space キー、PageUp、PageDown など）はキー入力を伴うため、INP が測定する他のイベントがトリガーされる可能性があります。発生するスクロールは INP の計算で考慮されません。
操作は、メイン ドキュメントまたはドキュメントに埋め込まれた iframe 内で発生します（たとえば、埋め込み動画での再生のクリック）。エンドユーザーはページのどの部分が iframe 内にあるかわからないため、iframe 内の INP を測定してページ全体を正確に測定する必要があります。ただし、JavaScript ウェブ API は iframe コンテンツにアクセスできず、iframe 内の INP を測定できない場合があります。これは、CrUX と RUM の違いを表しています。
インタラクションは複数のイベントで構成できます。たとえば、キー入力には keydown、keypress、keyup イベントが含まれ、タップ操作には pointerup イベントと pointerdown イベントが含まれます。インタラクション内の時間が最も長いイベントが、インタラクションのレイテンシとして選択されます。
INP は、ユーザーがページから離れたときに計算され、その結果、そのライフサイクル全体にわたるページの全体的な応答性を表す単一の値になります。INP が低いということは、ページがユーザー入力に確実に反応していることを意味します。
INP と FID（First Input Delay）の違いは何ですか？
INP は初回入力遅延（FID）の後継指標です。どちらも応答性の指標ですが、FID はページでの初回操作の入力遅延のみを測定しました。INP は、入力遅延からイベント ハンドラの実行に要する時間、そして最終的にブラウザが次のフレームをペイントするまでのすべてのページ インタラクションを考慮することで、FID を改善します。
これらの違いは、INP と FID の両方が異なる種類の応答性指標であることを意味します。FID は、ユーザーにページの最初の印象を与えるように設計された読み込み応答性の指標でしたが、INP はページ操作がいつ発生するかに関係なく、全体的な応答性をより信頼できるインジケーターです。
INP 値が報告されない場合はどうなりますか？
ページが INP 値を返さない場合もあります。これには、次のようなさまざまな理由が考えられます。
- ページが読み込まれましたが、ユーザーが操作したことはありません。
- ページは読み込まれたが、ユーザーが要素のスクロールやカーソルを合わせるなど、測定されない操作で操作した。
- ページを操作するスクリプトを作成していない bot（検索クローラーやヘッドレス ブラウザなど）がページにアクセスしている。
INP の測定方法
INP は、現場とラボの両方で、さまざまなツールを使用して測定できます。
重要なポイント: ウェブサイトの INP を測定する最良の方法は、現場の実際のユーザーから指標を収集することです。パフォーマンスの評価にラボのデータを使い慣れている場合は、ラボデータとフィールド データに差異が生じる理由（およびその対処方法）をご覧ください。
業務の現場
INP の最適化に向けた取り組みは、フィールド データから始めるのが理想的です。最良の場合、Real User Monitoring（RUM）のフィールド データは、ページの INP 値だけでなく、INP 値自体の原因となった特定のインタラクション、ページ読み込み中または読み込み後にインタラクションが発生したか、インタラクションの種類（クリック、キー押下、タップ）などの有益な情報をハイライト表示するコンテキスト データも提供します。
ウェブサイトが Chrome ユーザー エクスペリエンス レポート（CrUX）の対象である場合は、他の Core Web Vitals のデータとともに、PageSpeed Insights の CrUX を通じて INP フィールド データをすばやく取得できます。少なくとも、ウェブサイトの INP のオリジン レベルの画像を取得できますが、ページレベルのデータを取得できる場合もあります。
CrUX では、大まかには問題があることはわかるものの、問題を完全に理解するには十分な情報が得られないことがよくあります。RUM ソリューションは、遅いインタラクションが発生しているページ、ユーザー、ユーザー操作の詳細を明らかにするのに役立ちます。INP を個々のインタラクションに帰属させることができれば、当て推量や無駄な労力を回避できます。
実験室
インタラクションが遅いことを示すフィールド データが得られたら、ラボでテストを開始するのが理想的です。ただし、フィールド データがない場合は、遅いインタラクションをラボで再現するための戦略がいくつかあります。戦略としては、一般的なユーザーフローに沿って操作をテストすることや、メインスレッドが頻繁にビジー状態になることが多い読み込み中のページでの操作を行い、ユーザー エクスペリエンスの重要な部分で低速なインタラクションを明らかにする、などの戦略があります。
INP を改善する方法
現場で遅いインタラクションを特定し、ラボデータを使用して最適化するためのガイダンスについては、INP の最適化に関するガイドのコレクションをご覧ください。
変更履歴
指標の測定に使用する API や、指標自体の定義にバグが見つかることもあります。そのため、変更が必要になることがあり、これらの変更は、内部レポートとダッシュボードに改善または回帰として表示されることがあります。
これを管理できるように、これらの指標の実装または定義に対するすべての変更は、こちらの変更履歴に掲載されています。
これらの指標に関するフィードバックがある場合は、web-vitals-feedback Google グループからお知らせください。