本記事は「Passionate about UX? Pay attention to web performance metrics」の抄訳です。
ユーザー体験・ユーザーエクスペリエンス(UX)の文脈において、デザインの要素ではないブラウザ描画速度や応答性能などのパフォーマンスは、UXの構成要素から見落とされがちです。
Paul Boag氏などのUXの専門家でさえ、開発チームが担当するアプリケーションがパフォーマンスに直接影響を与えるため、時にはUXチームよりもUXに大きな影響を与えることがあると認めています。
革新的で直感的な素晴らしいビジュアルをもつサイトでも描画が遅い、エラーが発生しやすい、あるいはそもそも通信に失敗しユーザーがアクセスできなかったりすれば、ユーザーの関心を集めることはできないでしょう。
つまり開発エンジニアはUXに影響を与える強い能力を持っています、その能力を良いことに使いましょう！
WebアプリケーションのUXが良い状態であるかを測定するには、アプリケーションの死活やエラーだけに注目する古典的なアプローチを超える必要があります。
UXチームが創り上げたWebサイトのデザインとナビゲーション、それが最大限効果を発揮するためにはユーザーのパフォーマンス体験を知る必要があります。
パフォーマンス体験は、定量的な測定方法がわかれば最適化することができます。New RelicのSyntheticsとBrowserを使用している場合、必要なデータはすでにすべて揃っています。
1. 開発者観点でのパフォーマンス
週次で、例えば毎週月曜日にパフォーマンス状況を確認しましょう。
New Relic の Browser UIにあるSummaryページでWebサイトがどのような動作をしていたのか確認する事ができます。 例として上の画像ではパフォーマンスやスループットの急激な変化はなく全て順調だったようです。Core web vitals におけるLargest Contentful Paint (LCP)が警告である黄色で強調されています。ただこの警告は中央のUser-centric page load timesグラフから急激な悪化ではなく定常的にそういう状況であった事が読み取れます。常態化して悪い状態ということは改善の余地があるかもしれません、後で開発チームと相談してみましょう。
2. UX観点でのパフォーマンス
次に同じアプリケーションを別の視点から見てみましょう。デジタルカスタマー体験に影響を与える４つの大切な要素を表現したダッシュボード - Quality foundation dashboard -を使います。４つの要素とは：
- Availability - 可用性 （サービスに接続できるかどうか）
- Performance - パフォーマンス（利用に耐える程度のパフォーマンスが出ているか）
- Content quality - コンテンツ品質（ユーザーが必要としているものが存在し、見つけられているか）
- Product and content relevance - プロダクトとコンテンツの関連性（ユーザーが求めているものを提示できているか）
です。
Quality foundation dashboardでは多くの部分でGoogleが定義したページ表示のUX指標であるCore web vitalsに焦点をあてています。
本記事ではユーザーが最初にページを呼び出してから、画像やコンテンツのブロックなど最も大きな描画要素が描画されるまでの時間を測定するLargest Contentful Paint (LCP)に着目します。
大丈夫です、アプリケーション全体のパフォーマンスを見る、という思想に変わりはありません。ただユーザーの体験をよく理解できるLCPという指標に絞り込んでいるだけです。この指標をモバイル（スマートフォン上のWeb）とデスクトップ（PCやMacのブラウザ）に分けているのにも理由があります、LCPの指標が大きく異なってくるからです。
下がQuality foundation dashboardの例です。
このダッシュボードを見る限り、サーバーの初期応答（TTFB）とレスポンスのエラー率（4xx Responces）に改善の余地がみられます。しかし最も注目すべき、そして実用的なデータはLCPあたりにあります。
Googleの指標によればLCPは2.5秒以内に収めることが良いUXのためには理想的、2.5〜4.0秒であれば許容範囲、そして4.0秒以上は悪い体験であるとされています。
上記の例ではデスクトップに限ったLCPは2.875秒で全体（2つ前の画像）の平均3.437秒に比べ優れていることがわかります。これは警告色になっていますがほぼ理想的な数値に近いです。しかしモバイルでのユーザー体験は、おそらく大変イライラするものでしょう。このデータによればモバイルでの読み込みはトラフィック全体の25%を占めています。その25%のユーザーにとってのLCP指標は真っ赤になってしまっています。これは、イライラしているユーザーの割合が高いということです。
ではなぜBrowserのUI（2つ前の画像）からこれを読み取ることができなかったのでしょうか。それは情報が「平均」に埋もれてしまったためです。
あなたのサイトのデスクトップとモバイルの利用状況を見ることはユーザーのパフォーマンスを分割し分析する方法の一つに過ぎません。デバイス種別、アクセス元地域や利用している端末、あなたのサービスにおけるユーザージャーニーごとにパフォーマンス指標を分割する方法もあります。
ここで重要なのはユーザーから見たパフォーマンスを理解するには、「UXの測定基準に焦点を当てて体験が変化する可能性がある箇所でデータを分割する必要がある」ことです。これについては次のセクションで詳しく説明します。
3.UX観点でのパフォーマンスをユーザージャーニーで見る
UXのメトリクスを分割する一つの方法は、アプリケーションの様々なパーツで分割することです。下の画面はユーザーがログインする際のアプリケーションパフォーマンスをダッシュボードで表現しています。
この画像で最も注目すべきはLCPのパフォーマンスです。ログイン画面においてデスクトップ環境でも4.25秒と遅く、モバイルにいたっては6.375秒ととても遅くなっています。
多くのサイトにとってログイン画面の表示回数は全体のページビューからするととても小さいです。ログイン画面の動作が遅くても全体を基準としたパフォーマンスの平均に影響を与えることはほぼ無く、したがって調査がされることもないでしょう。しかしユーザージャーニーにおいて必ず通る、最初の段階で離脱してしまうとビジネス観点を含めた「サイト・サービス全体のパフォーマンス」に大きな影響を与える可能性があることがおわかりいただけたかと思います。
アクセス頻度が低く重要なページはログイン画面以外にもあり、その多くは「ファネルの底」と呼ばれる場所にあります。ファネルの底とはユーザージャーニーにおける最後の箇所です、それ以上ユーザーはサイト内を移動しないので「底」です。そういった重要なページは例えば保険申し込みサイトの最終ページ、ECサイトにおける支払い確定画面、住所変更などを行うユーザー設定画面の変更確認ページなどがあります。
UXを観測・改善を行うためのTips
先ほどのデバイス別LCPで見たように、UXを観測する場合アプリケーション全体の平均値を見るだけでは不十分です。以下のTipsはユーザーのペインポイントを掘り下げて見つけるお役に立つでしょう。
- Core web vitals などのUXに直結するパフォーマンス指標に注目する
- パフォーマンス指標をデバイス、サービス機能、ユーザージャーニー別などで分割する
- ログイン画面や支払い完了画面など、ユーザージャーニー上UXに大きな影響を与えるが全体からするとページビューが少ない箇所を観測する
次のステップ
Core web vitalsについてより詳しく知りたい場合はこちらのblog記事や以下のサイトをご覧ください
デジタルカスタマー体験を向上させるにはNew Relicのドキュメントにある quality foundation implementation guide をご覧ください。New Relicの観測性を活用しユーザー体験を業界標準と比較し測定、より良いものにするための方法論を学べます。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
