<ph type="x-smartling-placeholder">
良い第一印象を与えることがいかに重要であるかは誰でも知っています。大事なこと 新しい人と会うときにも重要です。また、Google Chat で体験を できます。
ウェブでは、第一印象が良いかどうかが決め手となる リピーターになる人もいれば 利用をやめて二度と利用しない人もいます問題は インプレッションの測定方法 どうすればよいでしょうか
ウェブでは、第一印象はさまざまな形態を取ります。 サイトのデザインや視覚的な魅力の第一印象だけでなく スピードと応答性について 評価しています
ウェブ API を使用したサイトのデザインがどの程度ユーザーが好むかを測定することは困難ですが、 速度と応答性を測定することは不可能です。
サイトの読み込み速度に関するユーザーの第一印象は、 First Contentful Paint（FCP）。サイトのピクセル描画にかかる時間は ストーリーの一部にすぎません同様に重要な点は ユーザーがこれらのピクセルを操作しようとするときです。
FID（First Input Delay）指標は、サイトにアクセスしたユーザーに サイトのインタラクティブ性と応答性が向上します。
FID とは
FID は、ユーザーが最初にページを使用した（つまり、 リンクをクリックする、ボタンをタップする、JavaScript を活用したカスタム コントロールを使用するなど） ブラウザが実際にイベント ハンドラの処理を開始できる時点まで そのインタラクションに対するレスポンスで返されます。
優れた FID スコアとは
優れたユーザー エクスペリエンスを提供するため、サイトは最初の入力を表示するよう努める必要があります。 遅延が 100 ミリ秒以下。目標を確実に達成するには 測定するしきい値は、このユーザーのほとんどが占める割合の 75 パーセンタイル モバイル デバイスとデスクトップ デバイスで分割されたページ読み込み
<ph type="x-smartling-placeholder">
FID の詳細
イベントに応答するコードを記述するデベロッパーは、多くの場合、 イベントが発生するとすぐに実行されます。しかし ユーザーは 誰しも、ウェブページにウェブページを読み込み、 何とか連絡してみて、何も起こらないのにイライラした 発生しました。
一般に、入力遅延（または入力レイテンシ）が発生するのは、ブラウザの メインスレッドが他の処理でビジー状態になるため、ユーザーに（まだ）応答できない。 この問題が発生する一般的な理由の 1 つは、ブラウザが解析と実行にビジー状態であることです。 アプリで読み込まれる大きな JavaScript ファイル。その間は実行できません すべてのイベント リスナー。これは、読み込まれる JavaScript が できます。
一般的なウェブページ読み込みのタイムラインについて考えてみましょう。
上の図は、いくつかのネットワーク リクエストを行っているページを示しています。 （ほとんどの場合、CSS および JS ファイル）で、これらのリソースの メインスレッドで処理されます。
その結果、メインスレッドが一時的にビジー状態になり、 色がベージュ色で示されます。 タスク ブロックします。
First Contentful Paint の間隔が長いと初回入力の遅延が発生することが一般的です。 （FCP）とTime to Interactive（TTI）の問題が発生しないよう、ページに コンテンツの一部がレンダリングされましたが、まだインタラクティブではない状態です。例を使って説明すると、 タイムラインに FCP と TTI が追加されています。
お気づきかもしれませんが、これにはかなりの時間がかかります（この中には 3 つの タスク）を、ユーザーが試行した場合、FCP と TTI の間の その間にページを操作すると（たとえばリンクのクリックなど）、 クリックを受信してからメインスレッドがスレッドを できます。
ユーザーがページの近くに 開始することもできます。
入力はブラウザがタスクを実行している最中に行われるので、 タスクが完了するまで待機しないと入力に応答できません。「 待機時間は、このページのこのユーザーの 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。次の例で、
作成
PerformanceObserver
リッスンする
first-input
それらのエントリがコンソールに記録されます。
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 は これらのケースでは 1 つのページとして表示されるため、 あります。 - iframe 内で発生した入力は API ではレポートされないが、指標はレポートされる
ページのユーザーエクスペリエンスの一部として
組み込むからですこれにより、
CrUX と RUM の違いとして表示される。
FID を適切に測定するには、これらを考慮する必要があります。サブフレームは API を使用可能
集約のために親フレームに
first-inputエントリを報告します。
これらの微妙な違いをすべて覚える代わりに、
web-vitals JavaScript ライブラリを
FID を測定します。これにより、これらの違いが自動的に処理されます（可能な場合、iframe の問題は対象外です）。
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
詳細は、このモジュールのソースコードを
onFID()
をご覧ください。
FID データの分析とレポート
FID 値は変動することが予想されるため、 FID では、値の分布を調べて、より高いパーセンタイルに着目します。
一方で、 すべてに対してパーセンタイル Core Web Vitals のしきい値は 75 番目ですが、FID については依然として 95 ～ 99 パーセンタイルを確認することをおすすめします。これらは サイトの最初のエクスペリエンスが 悪影響を及ぼす可能性がありますすると、 改善が必要な領域を確認できます
これは、デバイスのカテゴリやタイプでレポートを分割する場合にも当てはまります。対象 たとえば、パソコンとモバイルで別々にレポートを実行する場合、 特に重要視されているのは PC ユーザーの 95 ～ 99 パーセンタイルです モバイルで最も重視する FID 値は 95 ～ 99 番目 モバイル ユーザーのパーセンタイルです。
FID を改善する方法
この指標を改善するための手法については、FID の最適化に関する完全なガイドをご覧ください。
変更履歴
指標の測定に使用される API でバグが見つかることがありますが、指標自体の定義に見つかることもあります。そのため、変更が必要となることがあり、こうした変更は社内のレポートやダッシュボードに改善や回帰として表示されることがあります。
管理しやすくするために、これらの指標の実装または定義に対するすべての変更は、こちらの変更履歴で確認できます。
これらの指標についてフィードバックがある場合は、web-vitals-feedback Google グループからお寄せください。