First Input Delay (FID)

— 更新済み
Available in: English, Español, Português, Русский, 中文, and 한국어
Appears in: 読み込み時間の高速化 | Core Web Vitals | 指標
Philip Walton
Philip Walton
TwitterGitHubHomepage
このページ内

良い第一印象を与えることがいかに重要かは誰もが知っています。新しい人と出会うとき、そしてウェブ上で体験を構築するときも重要です。

Web 上では、第一印象の良し悪しがお客様がロイヤル ユーザーとなってくれるか、それとも離脱して二度と戻ってこないかの分かれ道となります。そして、一体何が良い印象としてお客様の中に残るのか、またこのサイトがユーザー対してどのような印象を与えているのかをいかに測定するかが課題となります。

そして Web 上での第一印象には、様々な見方が存在します。サイトのデザインや視覚的な魅力を重視する視点もあれば、スピードや応答性などを重視する視点も存在します。

Web API を使用してサイトのデザインがどの程度ユーザーに好まれているかを測定するのは難しいですが、そのスピードや応答性については測定が可能です。

ユーザーにとっての第一印象であるサイトの読み込みの速さは、First Contentful Paint (視覚コンテンツの初期表示時間、FCP) を使用して測定が可能です。しかし、サイトが画面にピクセルを描画するスピードは、ユーザーが体験する物語の一部に過ぎません。ユーザーがそのピクセルを操作しようとしたときにサイトがいかに早く反応するかという点も、同様に重要なのです。

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

FIDとは何ですか？ #

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

良いfid値は2.5秒、悪い値は4.0秒を超え、その間の値は改善が必要

FID における良いスコアとは？ #

良好なユーザー体験を提供するために、サイトは First Input Delay が 100 ミリ秒以下になるように努力する必要があります。ほぼすべてのユーザーに対してこの目標値を確実に達成するためには、モバイル デバイスとデスクトップ デバイスに分けた上で、総ページロード数の 75 パーセンタイルをしきい値として設定します。

FID の詳細 #

イベントに応答するコードを書く開発者としては、イベントが発生すればコードはすぐに実行されるものだと思い込みがちです。しかしながらユーザーとしては、スマートフォンで Web ページを読み込み、操作をしようとしているのに何も反応がなくてイライラした経験がきっとあるはずです。

一般的に入力遅延 (別名: 入力レイテンシー) は、ブラウザーのメイン スレッドが何か他の作業で忙しく、ユーザーの操作に (まだ) 応答できない場合に発生します。よくある理由としては、アプリが読み込んでいる大きな JavaScript ファイルの解析と実行でブラウザーがビジー状態になっていることが挙げられます。この間、ブラウザーはイベント リスナーを実行することができなくなります。なぜなら、ブラウザーが読み込んでいる JavaScript がブラウザーに対して別の作業を指示している可能性があるからです。

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

ページ読み込みの追跡例

上の図は、ページがリソース (主に CSS や JS ファイル) に対していくつかのネットワーク リクエストを行い、それらのリソースのダウンロードが完了した後、メイン スレッドで処理を行っている様子を示しています。

その結果として、メイン スレッドが一時的にビジー状態となる期間 (ベージュ色のタスクブロックで示されている部分) が現れます。

最初に発生する長い入力遅延は、一般的に First Contentful Paint (FCP) と Time to Interactive (操作可能になるまでの時間、TTI) の間に発生します。これは、ページがコンテンツのレンダリングを一部完了しているものの、まだ確実に操作可能になっていないために発生します。この現象を解説するために、FCP と TTI をタイムラインに追加してみましょう。

FCPとTTI を追加したページ読み込みの追跡例

FCP と TTI の間に、かなり長い期間に渡って (3 つの長く時間がかかっているタスクを含む) 処理が発生していることにお気付きかもしれません。ユーザーがその期間内にページの操作を試みると (たとえばリンクをクリックするなど)、クリックを受け取ってからメイン スレッドが応答するまでの時間に遅延が生じます。

それでは、ユーザーが最も長く時間がかかっているタスクの発生初期に近いタイミングでページの操作を試みた場合に一体何が起こるかについて考えてみましょう。

FCP、TTI、FID を追加したページ読み込みの追跡例

ブラウザーがタスクを実行している最中に入力が発生したため、ブラウザーが入力内容に応答するためには、このタスクが完了するまで待機しなければなりません。この待機時間が、このページでのユーザーの FID 値となります。

この例では、たまたまメイン スレッドが最もビジーな時間帯の初期にユーザーがページにアクセスしました。もしもユーザーがもう少し早く (アイドル期間内に) ページにアクセスしていれば、ブラウザーはすぐに反応できたはずです。このような入力遅延のばらつきは、指標のレポートで FID 値の分布を確認することの重要性を示しています。この点については、後述する「FID データの分析とレポート」のセクションで詳しく説明します。

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

FID は、ブラウザーが入力イベントを受け取ってからメイン スレッドが次のアイドル期間に入るまでの差分を測定します。つまり、イベント リスナーが登録されていない場合でも FID は測定されるのです。その理由は、ユーザーによるインタラクションの多くはイベント リスナーを必要としませんが、実行のためにはメイン スレッドがアイドル状態であることは必須であるからです。

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

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

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

遅延の発生がユーザー エクスペリエンスの低下につながるのはどのような入力であっても同様ですが、Google では以下の理由から初回入力の遅延の測定を主に推奨しています。

  • 初回入力の遅延は、サイトの応答性に関するユーザーの第一印象となります。第一印象は、サイトの品質や信頼性についての全体的な印象を形成する上で非常に重要な要素となります。
  • 今日の Web で見られるインタラクティブ性に関する問題の中でも、最も重大なものはページの読み込み時に発生しています。そのため Google では、サイトでのユーザーによる初回のインタラクションの改善に注力することが、Web 全体におけるインタラクティブ性の改善に最も大きな効果をもたらすことになると考えています。
  • 最初に発生する長い入力遅延に対するサイト側での修正方法として推奨されているソリューション (コードの分割、JavaScript の事前読み込みの削減など) は、ページの読み込み後に発生する入力に時間のかかるタイプの遅延を修正するためのソリューションとは必ずしも一致しません。これらの指標を分離することにより、より具体的なパフォーマンス ガイドラインを Web 開発者に提供できるようになります。

何が初回入力としてカウントされますか？ #

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

スクロールやズームなどといったその他のインタラクションは連続的な動作であり、パフォーマンス上の制限事項が全く異なります (また、別のスレッドで実行することによってブラウザー側でレイテンシーを隠すことも可能です)。

言い換えるならば、FID は RAIL パフォーマンス モデルにおける R (応答性) に焦点を当てているのに対し、スクロールやズームは A (アニメーション) により強い関連性を持っており、それらのパフォーマンス品質は個別に評価される必要があります。

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

すべてのユーザーが訪問するサイトで必ず操作を行うわけではありません。また、すべての操作が FID に関連しているわけでもありません (前のセクションで説明したとおりです)。さらには、ユーザーによって初回操作が悪いタイミング (メイン スレッドが長期間ビジー状態になっている時) に行われる場合もあれば、良いタイミング (メイン スレッドが完全にアイドル状態になっている時) に行われる場合もあります。

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

FID をどのように追跡し、レポートし、分析するかについては、おそらくあなたが慣れ親しんできた他の指標とはかなり方法が異なるはずです。次のセクションでは、これらを実施する場合に考えられる最善の方法について説明します。

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

先に述べたように、FID はイベント処理の "遅延" のみを測定します。イベントの処理時間そのものや、イベント ハンドラーの実行後にブラウザーが UI を更新するまでの時間については測定を行いません。

こういった時間もユーザーにとって重要であり、ユーザー体験にかなりの影響を及ぼすものですが、この指標には含まれません。これは、これらの時間を指標に含めることが実際にはユーザー体験の質を落としてしまう回避策の実装へと開発者を駆り立ててしまうことを避けることが目的です。この場合の回避策には、イベント ハンドラーのロジックを、イベントに関連するタスクから分離するために (setTimeout() や requestAnimationFrame() を介した) 非同期コールバックでラップすることなどが挙げられます。結果的に指標のスコアは改善されますが、ユーザーが実際に感じる応答時間は長くなってしまいます。

FID はイベントのレイテンシーの "遅延" 部分のみを測定するものですが、イベントのライフサイクルのより幅広い部分を追跡したいという開発者の方は、Event Timing API を使用することでそれらを実行することができます。詳細については、「カスタム指標」に記載されているガイドを参照してください。

FID の測定方法 #

FID の測定には実際のユーザーによるページの操作が必要となるため、実際のユーザー環境でしか測定できません。FID は、以下のツールを使用して測定することができます。

フィールド測定を実施するためのツール #

JavaScript を使用して FID を測定する #

Browser support
  • 76
  • 89
  • 79

Source

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 では、ページが Back/Forward Cache から復元された場合の first-input エントリはレポートされませんが、これらはユーザーにとって別々のページ訪問となるため、こういったケースにおいても FID は測定される必要があります。
  • API では iframe 内で発生した入力はレポートされませんが、FID を適切に測定するためにはこれらの入力も考慮に入れる必要があります。サブフレームが集約のために API を使用してその親フレームに first-input エントリをレポートすることができます。

こういった微妙な違いをすべて記憶していなくても、web-vitals JavaScript ライブラリを使用して FID を測定すれば、これらの違いを (可能な限り) 処理してくれます。

import {onFID} from 'web-vitals';

// 実行可能となった時点ですぐに FID の測定やログ記録を実行します。
onFID(console.log);

JavaScript を使用して FID を測定する方法に関する詳細な例については、onFID() のソース コードを参照してください。

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

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

すべての Core Web Vitals でしきい値となるパーセンタイルの選択は 75 ですが、FID については特に 95 から 99 パーセンタイルを確認することを強くお勧めします。なぜならこれらのパーセンタイルは、ユーザーがあなたのサイトで経験した第一印象の中でも特に悪いものに対応しているからです。これらを確認することによって、最も改善が必要な領域を見つけることができます。

これは、デバイスのカテゴリや種類ごとにレポートをセグメント化した場合でも同様です。たとえば、デスクトップとモバイルで別々のレポートを実行している場合、デスクトップで最も気をつけなければならない FID 値はデスクトップ ユーザーのうち 95 から 99 パーセンタイルに含まれるユーザーの値であり、モバイルで最も気をつけなければならない FID 値はモバイル ユーザーのうち 95 から 99 パーセンタイルに含まれるユーザーの値となります。

FID の改善方法 #

特定のサイトについて FID の改善方法を把握するには、Lighthouse でパフォーマンス監査を実行し、そこで推奨される具体的な Opportunities (改善機会) に注目します。

FID はユーザー環境で測定される指標ですが (Lighthouse はラボ環境で使用するメトリック ツールです)、FID を改善するためのガイダンスは、ラボ環境での指標である Total Blocking Time (TBT) を改善するためのガイダンスと同じです。

FID の改善方法の詳細については、「Optimize FID (FID を最適化する)」を参照してください。FID の改善にもつながる個別のパフォーマンス改善手法に関するその他のガイダンスについては、以下を参照してください。

CHANGELOG #

Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in this CHANGELOG.

If you have feedback for these metrics, you can provide it in the web-vitals-feedback Google group.

最終更新

— 記事を改善する
Return to all articles
共有する
By Chrome DevRel