Web Vitalsの新指標「INP」完全対策!JavaScript長時間タスクを撲滅しスコアを改善する最適化技術

2026年10月5日月曜日

t f B! P L

📖 推定読了時間:約6分

ウェブサイトを閲覧していて、「ボタンをクリックしたのに一瞬固まって反応しない」「アコーディオンメニューを開こうとタップしたのに、ワンテンポ遅れてガクッと開いた」というストレスを感じたことはありませんか?

GoogleのCore Web Vitalsにおいて、従来の「FID(First Input Delay)」に代わり完全本採用となった新指標がINP(Interaction to Next Paint)です。FIDが「サイト訪問後の最初の1回の入力遅延」しか見ていなかったのに対し、INPは読者がページに滞在している間の「すべてのクリック・タップ・キーボード入力」に対する描画応答性を厳しく監視します。

ユーザー体験を底上げし、SEOでの検索順位ペナルティを回避するためには、INPの仕組みを正しく理解し、JavaScriptの長時間ブロッキングタスク(Long Tasks)を根本から解消するアプローチが欠かせません。

この記事のポイント

  • FIDからINPへの移行で「初回だけでなくページ全滞在期間のインタラクション」が評価対象になった
  • INPスコアの目安は200ms以下であり、悪化の主因は50msを超えるJavaScriptのLong Tasks
  • 新Web標準API「scheduler.yield()」と「Long Animation Frames(LoAF)API」による最新の診断・タスク分割手法

INPとは何か?従来のFIDとの決定的な違い

Webサイトのパフォーマンスといえば、かつてはページ全体の読み込み速度(LCPなど)ばかりが注目されていました。しかし、現代のリッチなWebアプリケーションでは、画面が表示された後の「操作の軽快さ」こそがユーザー満足度を大きく左右します。基礎から設計思想を学ぶなら、WebフロントエンドUI/UX・Webアクセシビリティ実践入門書などで画面応答の重要性を体系的に把握しておくのが効果的です。

INP(Interaction to Next Paint)は、ユーザーが行ったインタラクション(クリック、タップ、キーストローク)が発生してから、ブラウザがその結果を画面に次のフレームとして実際にピクセルを描画するまでの総経過時間をミリ秒単位で計測します。

比較項目 従来の指標:FID 新指標:INP
計測タイミング 初回インタラクションのみ ページ滞在中のすべてのインタラクション
計測区間 入力からJS実行開始までの待ち時間のみ 入力遅延 + JS処理時間 + 描画遅延の総合計
合格基準(Good) 100ms以下 200ms以下(最悪値に近い上位パーセンタイル)

FIDでは「イベントリスナーが動き出すまでの待ち時間」しか測っていなかったため、ハンドラー内部で重たいJavaScript計算を行い画面が数秒間固まっても「スコア上は合格」というすり抜けが可能でした。しかしINPでは、処理完了後のレンダリング(描画)完了までが厳格に対象となるため、誤魔化しが一切効きません。

なぜINPが悪化するのか?「Long Task」と3つの遅延フェーズ

INPの合計時間は、大きく分けて次の3つのフェーズで構成されています。

  • ⚠️1. 入力遅延(Input Delay):クリック時に別の重いバックグラウンド処理がメインスレッドを占有しており、イベントハンドラーの起動自体が待たされる時間。
  • ⚠️2. 処理時間(Processing Duration):登録されたJavaScriptのコールバック関数やフレームワークの再レンダリング処理が完了するまでの実行時間。
  • ⚠️3. 描画遅延(Presentation Delay):DOMツリー更新後に、ブラウザがスタイル再計算(Recalculate Style)、レイアウト(Reflow)、ペイント、コンポジットを行って画面に反映させるまでの時間。

特に問題となるのが、実行に50ms以上を要する「Long Tasks(長時間タスク)」です。ブラウザのメインスレッドはシングルスレッドで動作しているため、巨大なスクリプトが居座るとユーザーのタップやスクロールの処理がキューでせき止められ、画面がフリーズしてしまいます。

開発環境でミリ秒単位の描画遅延やフレームドロップ(Stutter)を肉眼でデバッグする際には、高リフレッシュレート対応のコーディング・クリエイター向け4K 144Hz外部モニターを活用すると、UIのカクつきや入力ラグの有無を極めて直感的に見極められます。

実践対策:scheduler.yield()によるタスク分割と最新チューニング

では、重たいJavaScript処理を抱えるWebアプリで、どのようにしてINPを200ms未満に抑え込めばよいのでしょうか?代表的な解決策がタスクの細分化(Yielding)です。

従来のWeb開発では、`setTimeout(..., 0)` を使って無理やりメインスレッドを解放するハックが多用されていましたが、タスクキューの最後尾に回されてしまい優先順位制御が困難でした。そこで新たに標準化されたのが `scheduler.yield()` APIです。

💡 scheduler.yield() の強み:メインスレッドの処理権限を一時的にブラウザ描画エンジンに譲り、入力処理やペイントを即座に割り込ませた後、元の処理を最優先で再開できる!

具体的な実装イメージは以下の通りです。大量のデータ配列をループ処理する際、定期的に制御を譲渡します。

async function processHugeList(items) {
  for (let i = 0; i < items.length; i++) {
    // 重いデータ加工ロジック
    processItem(items[i]);

    // 50件処理ごとにメインスレッドを描画エンジンへ一時譲渡
    if (i % 50 === 0 && 'scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    }
  }
}

さらに、Chrome 123以降で正式サポートされたLong Animation Frames(LoAF)APIを導入することで、現場の本番環境(Real User Monitoring: RUM)において「どのスクリプトファイルの何行目が何ミリ秒の描画遅延を引き起こしたか」を正確にログ送信・分析できるようになりました。

💬

「サードパーティ製の計測タグやチャットウィジェットが裏で重たいポーリング処理を行い、INPを一気に悪化させていたケースが多発しています。まずはDevToolsのPerformanceパネルで犯人スクリプトを特定するのが最短の近道です。」

まとめ

INP(Interaction to Next Paint)は、単なるGoogleの検索ランキング要因にとどまらず、ユーザーがWebサイトを「サクサク動いて快適だ」と感じるための最も本質的な指標です。

まずはChromeの拡張機能「Web Vitals」やPageSpeed Insightsを用いて、ご自身のサイトのINPが200ms以内に収まっているかを今すぐチェックしてみましょう。もし「改善が必要」と判定された場合は、巨大なJavaScriptの実行タイミングを見直し、`scheduler.yield()` によるタスク分割や不要な再レンダリングの抑制を少しずつ進めてみてください。

このブログを検索

このサイトはアフィリエイト広告(Amazonアソシエイト含む)を掲載しています。
Amazonのアソシエイトとして、「色即是空」な「空即是色」blogは適格販売により収入を得ています。