FIDとは？初回入力遅延（FID）

良い第一印象を与えることがどれほど重要かは、誰もが知っています。これは新しい人と出会うときだけでなく、オンラインでの体験を形作る際にも重要です。

オンラインでは、良い第一印象が、ロイヤルユーザーになるか、二度と戻ってこないかの分かれ目となることがあります。問題は、良い体験とは何か、そしてその印象をどのように測定するかということです。

インターネットでは、第一印象は様々な形で表れます。私たちはサイトのデザインや見た目の魅力だけでなく、速度や応答性についても第一印象を左右します。

Web API を通じてユーザーが Web サイトのデザインをどれだけ気に入っているかを測定することは困難ですが、Web API を使用すると Web サイトの速度と応答性を簡単に測定できます。

ウェブサイトの読み込み速度に対するユーザーの第一印象は、ファーストコンテンツペイント (FCP)測定してみましょう。サイトが画面上にピクセルを描画する速度は、重要な要素の一つに過ぎません。ユーザーがピクセルを操作しようとした際のサイトの応答性も同様に重要です。

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

FIDとは何ですか?

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

良い FID スコアとは何ですか?

優れたユーザーエクスペリエンスを提供するために、ウェブサイトは最初の入力遅延を100ミリ秒ほとんどのユーザーに対して推奨目標を達成できるようにするには、適切な測定しきい値は次のとおりです。75パーセンタイルこのしきい値はモバイルデバイスとデスクトップデバイスの両方に適用されます

FIDの詳細

イベントに応じてコードを書く開発者は、イベント発生時にコードがすぐに実行されると想定しがちです。しかし、ユーザーである私たちは、逆の状況に何度も遭遇したことがあるでしょう。スマートフォンでWebページを読み込み、ページを操作しようとしたのに、ページが全く反応せずイライラしてしまう、といった状況です。

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

次の典型的な Web ページの読み込みタイムラインを考えてみましょう。

上の図は、リソース (主に CSS ファイルと JS ファイル) を取得するために複数のネットワークリクエストを発行しているページを示しています。これらのリソースはダウンロード後にメインスレッドで処理されます。

これにより、メインスレッドが定期的にビジー状態になります (図ではベージュ色で示されています)。タスクピース）。

最初の入力遅延が長くなるのは、通常次のような場合に発生します。ファーストコンテンツペイント (FCP)そして対話時間（TTI）この期間中、ページは一部のコンテンツをレンダリングしていますが、インタラクションはまだ安定していません。なぜこのようなことが起こるのかを説明するために、タイムラインにFCPとTTIを追加しました。

かなり長い期間（3つの長時間の作業)、この間にユーザーがページを操作しようとすると (リンクをクリックするなど)、ブラウザがクリックを受信してからメインスレッドが応答できるようになるまでに遅延が発生します。

最も長いタスクの最初にユーザーがページを操作しようとすると何が起こるか見てみましょう。

ブラウザがタスクの途中で入力が行われるため、ブラウザはタスクが完了するまで入力に応答できません。ブラウザの待機時間は、ユーザーがページ上で体験するFID値となります。

この例では、ユーザーはメインスレッドが最も忙しい時間帯に入ったまさにその時にページを操作しました。ユーザーがもう少し早く（アイドル時間帯に）ページを操作していれば、ブラウザは即座に応答していたでしょう。この入力レイテンシの違いは、指標をレポートする際にFID値の分布を確認することの重要性を浮き彫りにしています。この点については、以下のFIDデータの分析とレポートに関するセクションで詳しく説明しています。

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

FIDは、入力イベントを受信した時刻と、次にメインスレッドがアイドル状態になった時刻との差を測定します。つまり、イベントリスナーが登録されていない場合でもFIDは測定されます。これは、多くのユーザーインタラクションではイベントリスナーの実行は不要であるものの、しなければならないメインスレッドはアイドル期間にある必要があります。

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

テキストフィールド、チェックボックス、ラジオボタン（入力、テキストエリア）
ドロップダウン選択リスト（選択）
リンク(a)

なぜ最初の入力だけが考慮されるのでしょうか?

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

最初の入力遅延は、サイトの応答性に関するユーザーの第一印象となり、第一印象はサイトの品質と信頼性に関する全体的な印象を形成する上で非常に重要です。
今日のウェブ上で最も大きなインタラクティブ性の問題は、ページの読み込み時に発生します。そのため、まずはユーザーがサイトとの最初のインタラクションを改善することに重点を置くことが、ウェブ全体のインタラクティブ性の向上に最も大きな影響を与えると考えています。
初回入力遅延が高い場合に推奨する解決策（コードの分割、プリロードされるJavaScriptの量の削減など）は、ページ読み込み後の入力遅延が遅い場合に推奨する解決策とは必ずしも同じではありません。これらの指標を分離することで、ウェブ開発者により正確なパフォーマンスガイダンスを提供できるようになります。

初回入力とは何ですか?

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

スクロールやズームなどの他の操作は、パフォーマンス制約がまったく異なる順次操作です (また、ブラウザはこれらの操作を別のスレッドで実行することで、遅延を隠すことができることがよくあります)。

言い換えれば、FIDはRAILパフォーマンスモデルパフォーマンス評価では、スクロールとズームは A (アニメーション) との関連性が高いため、これらの操作のパフォーマンス品質は個別に評価する必要があります。

ユーザーが Web サイトをまったく操作しなかった場合はどうなるでしょうか?

すべてのユーザーがサイトを訪れるたびにインタラクションを行うわけではありません。また、すべてのインタラクションがFIDと相関するわけではありません（前のセクションで説明したとおり）。さらに、一部のユーザーの最初のインタラクションは、好ましくない時間帯（メインスレッドが長時間ビジー状態にある時間帯）に発生する一方で、他のユーザーの最初のインタラクションは好ましい時間帯（メインスレッドが完全にアイドル状態にある時間帯）に発生することもあります。

つまり、一部のユーザーには FID 値がまったくなく、一部のユーザーには FID 値が低く、一部のユーザーには FID 値が高い可能性があります。

FIDの追跡、報告、分析方法は、普段使用している他の指標とは大きく異なる場合があります。次のセクションでは、ベストプラクティスについて説明します。

なぜ入力遅延だけを考慮するのでしょうか?

前述の通り、FID はイベント処理プロセス内の「レイテンシ」のみを測定します。FID はイベント処理自体にかかる時間や、イベントハンドラの実行後にブラウザがユーザーインターフェースを更新するまでの時間を測定するものではありません。

これらの時間はユーザーにとって非常に重要ですが、本当にこれはユーザーエクスペリエンスに影響を与えますが、これらの時間はこの指標には含まれません。開発者が回避策を追加することでエクスペリエンスが悪化する可能性があるためです。つまり、開発者はイベントハンドラーのロジックを非同期コールバック（setTimeout() または requestAnimationFrame() 経由）にカプセル化し、イベントに関連付けられたタスクからロジックを分離することができます。最終的な結果として指標のスコアは向上しますが、ユーザーは応答速度が遅いと感じてしまうでしょう。

ただし、FIDはイベント遅延の「遅延」部分のみを測定するため、イベントライフサイクルのより詳細な部分を追跡したい開発者は、イベントタイミングAPI詳細については、カスタムインジケーター関連するガイダンス。

FIDの測定方法

FIDは実際のFIDは、実際のユーザーがページを操作することを必要とする指標です。FIDを測定するには、以下のツールをご利用いただけます。

測定ツール

JavaScriptでFIDを測定する

JavaScriptでFIDを測定するには、イベントタイミングAPI次の例は、パフォーマンスオブザーバー聞いてください最初の入力エントリとコンソールにログインします:

新しいパフォーマンスオブザーバー((エントリリスト) => { のために (定数エントリのエントリリスト.エントリ取得()) { 定数遅れ = エントリ.処理開始 - エントリ.開始時間; コンソール.ログ(「FID候補」, 遅れ, エントリ); } }).観察する({タイプ: '最初の入力', 緩衝: 真実});

上記の例では、最初の入力エントリのレイテンシは、エントリのstartTimeとprocessingStartのタイムスタンプの差によって測定されます。ほとんどの場合、この差がFID値となりますが、すべての最初の入力エントリがFIDの測定に使用できるわけではありません。

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

指標とAPIの違い

API はバックグラウンドタブに読み込まれたページの最初の入力エントリをディスパッチしますが、FID の計算時にはこれらのページは無視されます。
最初の入力が発生する前にページがバックグラウンドに移動すると、API は最初の入力エントリもディスパッチしますが、FID の計算時にはこれらのページは無視されます (入力はページが常にフォアグラウンドにある場合にのみ考慮されます)。
ページが通過するとラウンドトリップキャッシュ再開時に、API は最初の入力エントリを報告しませんが、これはユーザーによる複数の異なるページ訪問であるため、このような場合には FID を測定する必要があります。
APIはiframe内の入力を報告しませんが、FIDを適切に測定するには、それらを考慮する必要があります。子フレームはAPIを使用して、これらの入力の最初のエントリを親フレームに報告し、集計することができます。

開発者は、これらのニュアンスをすべて覚える代わりに、web-vitals JavaScript ライブラリFID を測定するために、ライブラリはこれらの違いを自ら処理します (可能な場合)。

輸入 {FIDを取得} から「ウェブバイタル」; // FID が利用可能になったらすぐに測定して記録します。 FIDを取得(コンソール.ログ);

JavaScript で FID を測定する方法の完全な例については、getFID のソースコードを参照してください。

FIDデータの分析と報告

FID 値には変動が予想されるため、FID を報告するときは値の分布を確認し、高いパーセンタイルに注目することが重要です。

すべてのコアウェブ指標のしきい値優先パーセンタイルは 75 パーセンタイルですが、特に FID の場合、しきい値を 95 ～ 99 パーセンタイルに設定することを強くお勧めします。これらのパーセンタイルは、ユーザーがサイト上で特に悪い初回体験をする箇所に相当し、最も改善が必要な箇所がわかるためです。

これは、レポートをデバイスのカテゴリやタイプでセグメント化している場合でも行う必要があります。例えば、デスクトップとモバイルを別々にレポートする場合、最も注目すべきデスクトップのFID値はデスクトップユーザーの95～99パーセンタイルであり、最も注目すべきモバイルのFID値はモバイルユーザーの95～99パーセンタイルです。

FIDを改善する方法

特定のサイトの FID を改善する方法を確認するには、Lighthouse パフォーマンス監査を実行し、監査で推奨される特定のオプションを確認します。チャンス。

FIDは実用的な指標であり（Lighthouseは実験室の指標ツール）、FIDを改善するためのガイダンスは、合計ブロック時間（TBT）この実験室インジケーターには同じガイド方向があります。

FIDの改善方法の詳細については、以下を参照してください。FIDの最適化LCP を向上させることができるその他の個別のパフォーマンス手法に関する詳細なガイダンスについては、以下を参照してください。

1/5 - (1票)