INP を 200ms 未満にする実装の全手法

INP（Interaction to Next Paint）は、ユーザーがボタンをタップしたり文字を入力したりした瞬間から、その操作の結果が画面に反映されるまでの時間を測る指標です。Core Web Vitals の 3 指標のうち「操作への応答性」を担当します。

合格基準は明確で、200 ミリ秒以内なら「良好」、200〜500ms で「要改善」、500ms 超で「不良」です。判定は実ユーザーの体験データ（CrUX）の 75 パーセンタイルで行われるため、回線が遅い人や古い端末の人を含めて 200ms 以内に収める必要があります。

2024 年 3 月、INP は旧指標 FID（First Input Delay）と置き換わりました。FID は最初の 1 操作の「待ち時間」だけを見ていましたが、INP はページ滞在中のほぼ全操作を見て、応答が完了し画面が更新されるまでを測ります。FID より格段に厳しい指標です。

ブラウザの JavaScript は「メインスレッド」という 1 本の作業列で動きます。ここで 50 ミリ秒を超える処理が走っている間、ブラウザはユーザーの操作に応答できません。これが「ロングタスク」で、INP 悪化の正体です。

Web Almanac 2025 によると、INP 自体は改善傾向にある一方、TBT（Total Blocking Time＝メインスレッドがふさがる総量）は前年比 58% 増。サイトに積まれる JavaScript の総量と実行コストが増え続けていることを示しています。

タップしても反応しない、入力した文字がワンテンポ遅れて表示される — こうした「もたつき」は、たいてい裏でロングタスクが走っているサインです。解決の方向はひとつ。長い処理を細かく区切り、その合間にブラウザへ制御を返すことです。

INP 改善の中核は、web.dev 公式が示す「ロングタスクの分割」と「メインスレッドへの yield（明け渡し）」です。処理の途中でブラウザに「ここで一旦どうぞ」と制御を返すと、その瞬間に溜まっていたユーザー操作を先に処理できます。

制御を返す新しい標準が scheduler.yield() です。ただし 2026 年 5 月時点で Safari は未対応のため、使える環境では scheduler.yield()、使えない環境では setTimeout によるフォールバックを併用するのが定石です。タスクに優先度を付けて予約する scheduler.postTask() も関連 API として使えます。

実装の勘所は、ループや一括処理の中で「重要な画面更新を先に済ませ、残りの作業の前に yield する」こと。イベントハンドラの中に重い処理を全部書かず、ユーザーに見える部分の更新を優先させます。

分割しても重すぎる処理は、そもそもメインスレッドから外すのが正解です。それを担うのが Web Worker。画面描画とは別のスレッドで JavaScript を動かせる仕組みです。

大量データの並べ替え、検索フィルタの集計、画像の前処理といった「画面を直接いじらない計算」は Web Worker に任せられます。計算が終わったら結果だけをメインスレッドに渡して描画する。こうすればメインスレッドは常に操作へ応答できる状態を保てます。

中小企業サイトでここまで必要になる場面は多くありませんが、商品の絞り込み一覧や予約カレンダーなど「操作のたびに裏で計算が走る」画面では効果が大きい手法です。

「INP を直すと何が変わるのか」は、web.dev の公式ケーススタディが具体的に示しています。いずれも前述の手法を実際に適用した結果です。

EC サイトの Trendyol は scheduler.yield() の導入で商品一覧の INP を 50% 削減。不動産サイトの QuintoAndar は INP を 80% 削減し、コンバージョンが前年比 36% 増と報告されています。ニュースサイトの Economic Times は INP を約 4 分の 1 にし、直帰率 50% 減・ページビュー 43% 増という結果が出ています。

誠実にお伝えすると、「INP 改善 → 売上 X%」は厳密には因果ではなく相関です。それでも、操作の快適さがビジネス指標と一緒に動く事例が公式に積み重なっていることは、対策の価値を裏付けています。