First Input Delay（FID）

Philip Walton

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

ウェブでは、第一印象が優れていれば、ロイヤル ユーザーになるか、いったん離れて二度と戻ってこないかの分かれ目となります。問題は、良い印象を与える要因と、ユーザーに与える可能性のある印象をどのように測定するかということです。

ウェブでは、第一印象はさまざまな形態を取ります。サイトのデザインや視覚的な魅力、そしてそのスピードと応答性の第一印象は第一印象です。

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

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

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

FID とは

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

適切な FID スコアとは

優れたユーザー エクスペリエンスを提供するには、First Input Delay を 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>）

最初のインプットのみを考慮するのはなぜですか。

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

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

最初の入力と見なされるものは何ですか？

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

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

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

ユーザーが一度もサイトを訪れたことがないとしたらどうなるでしょうか。

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

つまり、FID 値を持たないユーザー、FID 値が低いユーザーがいる、FID 値が高いユーザーがいる可能性があります。

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

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

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

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

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

FID を測定する方法

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

フィールドツール

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

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 エントリの遅延値は、エントリの 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 グループで送信してください。