First Input Delay (FID)

First Input Delay（FID）の定義

First Input Delay（FID） は、ユーザーがウェブページと最初にインタラクションしてから、ブラウザーのメインスレッドがそのインタラクションイベントの処理を開始するまでに経過する時間を測定する、ユーザー中心のウェブパフォーマンス指標です。ユーザーがリンクをクリックしたりボタンをタップしたり、キーを押したりした際、即座のフィードバックを期待します。FIDは、ブラウザーが他のタスクを実行中でユーザー入力に即時応答できない場合に発生する応答性のギャップを捉えます。 この指標は、JavaScriptの解析・実行中などクリティカルなページ読み込みフェーズでのユーザーの実体験を反映するため、特に重要です。FIDはミリ秒単位で測定され、インタラクションライフサイクルのうち入力遅延の部分のみを表し、インタラクション完了や視覚的フィードバックに要する全体の時間は含みません。FIDの理解は、ユーザーを苛立たせずに惹きつける、応答性の高いウェブ体験を実現したい開発者やパフォーマンスエンジニアにとって不可欠です。

FIDの歴史的背景と進化

First Input Delayは2020年にCore Web Vital指標として登場し、ウェブ上の実際のインタラクティビティ測定のニーズ拡大に応えるためGoogleによって導入されました。FID以前は、Time to Interactive（TTI）のようなラボベースの指標に頼っていましたが、ページインタラクション中の実際のユーザー体験は捉えられていませんでした。この指標は、サイトの応答性に対するユーザーの第一印象に着目し、パフォーマンス計測の重要なギャップを埋める目的で設計されました。数年間、FIDはGoogleのCore Web Vitalsフレームワーク内で主要な応答性指標として機能し、検索順位やパフォーマンス最適化実践の普及に影響を与えました。しかし、FIDは最初のインタラクションのみを測定し、イベント処理ライフサイクル全体を考慮していないという限界が、調査や実データから明らかになりました。HTTP Archive 2024 Performance Reportによると、デスクトップウェブサイトの約68％、モバイルウェブサイトの約51％が良好なFIDスコアを達成しており、ウェブパフォーマンス最適化の大きな進歩を示しています。FID最適化の普及はウェブ全体の応答性向上に貢献しましたが、指標の限界を受けてGoogleはより包括的な後継指標の開発に至りました。

技術的解説：FIDの仕組み

FIDは、2つの重要なタイムスタンプ間の差分を測定します。すなわち、ブラウザーが入力イベントを受信した瞬間と、メインスレッドがそのイベント処理を開始できるようになった瞬間です。ユーザーがウェブページとインタラクションすると、ブラウザーはそのイベントをキューに追加し、メインスレッドが現在のタスクを終えるのを待ってから関連するイベントハンドラーを実行します。メインスレッドはHTMLの解析、JavaScriptの実行、スタイルの再計算、レイアウト描画など重要な作業を単一スレッドで処理します。もしメインスレッドが長時間実行されるJavaScriptタスクで占有されていると、入力イベントはキューで待つことになり、これがFIDで測定される遅延です。この測定はシンプルながら強力です。たとえば、ユーザーが1000ms時点でボタンをクリックし、メインスレッドが1050msで空いた場合、FID値は50ミリ秒となります。この遅延自体はユーザーからは直接見えませんが、体感パフォーマンスに直結し、クリックが即座に反応しないことをユーザーは感じ取ります。FIDは、イベントハンドラーの処理や視覚的表示に要する時間は含まず、待ち時間のみを対象としています。これは、処理時間まで含めてしまうと非同期処理などで逆にユーザー体験が悪化する可能性があるため、意図的な設計です。

比較表：FIDと関連パフォーマンス指標

FIDの重要性：ビジネスとユーザー体験への影響

First Input Delayは、ウェブサイトの応答性が高いか遅いかを決定するため、ユーザー満足度やコンバージョン率に直接影響します。 研究によると、100～300ミリ秒の遅延でもユーザーの苛立ちや離脱率増加につながることが分かっています。ユーザーがボタンをクリックしてフィードバックが遅いと、複数回クリックしてしまい、重複送信やナビゲーションエラーを引き起こすことがあります。高いFID値は、特にモバイル端末でバウンス率増加・エンゲージメント低下に相関します。ビジネス面では、FIDパフォーマンスが悪いとGoogleの検索順位に悪影響を与える可能性があるため、SEO対策にも直結します。良好なFIDスコアはSEO可視性の向上、検索結果からのクリック率増加、ユーザーリテンション向上につながります。また、FIDは診断ツールとしても機能し、メインスレッドをブロックしているJavaScriptの存在など、具体的な最適化ポイントを示してくれます。ECサイトやSaaS、コンテンツプラットフォームでは、FID最適化がそのままコンバージョンや生涯価値の向上につながります。

プラットフォーム別の考慮点：ブラウザー・デバイスごとのFID

FIDの挙動は、デバイスやネットワーク状況によって大きく異なります。そのため、デバイス種別や通信速度ごとにパフォーマンスを分析することが重要です。モバイル端末は、デスクトップと比べて処理能力やメモリが低いため、より高いFID値になりやすくなっています。同じJavaScriptでも、デスクトップでは問題なくても、モバイルの中・低価格帯端末ではFIDに大きな問題を生じさせる場合があります。また、ネットワークが遅いとJavaScriptのダウンロードが長引き、その間メインスレッドも解析や実行で占有されるため、間接的にFIDが悪化します。FIDの計測自体は標準化されたAPIに依存するためブラウザー間で違いは小さいですが、各ブラウザーでJavaScriptの実行方式に差があるため、実際のFIDには違いが現れます。ChromeやEdgeなどのChromium系ブラウザーは似た傾向を持ちますが、FirefoxやSafariでは異なるパターンが出ることもあります。FIDの計測に使われるEvent Timing APIはほぼすべてのモダンブラウザーでサポートされていますが、クロスオリジンiframeからのFID計測は制限される場合があります。開発者は、デバイスカテゴリやブラウザータイプごとにFIDデータを分析し、最適化ポイントを特定しましょう。

First Input Delayが高くなる主な要因

• 長時間実行されるJavaScriptタスクがメインスレッドを長くブロックし、ブラウザーがユーザー入力に応答できなくなる
• 大きく最適化されていないJavaScriptバンドルにより、解析やコンパイルに時間がかかる
• レンダーブロッキングのCSSやスクリプトが、ユーザーインタラクションの前に処理される必要があるため、ページの応答性を遅らせる
• 広告・解析・SNSウィジェットなどのサードパーティスクリプトがメインスレッドリソースを消費する
• 複雑なロジックやパフォーマンスの悪いイベントハンドラーにより処理時間が増大
• 深くネストした複雑なDOM構造が、イベントのデリゲーションやレイアウト計算時の負荷を高める
• 過剰なイベントリスナーが多くの要素や高頻度イベント（スクロール・リサイズなど）に設定されている
• 同期的な処理（同期XMLHttpRequestやブロッキングなファイル操作など）がメインスレッドをブロックする
• モバイル端末への最適化不足で、低スペック端末でパフォーマンスが低下する
• 不要なコードや非効率アルゴリズムを含む未最適化のサードパーティライブラリ

最適化戦略とベストプラクティス

First Input Delayを削減するには、JavaScript最適化・タスク管理・リソース配信の多面的なアプローチが必要です。コード分割は特に有効な戦略の一つで、JavaScriptを小さなチャンクに分割し、必要なものだけを逐次読み込むことで、初期インタラクティビティに必要なクリティカルパスのJavaScriptが素早く利用可能になります。長いタスクを50ミリ秒未満の小さなチャンクに分割することで、ブラウザーはタスクの合間にユーザー入力に応答でき、体感応答性が大きく向上します。これはsetTimeoutやrequestIdleCallback、async/awaitなどで実現できます。非クリティカルなJavaScriptの遅延読み込み（defer属性や動的インポート）で、初期インタラクティビティに不要なスクリプトによるメインスレッドのブロックを回避します。ミニファイと圧縮によりファイルサイズを削減し、JavaScriptのダウンロード・解析を高速化します。Brotliのような最新圧縮アルゴリズムはgzipより15～20％小さくできます。Web Workerによる重い処理のバックグラウンド化で、メインスレッドをユーザー入力処理に集中させます。遅延読み込みで画像や非クリティカルリソースの初期ロード負荷を減らします。イベントハンドラーの最適化（デバウンスやスロットリング）は高頻度イベントでの過剰な関数呼び出しを防ぎます。未使用JavaScriptの削除（ツリーシェイキングやデッドコード除去）も重要です。パッシブイベントリスナーをスクロールやタッチイベントに指定すれば、ブラウザーはリスナー完了を待たずにスムーズなスクロールを実現できます。

FIDからINPへの移行：進化の背景

2024年3月、GoogleはCore Web Vitalsの応答性指標をFirst Input DelayからInteraction to Next Paint（INP）へ正式に移行しました。 FIDが最初のインタラクションの入力遅延のみを測定していたのに対し、INPはページのライフタイム全体のあらゆるユーザーインタラクションに対して、入力遅延・処理遅延・表示遅延の3フェーズを包括的に測定します。 これにより、FIDの「最初の遅延しか測れない」という限界を克服し、ユーザーが本当に気にする「インタラクション全体の応答性」を正確に評価できるようになりました。この移行は、FIDだけではユーザー体験の全貌を捉えきれないという業界の認識を反映しています。例えば、FIDが良好でも、イベントハンドラーの処理やレイアウト再計算が遅ければ、全体の応答性は悪化します。開発者にとって、この移行は、メインスレッドのブロック削減に加え、イベントハンドラーの効率化や描画パイプラインの最適化にも取り組む必要があることを意味します。ただし、FID最適化の基本原則はINPにも有効で、メインスレッドブロック削減は今後も重要なパフォーマンス施策です。FIDを最適化してきた多くのサイトは、INPスコアも同時に向上していますが、さらなる処理・表示遅延の最適化も求められます。

FIDの計測：ツール・API・実装

First Input Delayは、実ユーザーを通じたフィールドデータでのみ測定できます。FID計測・監視にはいくつかのツールとアプローチがあります。GoogleのPageSpeed InsightsはChrome User Experience Report（CrUX）から取得した実際のFIDデータを提供します。Search Console Core Web VitalsレポートではデバイスやURLごとのFIDパフォーマンスを確認できます。web-vitals JavaScriptライブラリ（Google公式）は、FIDをプログラム的に計測し分析基盤へ送信可能です。リアルユーザーモニタリング（RUM）プラットフォーム（Datadog、New Relicなど）では実ユーザーからのFIDデータの詳細分析やアラートが可能です。JavaScriptで直接FIDを計測したい場合は、Event Timing APIでfirst-inputエントリをPerformanceObserver経由で取得し、startTime（入力発生時）とprocessingStart（処理開始時）の差分でFIDを算出できます。ただし、FIDには注意点もあり、バックグラウンドタブでのページ読み込みや、最初の入力前にバックグラウンド化されたページ、iframeからの入力（基本的には指標に含めるべき）には特別な扱いが必要です。**Total Blocking Time（TBT）**はラボ環境でFIDと高い相関を持つ代理指標であり、開発・テスト段階で最適化ポイントの特定に有効です。

今後の展望：FIDの遺産とパフォーマンス指標の進化

First Input Delayの遺産はINPに置き換えられても色褪せません。 FIDはウェブ開発コミュニティのパフォーマンス計測・最適化の意識を根本から変え、合成ラボ指標だけでなく実ユーザー体験の測定という潮流を作りました。同指標がページロードからインタラクティビティ到達までの「見える化」へと焦点を当てたことで、コード分割・遅延読み込み・JavaScript最適化の広範な普及を後押しし、全世界のWebサイトの応答性向上に寄与しました。INPへの移行は、単一のインタラクションから全体の応答性プロファイルへと進化するパフォーマンス計測の必然的な一歩です。 今後ウェブアプリがよりインタラクティブかつ複雑になるにつれ、指標もアニメーションの滑らかさや、サードパーティスクリプトがページ応答性へ与える影響など、より細かなユーザー体験の側面を捉えるよう進化していくでしょう。FID最適化に取り組んできた開発者は、INPでも優位に立つことができます。 なぜなら、メインスレッドブロック削減やJavaScript実行の最適化は良好なINPスコア獲得の基礎だからです。FIDやINPのようなユーザー中心指標にウェブパフォーマンスコミュニティが注目し続けてきたことは、特に低速端末や低速回線のユーザーを含め、すべてのユーザーに恩恵をもたらす「パフォーマンスファースト開発文化」の定着につながっています。