New Relicでユーザー・セントリックなメトリクスを用いたフロントエンドパフォーマンスの監視をしよう!

元記事:https://blog.newrelic.com/product-news/monitor-frontend-performance-with-user-centric-performance-metrics/

現代のウェブページはこれまでにないほど動的であり、サイトのパフォーマンスとエンドユーザーの体験を理解するためには、サーバーサイドのアクセスログだけでは事足りなくなっています。ユーザー中心のパフォーマンス指標は、デジタル顧客体験を積極的に測定し、ベンチマークを行い、改善したいフロントエンド開発チームにとって非常に重要です。ウェブサイトの開発者であれば、ビジュアル要素だけに集中できないことを知っているはずです。顧客は、サイトにアクセスしたときに、魅力的で反応の良い体験を求めています。「パフォーマンス」は顧客体験を把握するために非常に重要な要素です。

従来、ページのロード時間(歴史的には window.onload イベントによって測定されてきました)を測定・監視されてきましたが、近年のサイトを監視する上ではあまり効果的ではありません。「ユーザーが応答を認知するまでのパフォーマンス」を特定するメトリクスは、顧客体験を明らかにし、ページの読み込み速度を理解するのに役立ちますが、気になるのは速度だけではありません。一方で、インタラクティブ・メトリクスは、ページが「使える」ようになったタイミングを測定するのに役立ちます。firstPaintやfirstContentfulPaintのようなペイント・メトリクスが、ユーザーがページ上で何かを「感じた」ことを教えてくれるのに対し、インタラクティブ・メトリクスは、エンドユーザーがページを操作できるようになったタイミングを教えてくれます。

*以下画面描画のためのパフォーマンスメトリクスを、ペイント・メトリクス、ユーザーの操作における体感時間を把握するためのメトリクスを、インタラクティブ・メトリクスと呼ぶことにします。

さらに、インタラクティブ・メトリクスは、顧客体験の測定と改善に役立ちます。

  • サイトが視覚的なコンテンツをレンダリングした後、ユーザーがどれだけ速くそのコンテンツを操作できるか。
  • コンテンツを操作した後、ユーザーがどれだけ速く反応を得るか
  • サイトのコードレベルの要素が、デバイスの種類、ブラウザ、ブラウザのバージョンを超えてユーザーの操作にどのように影響するか

PageViewTiming イベントで、ペイント・メトリクスとインタラクティブ・メトリクスを確認しましょう

firstPaint と firstContentfulPaint のメトリクスは、ユーザーがサイトの使用準備ができたと認識したときの情報を提供しますが、多くの場合、window.onload イベントよりも遅いことがわかりました。つまり、「従来のページロード」時間では、ページ上に視覚的なコンテンツがあることさえ保証されていないということです。

New Relicでは、顧客体験を向上させるために、ウェブページが使用可能になるまでの時間を測定する3つの「インタラクティブ・メトリクス」を利用できます。

  • firstInteraction
  • firstInputDelay (FID)
  • longRunningTasksCount

そして、firstInteractionとfirstInputDelayに加えて、firstPaintとfirstContentfulPaintも、PageViewTimingイベントを使用して問い合わせることができます。

firstPaintのタイミングでPageViewTimingイベントが送られます。その時にFIDとfirstInteractionも一緒に報告されます。

注意: PageViewTimingには、インタラクティブ・メトリクスはすべてのブラウザタイプで収集できますが、firstPaintとfirstContentfulPaintはGoogle Chromeに限定されています。”firstPaint”及び”firstContentfulPaint”について他のブラウザの情報を確認する場合は、PageViewイベントをご利用ください。

どんな指標見れば良いのか、コピー&ペーストで利用できる、クエリ(NRQL)もご用意しています。New Relicのダッシュボードでぜひご活用ください。

firstInteraction メトリクスを使ってみよう

firstInteraction メトリクスを使用すると、ポインタダウン、クリック、タッチスタート、またはキーダウンなど、ユーザーが初めてサイトで操作した瞬間を確認できます。
firstPaint および firstContentfulPaint メトリクスとともに、firstInteraction メトリクスも、「顧客がサイトを使用する準備ができたと」考える時点を理解するのに役立ちます。

それでは、firstInteractionを確認するためのクエリ例をご覧ください。

例 : インタラクションタイプ別にfirstInteractionを確認する ~ パフォーマンスの高い(低い)インタラクションを見極める

From PageViewTiming select percentile(firstInteraction, 50) since 30 minutes ago timeseries facet interactionType

例 : firstInteractionをfirstPaintとfirstContentfulPaintと比較 ~ コンテンツがページ上に表示された後、ユーザーがどのくらいの時間でエンゲージメントを開始するかを判断するためのパターンを見つけます。

From PageViewTiming select percentile(firstContentfulPaint, 50), percentile(firstPaint, 50), percentile(firstInteraction, 50) since 2 days ago timeseries

firstInputDelay (FID) メトリクスを使ってみよう

多くの場合、開発者はイベント(ボタンクリックなど)の直後にコードが実行されることを想定しています。しかしながら、ブラウザのメインスレッドが他のタスクを完了するために忙しくサーバに応答できないため、Web ページはインタラクションの後に遅延が発生します。たとえば、web.devで説明されているように、アプリが大きなJavaScriptファイルをロードすると、JavaScriptが他の処理をしないようにブラウザに指示するため、この場合ユーザーはラグがあると感じてしまいます。

このことを考慮して、firstInputDelay(FID) メトリックは、ユーザーが最初にサイトを操作した時(firstInteraction)からサイトが応答するまでの時間(言い換えれば、メインスレッドが空いているとき)を測定します。

FIDを短くするには、ページ全体で読み込みの遅い要素があるかどうかを確認してください。場合によっては、ページ上での要素の読み込み順序を変更するだけでFIDを削減できることもあります。例えば、大きな画像やサードパーティーのコンポーネントを最後に読み込むなどです。

それでは、firstInputDelay(FID) を確認するためのクエリ例をご覧ください。

例 : インタラクションタイプ別にfirstInputDelayを確認する – パフォーマンスの高い(低い)インタラクションを見極める

From PageViewTiming select percentile(firstInputDelay, 50)/1000 since 1 day ago timeseries facet interactionType

例 : ブラウザ/バージョンごとのfirstInputDelay中央値比較 ~ ブラウザの種類でどれだけ違うのかを確認する

From PageViewTiming select percentile(firstInputDelay, 50)/1000 since 1 day ago timeseries facet userAgentName, userAgentVersion

longRunningTasksCountsメトリクスの使用

Google Chrome のソフトウェア エンジニアである Shubbie Panicker 氏によると、”今日のウェブの応答性の問題の大部分は長時間のタスクが原因であり、長時間のタスクの原因としてはスクリプトが圧倒的に多い” とのことです。”ロング ランニング タスク”とは、完了までに 50 ミリ秒以上かかるタスクのことです。ブラウザのメインスレッドはタスクを1つずつ実行するため、ユーザーのクリックに対するページの応答が、たとえば実行待ちの JavaScript によってブロックされてしまうことがあります。これもまた、ユーザーがラグとして体験することになります。

longRunningTasksCounts を使用して、ページの読み込みパフォーマンスを向上させるために最適化できるオブジェクトを特定します。これらのタスクがサイトコンテンツの読み込み前に発生している場合は、まずそれらのプロセスを改善することから始めましょう。

longRunningTasksCountはSyntheticsで見つけることができ、ページごとに発生したインスタンスの数で追跡されます。これらは、firstPaintとfirstContentfulPaintのペイント・メトリクスと一緒にSyntheticsで計測されています。

この、longRunningTasksCountもクエリ例を用意していますので、ご覧ください。

例 : どれだけの量のロングランニングタスクがあるかページURLごとに確認する

FROM SyntheticRequest SELECT count(longRunningTasksCount) WHERE isNavigationRoot IS TRUE FACET URL

操作性とユーザー体感を測るパフォーマンスメトリクスの3つの使い方

結局のところ、ユーザーは皆様エンジニアがウェブサイトのパフォーマンスに注力していることを願っています。
ページに背景やコンテンツが表示されるタイミング、ユーザーがサイト上で操作できるようになるまでの遅延、そしてJavascriptのソースコードがブラウザのメインスレッドにどのように影響するか理解しチューニングしていくことまで、やるべきことはたくさんあります。

ここでは、ペイント・メトリクス、インタラクティブ・メトリクスの3つの使い方についてご紹介いたします。

1. ユーザー体験を改善しましょう

画面描画のためのペイント・メトリクスのパフォーマンス指標と大規模なビジネスKPIに相関があるかを把握するためのダッシュボードを作成します。ページのコンテンツ表示の速さやページビューの量とビジネスKPIとの間に直接的な相関があるかを確認します。このような顧客中心の体験をベンチマークし、それらの測定値を使用して、より長期的なウェブページ最適化プロジェクトを計画しましょう。

2. デプロイする前にステージング環境でパフォーマンス課題を排除し、本番環境でその課題をモニタリングしましょう

ステージング環境でSyntheticsを利用し、新しいコードがユーザーに悪影響を与えないようチューニングを行いましょう。

  • パフォーマンスバジェットを意識してソースコードを書きましょう
  • Syntheticsで開発環境においてテストシナリオを実行し、デプロイ前に問題を排除しましょう
  • コードデプロイ後は、アラート及びテレメトリデータ(活用できる全てのデータ)を使ってリグレッションしていないか即座に特定しましょう
  • 本番環境で「リアルユーザーモニタリング」を実施し、地理・デバイス・ネットワークなど全体を通して顧客体験を測定しましょう

3. 競合他社とのベンチマークを実施する

可能であれば、Web開発チームにリソースを割り当てて、ページ速度の最適化を強化しましょう。
競合と比較して今の立ち位置がどうなっているのかを把握しましょう。そしてできれば20%パフォーマンス改善をすることを目標としていただければと思います。

NewRelicソリューションコンサルタント。ERPパッケージベンダーにてSaaS製品を開発。SREも担当し運用自動化に励む。その後総合系コンサルティングファームに転職し、BtoCサービスの構築支援としてモバイルアプリを主としたサービスの開発リーダーを担当。 アーキテクチャの設計からCICD、バックエンド・フロントエンド開発という全領域の開発に加え、SREで経験した運用も踏まえたアプリケーションを中心としたパフォーマンス管理・チューニングを得意とする。 業務上経験が多いのはJava、Javascript。 View posts by .