サポート

操作不能状態(Jank)とユーザーエクスペリエンス(UX)を計測する

【補足】
Jank : ブラウザ上で操作不能な状態(感覚)
UX : ユーザーエクスペリエンス(ユーザー体験)

Steve Souders

2019年5月1日水曜日

10年前、ウェブサイトを高速化する上でネットワークが最大の問題点でした。昨今では、CPUが主な懸念点です。これは、過去6年間でJavaScriptのサイズが3倍に拡大する一方で、ネットワークが高速化したためです。JavaScriptは他のすべてのブラウザアクティビティを合わせたものよりも多くのCPUを消費するため、この発展はとても重要です。JavaScriptやその他のアクティビティがCPUをブロックしている間、ブラウザはユーザーの入力に反応できず、遅い、いらいらする、またはページが壊れているという感覚を生み出します。

CPUに注目しやすくするために、ここ1、3年の間にいくつかの新しいパフォーマンス・メトリックが定義され普及してきました。この記事ではこれらに焦点を当てます。

  • First CPU Idleは、ページに欠陥のない場合を測定します。具体的には、First Contentful Paintの後、ブラウザのメインスレッドが50㎳以上ブロックされることがない最初の5秒間です。2~4秒位が一般的です。
  • First Input Delayは、ユーザーがページを操作するタイミング(e.g、クリック、スクロール)と、ブラウザーがその入力に対して動作できるタイミングとのギャップを測定します。First Input Delayの値は非常に低く、適切なターゲットは10ミリ秒ですが、25ミリ秒が一般的です。
  • First Interaction Timeは、最初のユーザー入力が行われる時間です。これはサイトやページの種類によって大きく異なります。優れた検索結果ページでは、ユーザーがすばやくスクロールしてクリックするため、最初の対話時間が短くなる場合があります。ユーザーがページを操作する前にコンテンツの読み取り(見出し、記事)を開始するため、メディアサイトの初回操作時間が長くなる場合があります。SpeedCurveではこれを「IX time」と呼びます。
  • Total Long Task CPU Timeは、ページ内で発生したすべてのLong taskの合計です。「Long task」は、50ミリ秒以上メイン・スレッドをブロックするブラウザ・イベントです。

これらの指標を視覚化するための図があります。

上の図は、WebPageTestの(わずかに修正された)CPUタイムラインです。Long task(CPUが50ミリ秒以上ブロックされている場合)は赤で表示されます。上のタイムラインには2つのLong taskがあります。緑は、Long taskがない場所を示します。最初のCPUアイドル状態は3.0秒に発生します。これは、タイムラインの最初のポイントで、5秒間に長いタスクがありません(3秒から8秒)。このタイムラインでは、ユーザが最初にページとやり取りしたのは5.5秒ごろで、これはFirst Interaction Time(またはIX Time)です。Long Taskがないため、ブラウザはユーザーの入力に8ミリ秒で応答でき、First Input Delay(青で表示)が発生します。

この例で示すように、これらのメトリック間の関係を調べることは、jankinessがユーザーに影響を与えているかどうか、そしてなぜ影響を与えているかを判断するための鍵となります。

上のタイムラインでは、First Interaction TimeはFirst CPU Idleの後であるため、First Input Delayが非常に高速であることは理にかなっています。CPUをブロックするものは何もないようです。しかし、通常、First Input Delayについてパフォーマンス担当者と話すときには、First Input DelayがどのようにLong taskによって妨害されているかに焦点を当てて説明しますが、First Interaction TimeがFirst CPU Idleよりも大きい場合はその限りではありません。したがって、サイトオーナーがFirst Input Delayが何を言っているかを理解するには、以下のことを知っておくことが重要です。

First CPU Idle後の最初の対話の頻度はどれくらい?

RUMを使用しているお客様の場合、最初の対話時間は、約66%の時間で最初のCPUアイドルが発生した後です。それを理解し、心に留めておくことが大切です。つまり、ほとんどの場合、 [First Input Delay] は [Long Task CPU] アクティビティの影響を受けません。

最初の対話が行われてからFirst CPU Idleが実行されるまでの時間の約3分の1。このシナリオを次の図に示します。この例では、最初のインタラクションはLong Task中に発生するため、ユーザはそのLong Taskが完了するまで待ってからインタラクションを処理する必要があります。このとき、First Input Delayの値が数百ミリ秒に跳ね上がります。

First CPU Idle前に最初のインタラクションが発生したときに、それがLong Taskとオーバーラップするとは限りません。上のタイムラインでは、ユーザ入力が [Long task] と衝突しない可能性が高く、その結果、 [First Input Delay] の値が速くなります。ただし、下のタイムラインの例では、多くの(少ない)Long taskがあるため、First Input Delayの値を大きくすると、より不自然になる可能性があります。Long taskによって消費されるCPU時間を理解することは重要です。

上のタイムラインには多くの [Long task] があり、 [First Input Delay] の値が大きくなっています。ただし、 「Long task」 は非常に少ないため、 「First Input Delay」 の値が数百ミリ秒を超えることはありません。下のタイムラインは別の話で、Long taskは二つしかありませんが、一つは1.5秒近くあります。(これは実際に起こったことがあります)最初のユーザ入力がこのLong taskと重なると、1000msを超えるFirst Input Delay値が表示され始めます。Long taskの期間を理解することが重要です。

最後にFirst Input Delayの注意すべき点は、レンダリングを考慮していないことです。これは大きな盲点です。一番上のタイムラインを見ると、おそらく、ユーザーがページと対話するのを5.5秒待つのは、重要なコンテンツのレンダリングに長い時間がかかったためだと思われます。この場合、レンダリングタイムが改善されると、Long taskと消費されたCPUの数が同じであっても、First Input Delayが悪化します。これは、レンダリングを改善することで、ユーザの操作が早くなり、以前は問題がなかったロングタスクとオーバーラップするからです。インタラクションタイムとレンダリングタイムに関連するFirst Input Delayを追跡することが重要です。

この最後の点は、Webパフォーマンスに注意することが難しい理由です。1つのメトリックに焦点を合わせることはできません。ユーザーエクスペリエンスに焦点を当てることが重要です。ユーザーエクスペリエンスに関しては、CPUとレンダリングが最も重要な指標です。幸いなことに、SpeedCurveのRUM製品であるLUXには、First CPU Idle、First Interaction Time、First Input Delay、Total CPU time、Long Tasksの数、Median Long Task、およびlongst Long Taskに加えて、多くのレンダリングメトリックが含まれています。LUXをまだ使用していない場合は、無料トライアルに登録してください。

これらの重要なポイントを覚えておいてください。

  • First Interaction TimeがFirst CPU Idle後にどれくらいの頻度で発生するかを把握します。
  • Long taskで消費されるCPUタイムの量を把握します。
  • 最も長いタスクを監視します。
  • [First Input Delay] インタラクションタイムとレンダリングに関連する遅延です。

ご質問やお問合せは、[email protected] までお願いします。

関連記事

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。