このページは Cloud Translation API によって翻訳されました。

First Input Delay（FID）

Philip Walton

対応ブラウザ

ソース

良い第一印象を与えることは非常に重要です。これは、新しい人と出会うときに重要であり、ウェブでエクスペリエンスを構築する際にも重要です。

ウェブでは、良い第一印象が、ユーザーがリピーターになるか、離れて二度と戻ってこないかの違いを生む可能性があります。問題は、良い印象を与える要素と、ユーザーにどのような印象を与えているかを測定する方法です。

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

ウェブ API を使用して、ユーザーがサイトのデザインをどの程度気に入っているかを測定することは難しいですが、速度と応答性を測定することは可能です。

サイトの読み込み速度に関するユーザーの第一印象は、First Contentful Paint（FCP）で測定できます。ただし、サイトが画面にピクセルを描画する速度は、全体像の一部にすぎません。ユーザーがピクセルを操作しようとしたときに、サイトがどれだけ迅速に応答するかも同様に重要です。

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

FID とは

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

適切な FID スコアとは

優れたユーザーエクスペリエンスを提供するには、サイトで最初の入力遅延を 100 ミリ秒未満に収めるようにします。ほとんどのユーザーがこの目標を達成できるように、モバイルとパソコンのデバイスに分けてページ読み込みの75 パーセンタイルを測定することをおすすめします。

良好な FID 値は 2.5 秒未満、良好でない値は 4.0 秒を超え、その間の値は改善が必要です

FID の詳細

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

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

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

ページ読み込みトレースの例

上の可視化は、リソース（ほとんどの場合、CSS ファイルと JS ファイル）に対して複数のネットワークリクエストを実行しているページを示しています。これらのリソースのダウンロードが完了すると、メインスレッドで処理されます。

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

初回入力遅延が長くなるのは通常、First Contentful Paint（FCP）とTime to Interactive（TTI）の間です。これは、ページのコンテンツの一部はレンダリングされているものの、まだ信頼性の高いインタラクティブな状態ではないためです。これがどのように発生するかを示すために、FCP と TTI がタイムラインに追加されています。

FCP と TTI を含むページ読み込みトレースの例

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

ユーザーが最も長いタスクの開始近くでページを操作しようとするとどうなるかを考えてみましょう。

FCP、TTI、FID を含むページ読み込みトレースの例

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

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

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

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

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

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

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

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

最初の入力としてカウントされるもの

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

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

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

ユーザーがサイトを操作しなかった場合はどうなりますか？

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

つまり、一部のユーザーには FID 値が設定されず、一部のユーザーには FID 値が低く、一部のユーザーには FID 値が高い可能性があります。

FID のトラッキング、レポート、分析の方法は、慣れ親しんだ他の指標とは大きく異なる可能性があります。次のセクションでは、この最適な方法について説明します。

入力遅延のみを考慮する理由

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

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

ただし、FID はイベントレイテンシの「遅延」部分のみを測定しますが、イベントライフサイクルの詳細をトラッキングしたい場合は、Event Timing API を使用できます。詳しくは、カスタム指標のガイドをご覧ください。

FID を測定する方法

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

フィールドツール

JavaScript で FID を測定する

JavaScript で FID を測定するには、Event Timing 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 エントリをコンソールにログに記録し、その遅延を計算する方法を示しています。ただし、JavaScript で FID を測定するのは複雑です。詳しくは以下をご覧ください。

上記の例では、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 に関するレポートでは値の分布を確認し、上位のパーセンタイルを確認することが重要です。

すべての Core Web Vitals のしきい値のパーセンタイルは 75 パーセンタイルですが、特に FID については、95 ～ 99 パーセンタイルを重視することを強くおすすめします。これは、ユーザーがサイトに対して抱く最初の印象が特に悪い場合に該当します。最も改善が必要な分野が表示されます。

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

FID を改善する方法

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

変更履歴

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

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

これらの指標に関するフィードバックがある場合は、web-vitals-feedback Google グループで送信してください。