FID（First Input Delay）の意味と測定！INPへの移行対応と計測の基本を解説
FIDの概要と重要ポイント（現在はINPが指標）
FID（First Input Delay）は、ページ読み込み後の最初のユーザー操作に対して、ブラウザがイベントハンドラの実行を開始するまでの遅延を示す指標です。実ユーザーデータでのみ算出され、ラボ計測はできません。現在のCore Web VitalsはINPへ置き換わっているため、改善は INPへの移行対応 を前提に進めるのが実務的です。
FIDの定義（意味と評価基準）
FIDは「クリック・タップ・キー押下」など初回インタラクション時の待ち時間を測定します。原因の多くはメインスレッドを塞ぐ同期JavaScriptや長いタスクです。最初の1回だけを対象にするため、継続的な応答性はINPの方が適切に反映されます。
| 判定 | しきい値 | 解釈 |
|---|---|---|
| 良好 | ≤ 100ms | 初回操作に素早く反応 |
| 改善が必要 | 100〜300ms | タスク分割や読込最適化を検討 |
| 不良 | > 300ms | メインスレッド占有を解消すべき |
まず押さえる3点
- INP中心の評価へ移行しつつ、初回応答の遅延も同時に短縮
- メインスレッドの長いタスクを分割（<50ms目安）
- サードパーティと同期JSを削減し、遅延実行・
deferを徹底
実務での論点（原因と改善アプローチ）
FID悪化は主に「初期JSの重量」「長いタスク」「同期的なレンダリング阻害」で起きます。バンドルを分割し、必要な処理だけを初期化。残りはユーザー操作後やアイドル時間に実行します。イベントリスナーは軽量化し、CSS/フォントのブロッキングも最小化します。判断に迷う場面では メインスレッドの占有時間削減 を指標化して優先順位を付けます。
- JS最適化：コード分割・ツリーシェイク・
defer/async・遅延初期化 - 長いタスク：Web Workerや
requestIdleCallbackでオフロード - サードパーティ：必要最小限のみ読込、タグは同意後に遅延
- 入力即応：スケルトンUIと早期イベントバインドで操作を受け付ける
- ネットワーク：HTTP/2以降・キャッシュ戦略で初期負荷を軽減
比較・使い分け表（FIDと関連指標）
| 指標 | 意味 | 用途/改善の主眼 |
|---|---|---|
| FID | 初回入力に対する応答遅延 | 初期JS削減・長いタスク解消・イベント直後の負荷抑制 |
| INP | ページ全体の総合的な応答性 | 全操作の遅延分布を改善。ハンドラ軽量化・メインスレッド負荷最小化 |
| TBT | 合計ブロッキング時間（ラボ） | FID/INP改善のラボ代替。長いタスクの可視化に有効 |
運用上の注意（計測・SEO・検証）
FIDはフィールドデータのみの評価で、ラボではTBT・INP相当値で代替評価します。検索評価はINPが中心のため、ダッシュボードとアラートはINPへ移行します。改善ではテンプレート単位で初期JS量と長いタスクを継続把握し、第三者タグは同意後ロードや遅延を徹底します。
よくある質問（FAQ）
いまはFIDとINPどちらを見れば良いですか？
評価指標はINPが中心です。既存のFID監視は残しても、改善・レポートはINPへ統一するのが現実的です。
ラボでFIDは確認できますか？代替は？
FIDはラボ不可です。代わりにTBTやINPのラボ推定を用いて、長いタスクやメインスレッド占有を特定します。
どの改善が効果的ですか？優先順位は？
初期JSの削減と長いタスク分割が最優先です。次にサードパーティ遅延、イベント直後の重処理抑制、フォント/CSSのブロッキング削減を行います。
数値目標はどう設定すべきですか？
FIDは≤100msを目安にしつつ、INPは≤200ms（良好）をゴールに設計します。テンプレート別に閾値と改善チケットを管理してください。
FIDのまとめ
FIDは初回応答性を示す旧指標で、現在はINPの時代です。とはいえ初期JSの軽量化や長いタスク解消は、FIDとINPの双方を改善します。INP中心にモニタリングを切り替え、メインスレッドの占有削減・サードパーティ最適化・段階的初期化を標準化すれば、体感の速さと検索評価を安定して高められます。
