WEBサイトにおけるFID(First Input Delay)指標の重要性について

  • 2021年1月6日
  • 2019年春にGoogleがこのアップデートを発表して以来、われわれはCore Web Vitalsについてかなり熱心に研究してきました。私たちは、集められる指標の共有をするだけでなく、組織全体のチームを通じて、パフォーマンスについての幅広い議論をしてきました。

    サイト担当者がCore Web Vitalsに注目するようになったのは、2021年5月にGoogleが、SEOランキングの要素としてCore Web Vitalsを含めると発表したからです。

    多くの人にとって興味があるのは、よりよいUXを提供するために、数多い膨大なメトリックを、3つの簡単なガイドラインとして抽出してしまうことです。

    私たちは、この3つの指標の評価と調査を続けながら、その長所と短所については透明性をもった議論に注力しています。

    この記事では、以下について説明します。

    ・FIDとは?

    ・FIDはどのように見えるか?

    ・ユーザーインタラクションを計測する重要性

    ・JavaScriptがユーザー動作に与える影響

    ・主要メトリックとの比較。FIDはどのように見るか?

    FIDとは何?、また何を計測しようとしていますか?

    レスポンスのいいアプリケーションは素晴らしい。しかし、低速で、動作が鈍く、不安定なアプリケーションにはダメです。ユーザーにストレスを与え、最終的にはサイトのブランドに影響を与え、場合によっては収益にも影響を与えます。

    First Input Delay (FID) は、アプリケーションがユーザー入力にどれだけ素早く反応するかを見る指標です。ユーザーの最初の操作からブラウザの応答までの時間は、ブラウザがビジーの状態のときに遅延することがあります。メイン・スレッド・アクティビティは、JavaScriptに多く起因します。長いタスク(JavaScriptに起因する50 ms以上かかるタスク)が与える影響と、記事1記事2では、それらをどのように計測するについて議論しています。

    GoogleがFIDをCore Web Vitalとする理由として、「長いタスクとFIDの間に強い相関関係があるだろう」ということです。実際、シンセティック(合成)データを参照する場合には、FIDの代替として総ブロッキング時間を見ることをおすすめします。FIDの目的とは、「JavaScriptがページエクスペリエンスに与える影響を理解する」ことだということです。

    FIDに関する注意事項を次に示します。

    FIDに必要なユーザ入力は、クリック、タップ、キープレスとして定義され、スクロールやズームは含みません。
    FIDは、リアル・ユーザーモニタリング(フィールドデータ)でのみ測定可能。
    SpeedCurve のRUMの場合は、従来のアプリケーションはSPAと同様に、FIDを計測します。
    現在、Chromeブラウザでは、ネイティブでFirst-inputのパフォーマンスエントリタイプがサポートされていますが、FIDはすべてのモダンブラウザで測定することができます。

    FIDはWeb全体でどのように見えますか?

    実際にFIDがどのように見えるかを理解するために、RUMデータを元にWebを調べました。Googleの推奨では、FIDを100 ms未満の75パーセンタイルに保つことで 「良好」 なレーティングを維持できます。表面上, FIDスコア33 msで全面的に「非常によい」といえます。全体の95%が「レッド」「Poor 」の範囲外にあるこことを考えると、FIDのロングテールは、かなり妥当なように思われます。

    グリーンはいいですね!これまでのところ、サイトオーナーは、ユーザーのページ操作に悪影響を与えないように、長いタスクをしっかり管理できており、素晴らしい仕事をしています。

    ここでユーザーを満足させるためにやるべきこと多くはないしょう。そんなに速くはありません。

    FIDはほとんどの状態でかなり低いように見えますが、 長いタスクは、Web全体で大きな問題です。75パーセンタイルでは、長いタスク(ページ上の長いタスクの合計)は2,286ミリ秒とかなり高くなります。

    インタラクションの計測

    SpeedCurveでは、入力遅延を計測しますが、ユーザーがアプリケーションを操作するタイミングの計測も重要と考えています。これを「インタラクション (IX) メトリック」と呼んでいます。ユーザーの最初のインタラクションを測定し,インタラクションのタイプ(キーを押す、クリック/タップする、スクロールする)を分析します。本研究の目的において、 FIDと整合させるために、スクロール・インタラクションを除外します。

    メトリックの典型的なシーケンスを示すページエクスペリエンスのタイムライン。値は、各メトリックの75パーセンタイルを表しています

    ウェブのバイタルへの影響を考えると、FIDの時間が比較的短く、かなり楽観的に見えるのは、間違いなくこのためです。やっかいなものの大部分であり、CPUの長時間のタスクは、すでに完了しています。

    長いタスクがページエクスペリエンスに影響を与えることは確かですが、表面的には長いタスクとFIDの間に固有の関係があるようには見えません。驚くことではありませんが、このチャートのように長いタスクはインタラクション時間と強い相関関係があることがわかります

    75パーセンタイルでIX回と相関する長いタスクの分布(出典:SpeedCurve RUM)

    つまり、タスク時間が長いほど、IX時間も長くなるということです。でもそれが本当に重要なのでしょうか?

    IX時間が増えるとほかの数値に影響があるのかどうかを続いて考察したいと思います。

    ユーザー行動とどのように関連しているのか?

    SpeedCurveでは、常にユーザー行動での指標の影響を見ることを注視してきました。

    特定のパフォーマンス指標の相関関係や影響を判断するために、確認できる行動の結果はかなりの数があります。 バウンスレート(直帰率)は、多数のサイトで確認するのに適した普遍的な指標です。

    特定のパフォーマンス指標の相関関係や影響を判断するために、多数の動作結果を調べることができます。バウンスレート(直帰率)は、多数のサイトをチェックするための一般的な指標として適しています。

    FIDの場合、直帰は最適なインジケーターではないかもしれません。直帰したセッションではインタラクションが少ないためです。その代わりに、ランダムに選ばれた多くのコマースサイトのユーザー行動に、これらの指標がどのように関連しているかを調べてみました。これらのサイトのトラフィックは高く、新型コロナためにオンライン活動が増加しいますし、話しているような大量のサイバーショッピングが起こっています。

    私たちは、二つの指標(FIDおよびJSのロングタスク)が$$$と関連し、$$$とコンバージョンしているかを調べました。

    調査結果

    FIDはコンバージョンとは意味ある相関はないようです。つまり悪くなる場合を除いて。ほとんどのサイトは、同じく決定的なパターンを示しませんでした。すでに見てきたように、ほとんどのサイトでFIDの値がそれほど高くないためです。

    FIDの配分VSコンバージョンセッションの分布には相関関係がありません

    (出典:SpeedCurve RUM)

    調査したサイトでは, FIDがスペクトルの遅い端に向かってクリープするサイト指標として提供される1つの例外がありました。このサイトの75パーセンタイル値は~60ミリ秒以下で、これは「良い 」の範囲(100ms以下)のままです。コンバージョンレートへの影響は別の話となります。FIDが20 msを超えるセッションでは、コンバージョン率に顕著な低下があり、60 ms付近で底となりました。

    低速のFIDと相関するFIDと変換されたセッションの分布(出典:SpeedCurve RUM)

    厳密に比較すると、長いタスクは全体的に高い相関関係がありそうです。タスクが1秒かそれ以上になると、忍耐の余地はあまりありません。下のグラフは、フルセッション・データでの相関関係を示していますが、ホーム/ランディングページ、製品/ブラウズページ、決済フロー内のページなど、さまざまなページ・タイプで同じパターンがページレベルで見ることができます。

    長いタスクとコンバージョンセッションの分布は、買い物行動への影響を示しています

    それはどういう意味ですか?

    JS問題を解決しようとFIDだけに頼るなら、それはユーザを犠牲にして大切なものをを逃しているというリスクがあります。

    誤解のないように、FIDを理解することは非常に重要です。特に、バイタルのスペクトルの「ニーズの改善」 (赤は悪い!)側にいる場合には、まさに真実です。おそらく、このVitalの現在のしきい値を喜んでリセットすべきでしょう。100 msのしきい値の代わりに、アプリケーション目標として、バーを少し高く 50 msに設定するか、FIDウィンドウ内で長いタスクが発生しないように検討します。

    FIDに加えて、SpeedCurveで利用可能なメトリックがいくつかあります。JavaScriptの問題を把握するには、次のことに注目してください。

    Long tasks:

    • Long tasks:ナビゲーションの開始からのページ上の長いタスクに割り当てられた合計時間
    • Long taskの数:ページ内で発生した個々の長いタスクの合計数
    • 最長JSタスク:テント内で最長のポール。ここから出発し、シンセティック(合成)モニタリングを使用してソースを特定します。

    Interaction times:常に最適化できるわけではありませんが、このコンテキストは、ユーザがアプリケーションにどのように応答し、FIDが発生する場所を正確に理解する場合に役立ちます。スクロール操作は除外しましたが、JavaScriptタスクを最適化して、ユーザーが恐れるギクシャクした遅い状況を回避する場合にも、このコンテキストは重要です。

    あなた自身のデータは何を示していますか?

    私たちは多くのデータを調査し、いくつかの傾向を見てきましたが、自分のデータを見ることをお勧めします。Core Web Vitalsは、複数のRUM製品でもサポートされるようになりました。RUMを持っていない場合や、SpeedCurveのRUMを使って独自の解析を行う方法に興味がある場合は、ここから始めてください。

     


    ※この記事はSpeedCurve社の英文情報を元に、内容を分かりやすく編集、翻訳した記事です。

    Copyright © 2021 SpeedCurve Limited. All Rights Reserved.

>サイトが重い、ファーストビューが速く表示されないこんなお悩み、ご相談ください。

サイトが重い、ファーストビューが速く表示されないこんなお悩み、ご相談ください。