Core/Dashディメンション: Input Type (INP)

ディメンション: Input Type INP (inpit)

Input Type (INP)ディメンションは、ユーザーのページ訪問中に発生した単一の最悪なインタラクションをトリガーしたDOMイベントタイプを記録します。値は、ブラウザのEvent Timing APIから取得した生のイベント名です（click、keydown、pointerdown、pointerup、keypressなど）。

INPはワーストケースの指標です。インタラクションの平均値は算出しません。入力から次のペイントまでに最も時間がかかった1つのインタラクションを特定し、その所要時間を報告します。Input Typeディメンションは、その瞬間にユーザーが何をしていたかを示します。これが、「INPは450msである」とだけ知るのと、「ユーザーが検索フィールドに入力したため、INPが450msになっている」と知ることの違いです。

Event Timing APIは、関連するイベントを1つの論理的なインタラクションとしてグループ化します。タッチスクリーンでのタップは、pointerdown、pointerup、clickを1つのグループとして発火させます。そのグループ内で最も処理時間が長かったイベントハンドラーが、インタラクションのレイテンシを決定します。CoreDashは、インタラクションを遅くした原因である、最も実行時間が長かったハンドラーのイベントタイプを記録します。

INPにおいてInput Typeが重要な理由

各Input Typeは、JavaScriptコードベースの異なる部分に対応します。INPの低いページでkeydownが主要なInput Typeである場合、問題はキー入力ハンドラー（オートコンプリート、入力時検索、キー押下ごとに実行されるフォームバリデーションなど）にあるとすぐに判断できます。clickが表示されている場合、問題はボタンやリンクのハンドラー（ナビゲーションロジック、状態の更新、モーダル表示、同期的なアナリティクス呼び出しなど）にあります。

このディメンションがない場合、INP의調査は... wait! "INPの調査は" - let me check that.

このディメンションがない場合、INPの調査はプロファイリングセッションの実施、再現手順の作成、そして75パーセンタイルのユーザーがどのインタラクションを行おうとしていたかの推測から始めることになります。Input Typeディメンションがあれば、該当するハンドラーへ直接スキップできます。大幅な時間短縮になります。

Input Typeはプラットフォームの違いも明らかにします。パワーユーザーによるキーボードナビゲーションが多いサイトでは、INP悪化の原因としてkeydownイベントが高い割合を占めます。主にモバイルで利用されるプロダクトでは、pointerdownが支配的になります。同じページ、同じINPスコアであっても、実際のユーザーが誰であるかによって、異なるハンドラーに修正を適用することになります。

Input Typeの種類

click と pointerdown

これらはCoreDashのデータにおいて最も一般的なInput Typeであり、最悪のINPイベントの約75%を占めています。デスクトップでは、clickはマウスボタンを離す操作を表します。モバイルでは、タップによって一連のイベントチェーンが発火します。まず画面に指が触れたときにpointerdownが発火し、指が離れたときにpointerup、最後にclickが発火します。CoreDashは、このチェーンの中で最もハンドラーの処理時間が長かったイベントを記録します。

clickハンドラーは、重い同期JavaScript処理が実行される主な場所です。ナビゲーションアイテムを1回クリックするだけで、状態管理の更新、DOMの変更、アナリティクスイベント、そして再レンダリングがすべて同じタスク内でトリガーされることがあります。clickハンドラー内での同期処理が1ミリ秒増えるごとに、INPも1ミリ秒増加します。

遅いclickハンドラーに対する解決策は、タスクの分解です。scheduler.yield()を使用してハンドラーをより小さなタスクに分割し、タスクの合間にブラウザがレンダリングを行えるようにします。アナリティクス呼び出しのような重要度の低い処理は、遅延ゼロのsetTimeoutに移動するか、requestIdleCallbackへ完全に遅延させてください。ブラウザは、次のペイントの前に視覚的な応答に影響を与える処理だけを完了すればよいのです。それ以外の処理は後回しにできます。

keydown

キーボード入力は、CoreDashのデータにおいて最悪のINPイベントの約15%を占めるに過ぎませんが、極めて深刻なスコアを引き起こす傾向があります。その理由は発生頻度です。ユーザーが検索フィールドに入力すると、キーを押すたびにkeydownが発火します。もしハンドラーに200msかかると、ユーザーは文字を1文字入力するたびに200msの遅延を体感することになります。10文字の検索クエリを入力するだけで、累積ブロッキング時間は2秒に達します。

よくある原因は、キー入力のたびに同期APIリクエストを送信したり負荷の高いDOMの差分比較を実行したりする入力時検索（search-as-you-type）の実装や、キー押下のたびにフォーム全体を再検証するフォームバリデーションです。これらのパターンは小規模な環境では問題なく動作しますが、実際のユーザー環境では破綻します。

標準的な対策は、デバウンスとオフロードです。検索ハンドラーをデバウンスし、ユーザーが入力を止めてから（通常は200〜300ミリ秒後）発火するようにします。大規模なローカルデータセットに対するあいまい検索など、より複雑な処理を行う場合は、処理をWeb Workerに移行して、各keydownイベントの後にmain threadが次のフレームを描画できるように空けておきます。

pointerup

pointerupイベントは、CoreDashのデータにおいて最悪のINPケースの約8%を占めています。pointerupは、pointerdownの後、タッチまたはクリックシーケンスの最後に発火します。一部のフレームワークやUIライブラリは、主要な「クリック」時の挙動をclickではなくpointerupにバインドするため、ハンドラーがインタラクションのライフサイクルのより早い段階で実行されるようになります。

pointerupが主要なInput Typeとして現れる場合、調査方法はclickハンドラーと同様です。ハンドラー内で実行されるJavaScriptを特定し、次のペイントをブロックしなければならない処理と、後回しにできる処理を切り分けます。clickとの違いは通常、アプリケーション層ではなくフレームワーク層 of... wait! No "of"! "アプリケーション層ではなくフレームワーク層の設計によるものです。" -> Yes, correct.

pointerupが主要なInput Typeとして現れる場合、調査方法はclickハンドラーと同様です。ハンドラー内で実行されるJavaScriptを特定し、次のペイントをブロックしなければならない処理と、後回しにできる処理を切り分けます。clickとの違いは通常、アプリケーション層ではなくフレームワーク層の設計によるものです。そのため、コンポーネントライブラリによるインタラクションのバインド設定の調整が必要になる場合があります。

デバッグワークフロー

1. CoreDashでInput Typeを絞り込む: 問題が発生しているURLのINP内訳を開き、どのInput Typeが最悪のインタラクションの大部分を占めているか確認します。特定のタイプが悪いINPイベントの半分以上を占めている場合は、そこから着手してください。その分布によって、プロファイリングに時間を費やすべき箇所が分かります。
2. 適切なインタラクションで再現する: Chrome DevToolsを開き、Performanceプロファイリングを有効にして、CoreDashに表示されたものと同じインタラクションを実行します。keydownが支配的なページでは実際にタイピングしてテストし、clickが支配的なページではユーザーが操作する要素をマウスクリックしてテストします。トレースを記録し、入力イベントの直後に実行されるmain threadのlong taskを特定します。
3. タイプ別の修正を適用して検証する: keydownの問題にはデバウンスを追加して再プロファイリングを行います。clickの問題にはハンドラー内の論理的なブレークポイントでscheduler.yield()を呼び出します。テスト環境にデプロイし、インタラクションスクリプトを使用したWebPageTestまたはChrome DevTools Performance panelを利用して、本番リリースの前にタスクの処理時間が短縮されたことを確認します。

エンジニアリングの目安

• keydownが悪いINPの大部分を占める場合: すべての検索およびオートコンプリートのハンドラーにデバウンスを追加してください。200msの遅延が標準的な開始基準です。その遅延を設けても計算処理が重い場合は、Web Workerを使用して処理をmain threadから切り離してください。
• clickまたはpointerdownが大部分を占める場合: ブラウザが描画を行う前に、ハンドラーが過剰な同期処理を行っています。対象URLのすべてのclickハンドラーを監査してください。同期処理で行われるアナリティクス呼び出しは削除し、複数ステップにわたるロジックはステップ間にscheduler.yield()を入れて分割してください。
• pointerupが大部分を占める場合: フレームワークがインタラクションロジックをclickではなくpointerupにバインドしていないか確認してください。対処法は通常clickハンドラーと同様ですが、コードベースにおける介入箇所が異なります。
• 明確な偏りがない混合分布の場合: 問題は特定のインタラクションタイプに限りません。すべてのタイプを通じて最も遅い3つの個別インタラクションをプロファイリングし、影響の大きい順に対処してください。抽象的な予測で最適化を行ってはいけません。

Input Typeはルーティングのシグナルです。何が遅いかを直接示すものではなく、どこを調査すべきかを提示します。INPが低下した際にユーザーがクリック、タイピング、タップのどれを行っていたかが分かれば、その後のあらゆる調査ステップが迅速かつ的確なものになります。