First Input Delay（FID）

Philip Walton

第一印象が重要であることは誰もが知っています。新しい人と出会うときにも、ウェブでエクスペリエンスを構築するときにも、この点が重要になります。

ウェブでは、良い第一印象が、ユーザーが忠実なユーザーになるか、離れて二度と戻ってこないかの違いを生み出す可能性があります。問題は、どのような印象を与えればよいか、また、ユーザーにどのような印象を与えているかをどのように測定するかです。

ウェブでは、第一印象はさまざまな形で現れます。サイトのデザインや視覚的な魅力に対する第一印象もあれば、速度や応答性に対する第一印象もあります。

ウェブ API を使用してサイトのデザインに対するユーザーの好みを測定することは難しいですが、速度と応答性を測定することは難しくありません。

ユーザーがサイトの読み込み速度について最初に抱く印象は、First Contentful Paint（FCP）で測定できます。しかし、サイトが画面にピクセルを描画する速度は、ストーリーの一部にすぎません。ユーザーがこれらのピクセルを操作しようとしたときに、サイトがどれだけ応答性があるかも同様に重要です。

First Input Delay（FID）指標は、サイトのインタラクティブ性と応答性に対するユーザーの第一印象を測定するのに役立ちます。

FID とは

FID は、ユーザーが最初にページを操作したとき（リンクをクリックしたとき、ボタンをタップしたとき、カスタムの JavaScript ベースのコントロールを使用したとき）から、ブラウザがその操作に応答してイベント ハンドラの処理を実際に開始できるまでの時間を測定します。

FID スコアの目安はどのくらいですか？

優れたユーザー エクスペリエンスを提供するには、サイトで初回入力遅延を 100 ミリ秒以下に収めるようにします。ほとんどのユーザーに対してこの目標値を確実に達成するには、モバイル デバイスとデスクトップ デバイスに分割されたページ読み込みの 75 パーセンタイルを測定するのが適切なしきい値です。

FID の詳細

イベントに応答するコードを記述するデベロッパーは、イベントが発生するとすぐにコードが実行されると想定することがよくあります。しかし、ユーザーとして、私たちは皆、その逆の経験を頻繁にしています。スマートフォンでウェブページを読み込み、操作しようとしたのに、何も起こらずにイライラしたことがあるでしょう。

一般に、入力遅延（入力レイテンシ）は、ブラウザのメインスレッドが他の処理でビジー状態になっているため、ユーザーに応答できない（まだ応答していない）ことが原因で発生します。この問題が発生する一般的な理由の 1 つは、ブラウザがアプリによって読み込まれた大きな JavaScript ファイルの解析と実行に忙しいことです。ブラウザがその処理を行っている間は、読み込まれた JavaScript によって別の処理を行うよう指示される可能性があるため、イベント リスナーを実行できません。

一般的なウェブページのページ読み込みのタイムラインは次のとおりです。

上の可視化では、リソース（CSS ファイルと JS ファイルの可能性が高い）に対するネットワーク リクエストをいくつか行っているページが示されています。これらのリソースのダウンロードが完了すると、メインスレッドで処理されます。

これにより、メインスレッドが一時的にビジー状態になる期間が発生します。これは、ベージュ色のタスクブロックで示されます。

初回入力遅延が長くなるのは、通常、First Contentful Paint（FCP）とTime to Interactive（TTI）の間です。これは、ページがコンテンツの一部をレンダリングしたものの、まだ確実に操作可能になっていないためです。この仕組みを説明するために、タイムラインに FCP と TTI を追加しました。

FCP と TTI の間にはかなりの時間（3 つの長いタスクを含む）があります。ユーザーがその間にページを操作しようとすると（リンクをクリックするなど）、クリックが受信されてからメインスレッドが応答できるようになるまでに遅延が発生します。

ユーザーが最長のタスクの開始直後にページを操作しようとした場合を考えてみましょう。

入力はブラウザがタスクの実行中に行われるため、入力に応答するにはタスクが完了するまで待つ必要があります。待機時間は、このページのこのユーザーの FID 値です。

インタラクションにイベント リスナーがない場合はどうなりますか？

FID は、入力イベントが受信されてからメインスレッドが次にアイドル状態になるまでの差分を測定します。つまり、イベント リスナーが登録されていない場合でも FID が測定されます。これは、多くのユーザー操作ではイベント リスナーは必要ありませんが、実行するにはメインスレッドがアイドル状態である必要があるためです。

たとえば、次のすべての HTML 要素は、ユーザー操作に応答する前に、メインスレッドで進行中のタスクが完了するのを待つ必要があります。

• テキスト フィールド、チェックボックス、ラジオボタン（<input>、<textarea>）
• プルダウンを選択（<select>）
• リンク（<a>）

最初の入力のみを考慮するのはなぜですか？

入力の遅延はユーザー エクスペリエンスの低下につながる可能性がありますが、主に次の理由から、初回入力遅延を測定することをおすすめします。

• 初回入力遅延は、サイトの応答性に対するユーザーの第一印象となります。第一印象は、サイトの品質と信頼性に対する全体的な印象を形成するうえで非常に重要です。
• 現在ウェブで発生しているインタラクティビティに関する最大の問題は、ページの読み込み中に発生しています。そのため、ユーザーの最初のサイト インタラクションの改善に重点的に取り組むことが、ウェブ全体のインタラクティビティの改善に最も大きな影響を与えると考えています。
• サイトで初回入力遅延を改善するための推奨ソリューション（コード分割、事前に読み込む JavaScript の量を減らすなど）は、ページの読み込み後の入力遅延を改善するためのソリューションと同じとは限りません。これらの指標を分離することで、ウェブ デベロッパーに、より具体的なパフォーマンス ガイドラインを提供できるようになります。

初回入力としてカウントされるのはどのような場合ですか？

FID は、読み込み中のページの応答性を測定する指標です。そのため、クリック、タップ、キー押下などの個別の操作による入力イベントのみに焦点を当てています。

スクロールやズームなどの他のインタラクションは継続的なアクションであり、パフォーマンスの制約がまったく異なります（また、ブラウザは別のスレッドで実行することでレイテンシを隠すことができることがよくあります）。

言い換えると、FID は RAIL パフォーマンス モデルの R（応答性）に焦点を当てています。一方、スクロールとズームは A（アニメーション）に大きく関連しており、そのパフォーマンスの質は個別に評価する必要があります。

ユーザーがサイトをまったく利用しない場合はどうなりますか？

すべてのユーザーがサイトにアクセスするたびに操作を行うわけではありません。また、すべてのインタラクションが FID に関連するわけではありません（前のセクションで説明したとおり）。また、ユーザーの最初の操作が悪いタイミング（メインスレッドが長時間ビジー状態のとき）になることもあれば、良いタイミング（メインスレッドが完全にアイドル状態のとき）になることもあります。

つまり、FID 値がないユーザーもいれば、FID 値が低いユーザーも、FID 値が高いユーザーもいるということです。

FID のトラッキング、レポート、分析は、他の指標とはかなり異なるものになるでしょう。次のセクションでは、この方法について説明します。

入力遅延のみを考慮するのはなぜですか？

前述のように、FID はイベント処理の「遅延」のみを測定します。イベント処理の合計時間や、イベント ハンドラ実行後にブラウザが UI を更新するのにかかる時間は測定されません。

この時間はユーザーにとって重要であり、エクスペリエンスに影響しますが、この指標には含まれていません。これは、この時間を含めると、デベロッパーが実際にはエクスペリエンスを悪化させる回避策を追加するインセンティブになる可能性があるためです。つまり、イベントに関連付けられたタスクから分離するために、イベント ハンドラのロジックを非同期コールバック（setTimeout() または requestAnimationFrame() 経由）でラップする可能性があります。その結果、指標スコアは改善されますが、ユーザーが認識する応答速度は遅くなります。

ただし、FID はイベント レイテンシの「遅延」部分のみを測定しますが、イベント ライフサイクルのより多くの部分をトラッキングしたいデベロッパーは、イベント タイミング API を使用できます。詳しくは、カスタム指標に関するガイドをご覧ください。

FID の測定方法

FID は、実際のユーザーがページを操作する必要があるため、フィールドでのみ測定できる指標です。FID は次のツールで測定できます。

フィールド ツール

• Chrome ユーザー エクスペリエンス レポート
• PageSpeed Insights
• Search Console（Core Web Vitals レポート）
• web-vitals JavaScript ライブラリ

JavaScript で FID を測定する

JavaScript で FID を測定するには、イベント タイミング API を使用します。次の例は、first-input エントリをリッスンしてコンソールに記録する PerformanceObserver を作成する方法を示しています。

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

上記の例では、first-input エントリの遅延値は、エントリの startTime タイムスタンプと processingStart タイムスタンプの差分を計算することで測定されます。ほとんどの場合、これは FID 値になりますが、すべての first-input エントリが FID の測定に有効なわけではありません。

次のセクションでは、API がレポートする内容と指標の計算方法の違いについて説明します。

指標と API の違い

• この API は、バックグラウンド タブで読み込まれたページに対して first-input エントリをディスパッチしますが、FID の計算時にはこれらのページは無視されるべきです。
• API は、最初に入力が発生する前にページがバックグラウンドに移動した場合にも first-input エントリをディスパッチしますが、FID の計算時にはこれらのページも無視する必要があります（入力は、ページが常にフォアグラウンドにあった場合にのみ考慮されます）。
• ページがバック/フォワード キャッシュから復元された場合、API は first-input エントリをレポートしませんが、ユーザーはそれを個別のページ訪問として認識するため、このような場合でも FID は測定される必要があります。
• API は iframe 内で発生した入力をレポートしませんが、指標はページのユーザー エクスペリエンスの一部としてレポートします。これは CrUX と RUM の違いとして現れる可能性があります。FID を適切に測定するには、これらの点を考慮する必要があります。サブフレームは API を使用して、first-input エントリを親フレームに報告し、集計できます。

FID データの分析とレポート

FID 値にはばらつきが予想されるため、FID をレポートする際は、値の分布を確認し、上位のパーセンタイルに注目することが重要です。

すべてのウェブに関する主な指標のしきい値のパーセンタイルの選択は 75 パーセンタイルですが、特に FID については、95 ～ 99 パーセンタイルを確認することを強くおすすめします。これは、ユーザーがサイトで特に悪い初回エクスペリエンスを経験していることを示すためです。また、最も改善が必要な分野も表示されます。

これは、レポートをデバイス カテゴリやタイプ別に分割した場合でも当てはまります。たとえば、パソコンとモバイルで別々のレポートを実行する場合、パソコンで最も重要な FID 値はパソコン ユーザーの 95 ～ 99 パーセンタイル、モバイルで最も重要な FID 値はモバイル ユーザーの 95 ～ 99 パーセンタイルになります。

FID を改善する方法

FID を最適化するための完全なガイドでは、この指標を改善する手法について説明しています。

変更履歴

指標の測定に使用される API や、指標の定義自体にバグが見つかることがあります。そのため、変更が必要になることがあり、これらの変更は内部レポートやダッシュボードで改善または回帰として表示されることがあります。

この管理を容易にするため、これらの指標の実装または定義に対する変更はすべて、この変更ログに表示されます。

これらの指標に関するフィードバックがある場合は、web-vitals-feedback Google グループで提供できます。