INPとは？200msの基準・測定方法と遅い操作の改善手順

INPが測る操作と測らない待ち時間

INPはページの読み込み中を含め、利用中に行われた対象操作を観測します。対象はクリック、タップ、キー入力などで、スクロールやホバーそのものを測る指標ではありません。また、次の描画までの応答であり、その後のすべての通信や業務処理の完了時間を表すものではありません。詳しい範囲はINPの公式解説に基づいて確認します。

たとえば購入ボタンにすぐ処理中の表示が出ても、決済完了まで長く待つことはあります。その場合、INPと決済完了時間を別々に確認します。反対に通信が速くても、ブラウザの処理が詰まって表示が更新されなければ操作は遅く感じられます。

200msと500msの境界を正しく読む

1回のページ利用におけるINPは、対象操作の遅延から代表値を選びます。単純な全操作の平均ではありません。操作数が50回増えるごとに最も遅い操作を1回分除外する考え方で、操作が少ない多くの利用では最も遅い操作が代表になります。

それとは別に、実利用データの評価では、ページ利用ごとの値の75パーセンタイルを見ます。モバイルとデスクトップも分けて評価します。「1ページ利用内の代表値の選び方」と「多くの利用を集めた75パーセンタイル」は異なる段階です。1回だけ200ms以下になった結果を、すべての利用者が良好だった証拠にしないでください。

実利用データと手元の再現を使い分ける

PageSpeed Insightsのフィールドデータは、CrUXによる直近28日間の実利用データです。個別URLのデータが十分でない場合はオリジン単位のデータが示されることがあり、それも不足すれば表示されません。表示がないことは、問題がないことやINPが0であることを意味しません。データ単位はPageSpeed Insightsの公式説明で確認できます。

TBTはメインスレッドのブロック状況を調べる手掛かりですが、INPと同じ指標ではなく、決まった式で変換することもできません。手元では実際に対象操作を行い、応答と処理を記録します。

旧Web Vitals Chrome拡張機能は、Chrome 132でDevToolsに機能が統合されたことに伴いサポートが終了しています。現在の確認はChrome公式の案内に従い、DevToolsのPerformanceパネルのライブ指標や操作の記録を使います。

遅い操作を再現する手順

1. 問題のURL、端末種別、ブラウザ、確認日を記録する。
2. メニュー、検索、フォーム、カートなど主要な操作を選ぶ。
3. 読み込み途中と読み込み後の両方で操作し、遅いタイミングを探す。
4. DevToolsで操作を記録し、対象のインタラクションと周辺の処理を確認する。
5. 同じ端末条件・CPU制限・操作順序で複数回再現する。
6. 遅延を入力遅延、処理時間、描画までの待ちに分けて改善仮説を立てる。

高速な開発用パソコンだけでは、低速端末での問題を見落とすことがあります。複数条件の結果を混ぜた平均ではなく、条件を記録した比較を行ってください。

3つの遅延に分けて改善する

架空のローカル検証で、入力遅延80ms＋処理100ms＋描画まで60ms＝240msだったとします。見直し後に30ms＋50ms＋40ms＝120msになれば、その再現条件では操作応答が改善しています。これだけで公開サイトの75パーセンタイルが120msになったとは言えません。端末やページ状態、利用者の操作は異なるからです。

ボタンの反応を早く見せるだけで、本来の処理が失敗していないかも確認します。処理中の表示、重複送信の防止、成功・失敗の案内まで含めて利用の流れを検証してください。

公開後は性能と事業成果を分けて確認する

修正直後は、同じ条件のローカル再現で悪化や不具合がないかを確認します。その後、28日間のフィールドデータが更新される過程を追います。過去の利用が含まれる期間では、修正後のデータだけに即座に入れ替わるわけではありません。可能なら変更日と対象ページを残し、実利用計測も併用します。

優先順位を決める際、GA4のセッション数の仕様を踏まえた到達規模と、主要な操作の失敗・中断を別に把握します。INPが良好でも、説明不足や入力負担などの課題は残り得ます。成果はCVR改善の検証手順に沿って確認します。

Core Web Vitalsは検索にも関係しますが、良好な数値だけで上位表示や売上増加を保証しません。Google検索の公式説明の位置付けを踏まえ、内容・発見経路を含むSEOと合わせて改善してください。