INPという新指標：Core Web Vitalsで「操作の速さ」が問われる時代へ

FIDが引退し、INPが主役になった

2024年3月、Core Web Vitalsの応答性を測る指標が、FID（First Input Delay）からINP（Interaction to Next Paint）へと正式に置き換わった。この変更を「用語が変わっただけ」と軽く見ていると足元をすくわれる。FIDは「最初のクリックにどれだけ待たされたか」という、ページ読み込み直後の一瞬だけを見ていた。対してINPは、ページ滞在中に起きたすべての操作を対象に、応答の遅さを評価する。つまり、測る範囲が桁違いに広がったのだ。

INPは「反応が返ってくるまで」を測る

INPが測るのは、ユーザーがクリックやタップ、キー入力をしてから、その結果として画面が次に描画されるまでの時間だ。ボタンを押したのに一瞬固まる、入力した文字がワンテンポ遅れて表示される——こうした「もっさり感」がそのままスコアに表れる。良好とされるのは200ミリ秒以下。500ミリ秒を超えると「不良」と判定される。見た目が綺麗でも、操作するたびに引っかかるサイトは、この指標で容赦なく減点される。

犯人はたいてい「長いタスク」

INPが悪化する主因は、メインスレッドを長時間占有するJavaScriptの処理、いわゆる「ロングタスク」だ。ユーザーがボタンを押しても、ブラウザが重い処理にかかりきりだと、その処理が終わるまで反応を返せない。私たちがまず調べるのは、クリックをきっかけに走る処理の中に、重い計算や大量のDOM更新がまとめて詰め込まれていないかだ。

タスクを分割し、応答を先に返す

対策の基本は、重い処理を小さく分割することだ。一度に全部やろうとせず、処理を区切ってブラウザに制御を返す隙間を作る。まず画面の反応（ボタンの見た目の変化など）を先に描画し、時間のかかる処理は後回しにする。ユーザーは「押した手応え」さえあれば、多少の待ちは許容してくれる。無反応の数百ミリ秒こそが、最もストレスになる。

実測（RUM）でしか見えない現実がある

ここで強調したいのは、INPは実際のユーザー環境で計測してこそ意味がある、ということだ。開発者の高性能なマシンでは何の問題もなくても、数年前のスマートフォンを使う実ユーザーの手元では処理が詰まっている。こうした実態は、Chromeユーザーエクスペリエンスレポートや、RUM（Real User Monitoring）ツールで初めて見えてくる。ラボ環境の合格に安心せず、フィールドデータのINPを定点観測することが欠かせない。

「速く見える」から「速く反応する」へ

これまでのパフォーマンス改善は、いかに速く表示するかに重心があった。INPの登場は、その先の「操作にどれだけ機敏に応えるか」までが品質として問われる時代になったことを意味する。表示の速さとUXの快適さは別物だ。私たちは、この新しい物差しを、サイトの使い心地を根本から見直す良い機会だと捉えている。