Chrome ユーザー エクスペリエンス レポートでの初回入力遅延に関するテスト

Chrome ユーザー エクスペリエンス レポートの目的は、実際のユーザー パフォーマンスの分布と変化をウェブ コミュニティが把握できるようにすることです。これまで、First Contentful Paint(FCP)や Onload(OL)など、ペイントとページ読み込みの指標に重点を置いており、ウェブサイトがユーザーにとって視覚的にどう機能するかを理解するのに役立っています。2018 年 6 月のリリース以降、ウェブページのインタラクティビティに重点を置いた新しいユーザー中心の指標である First Input Delay(FID)がテストされています。この新しい指標により、ユーザーの入力に対するウェブサイトの応答性の良さをより深く理解できるようになります。

最近、Chrome で FID がオリジン トライアルとして利用できるようになりました。これにより、ウェブサイトでこの新しいウェブ プラットフォーム機能をテストできるようになります。同様に、FID は Chrome UX レポートで試験運用版の指標として利用できます。つまり、別の「試験運用」名前空間内でオリジン トライアル期間中、FID を使用できます。

FID の測定方法

FID とは何でしょうか。First Input Delay の発表に関するブログ投稿での定義は次のとおりです。

First Input Delay(FID)は、ユーザーが初めてサイトを操作(リンクのクリック、ボタンのタップ、カスタムの JavaScript 制御コントロールの使用など)してから、ブラウザが実際にその操作に応答できるまでの時間を測定します。

ビジー状態のメインスレッドがユーザー操作に対するレスポンスをどのように遅延させるかを示すアニメーション。

これは、誰かのドアホンを鳴らしてから、誰かがドアに応答するまでの時間を測定するようなものです。時間がかかる場合は、さまざまな理由が考えられます。たとえば、その人がドアから遠くにいる場合や、すぐに動けない場合があります。同様に、ウェブページが他の作業でビジー状態であったり、ユーザーのデバイスの動作が遅くなったりすることがあります。

Chrome UX レポートで FID を確認

何百万ものオリジンから収集された 1 か月分の FID データでは、すでに豊富な興味深い分析情報が発見されています。BigQuery の Chrome UX レポートからこの分析情報を抽出する方法を示すクエリをいくつか見てみましょう。

まず、developers.google.com の高速 FID エクスペリエンスの割合をクエリします。FID が 100 ミリ秒未満の高速エクスペリエンスと定義できます。RAIL の推奨事項に従い、遅延が 100 ミリ秒以下であれば、ユーザーは瞬時に遅延を感じるはずです。

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
  origin = 'https://developers.google.com'

その結果、このオリジンでの FID エクスペリエンスの 95% が瞬間的なものとして認識されることがわかります。とても良いように見えますが、データセット内のすべてのオリジンと比較してどうでしょうか?

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid

このクエリの結果を見ると、FID エクスペリエンスの 84% が 100 ミリ秒未満であることがわかります。そのため、developers.google.com は平均を上回っています。

次に、このデータをスライスして、パソコンとモバイルで高速 FID の割合に違いがあるかどうかを確認します。1 つの仮説として、モバイル デバイスでは FID 値が遅く、デスクトップ パソコンに比べてハードウェアが低速であることによるものと考えられます。CPU の処理能力が低いと、ビジー状態の時間が長くなり、FID の動作が遅くなる可能性があります。

SELECT
  form_factor.name AS form_factor,
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
  form_factor
form_factor fast_fid
デスクトップ 96.02%
着信音を鳴らします 79.90%
[タブレット情報] 76.48%

結果は今回の仮説を裏付けるものでした。デスクトップでは、スマートフォンやタブレットのフォーム ファクタに比べて、高速 FID エクスペリエンスの累積密度が高くなっています。CPU パフォーマンスなど、このような相違が存在する理由を理解するには、Chrome UX レポートの範囲外で A/B テストを行う必要があります。

ここまでで、オリジンで高速な FID エクスペリエンスがあるかどうかを特定する方法を見てきました。次に、パフォーマンスが優れているオリジンをいくつか見てみましょう。

例 1: http://secretlycanadian.com

Secretlycanadian.com の WebPageTest のフィルムストリップ

このオリジンでは、FID エクスペリエンスの 98% が 100 ミリ秒未満になっています。どのように対処しているのでしょうか。WebPageTest で作成方法を分析してみると、画像が多すぎる WordPress ページですが、168 KB の JavaScript があり、ラボのマシンでは約 500 ミリ秒で実行されます。これは、HTTP アーカイブによれば、このページは 28 パーセンタイルに位置している JavaScript としてはあまりありません。

Secretlycanadian.com の AWebPageTest ウォーターフォール

2.7 ~ 3.0 秒のピンク色のバーは、HTML 解析フェーズを示しています。この間、ページはインタラクティブでなく、視覚的に不完全に表示されます(上のフィルムストリップの「3.0s」をご覧ください)。その後、処理が必要な長いタスクは分割され、メインスレッドは静止状態が維持されます。11 行目のピンク色の線は、JavaScript の動作がバースト的にどのように分散するかを示しています。

例 2: https://www.wtfast.com

wtfast.com の WebPageTest のフィルムストリップ

このオリジンでは 96% のインスタント FID エクスペリエンスがある。267 KB の JavaScript(HTTP アーカイブの 38 パーセンタイル)を読み込み、ラボのマシンで 900 ミリ秒処理します。フィルムストリップを見ると、ページが背景のペイントに約 5 秒、コンテンツのペイントにさらに約 2 秒かかることがわかります。

wtfast.com の WebPageTest ウォーターフォール

結果について最も興味深いのは、メインスレッドが 3 ~ 5 秒間ビジー状態である間は、インタラクティブなものが何も表示されていないことです。FID を改善するのは、このページの FCP の遅さが原因です。この例は、ユーザー エクスペリエンスを表すために多くの指標を使用することの重要性を示す良い例です。

探索を始める

FID について詳しくは、The State of the Web の今週のエピソードをご覧ください。

Chrome UX レポートで FID を利用することにより、インタラクティビティのベースラインを確立できます。このベースラインを使用して、将来のリリースでの変化を確認したり、個々のオリジンのベンチマークを実施したりできます。ご自身のサイトのフィールド測定で FID の収集を開始する場合は、bit.ly/event-timing-ot からオリジン トライアルに登録し、イベント タイミング機能を選択してください。もちろん、ウェブでのインタラクティビティの状態に関する興味深い分析情報を得るために、データセットの探索を開始してください。これはまだ試験運用中の指標です。フィードバックをいただき、分析についてのご意見は Chrome UX レポートのディスカッション グループまたは Twitter の @ChromeUXReport からお送りください。