私たちは皆、良い第一印象を与えることがいかに重要であるかを知っています。これは、新しい人と出会うときだけでなく、ウェブでエクスペリエンスを構築するときにも重要です。
ウェブでは、第一印象が良いかどうかによって、ロイヤリティの高いユーザーになるか、リピーターになるかが決まります。良い印象を与えるものは何か、ユーザーにどのような印象を与える可能性があるかを測定するにはどうすればよいでしょうか。
ウェブにおける第一印象にはさまざまな形があります。サイトのデザインや視覚的な魅力に関する第一印象や、スピードや応答性に関する第一印象などです。
ウェブ 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>）
最初の入力のみを考慮するのはなぜですか？
入力の遅延はユーザー エクスペリエンスの低下につながる可能性がありますが、主にいくつかの理由から初回入力遅延を測定することをおすすめします。
- 初回入力の遅延は、サイトの応答性に関するユーザーの第一印象です。第一印象は、サイトの品質と信頼性の全体的な印象を形成するうえで非常に重要です。
- 今日のウェブにおけるインタラクティビティの最大の問題は、ページの読み込み中に発生します。そのため 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-vitalsJavaScript ライブラリ
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エントリを親フレームに報告できます。
デベロッパーは、これらの微妙な違いをすべて記憶する代わりに、web-vitals JavaScript ライブラリを使用して FID を測定できます。FID は、これらの違いを処理します（可能な場合、iframe の問題は対象外です）。
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
JavaScript で FID を測定する方法の完全な例については、onFID() のソースコードをご覧ください。
FID データの分析とレポート
FID 値には変動が予想されるため、FID に関するレポートを作成する際には、値の分布を調べて高いパーセンタイルに焦点を合わせることが重要です。
ウェブに関する主な指標のすべてのしきい値のパーセンタイルの選択は 75 パーセンタイルですが、特に FID については、95 ～ 99 パーセンタイルを確認することを強くおすすめします。これは、ユーザーがサイトで最初に受けるエクスペリエンスが特に悪いものに対応するためです。改善が必要な領域がわかります
これは、デバイスのカテゴリやタイプでレポートを分割する場合にも当てはまります。たとえば、パソコンとモバイルで別々のレポートを作成する場合、パソコンで最も重視する FID 値はパソコン ユーザーの 95 ～ 99 パーセンタイル、モバイルで最も重視する FID 値はモバイル ユーザーの 95 ～ 99 パーセンタイルとします。
FID を改善する方法
この指標を改善する方法については、FID の最適化に関する詳細なガイドをご確認ください。
変更履歴
指標の測定に使用する API や、指標自体の定義にバグが見つかることもあります。そのため、必要な変更を行う必要が生じることがあります。また、こうした変更は、内部のレポートやダッシュボードに改善または回帰として表示されることがあります。
指標の実装または定義に対する変更はすべて、こちらの変更履歴に掲載されています。
これらの指標についてフィードバックがある場合は、web-vitals-feedback Google グループからお寄せください。