速いことは良いことだと、誰もが知っています。実際にさまざまな調査で、エラーが少なく応答が速いほど利用率、コンバージョン率、収益が向上することが明らかになっています。そして多くの組織が、ビジネス指標を改善するためにカスタマーエクスペリエンスを向上させる即効薬的な方法をデジタルテクノロジーに求めています。しかし、適切な計画と準備がなければ間違いなく失敗に終わるでしょう。この記事では、パフォーマンスの成熟曲線について説明し、パフォーマンスとビジネスを持続可能な方法で体系的に向上させるための対策を成熟度別に紹介します。
成熟曲線が存在する理由
Webパフォーマンスの最適化は、ユーザーと顧客のエクスペリエンスを最優先するための取り組みです。この取り組みはアップタイムを維持するという基本を超えて、取り組みの必要性を認識することから始まります。デジタルエクスペリエンス監視によってページパフォーマンスやエンドユーザーエクスペリエンスのベンチマークを確立し、最終的にはソフトウェア開発のリリースサイクルにパフォーマンス測定を組み込むことが目標です。段階を1つ進むごとに、技術面と体制面の両方で、前の段階をベースに成熟度を上げていく必要があります。たとえば以下のようなプロセスです。
- パフォーマンスの低さが組織の重要なビジネスフローに与える影響を把握するために、まず、主要なページの可用性を監視し、サービスレベル目標(SLO)を追跡します。
- 最適化の効果を把握するために、可用性だけでなく、コアウェブバイタルなどの重要なUXメトリクスも監視します。
- エンジニアリングチームに新機能の開発やバグ修正だけでなく最適化にも意識を向けてもらうために、ビジネスに対するパフォーマンス向上の価値を組織全体で共有します。
マズローの自己実現理論と同じように、技術面および体制面の成熟度を上げるには、段階を1つずつ上っていく必要があります。
では、成熟曲線の各段階を詳しく見ていきましょう。
第1段階：リアクティブでアップタイム重視の対応
測定していないメトリクスは改善できません。また、詳細がわからない問題は解決できません。第1段階で重要なのは、パフォーマンスを包括的に監視して、サイトの可用性と安定性を基本レベルで可視化することです。この段階では、ビジネスサービスのSLAを達成することが最優先事項であり、カスタマーエクスペリエンスへの対応はリアクティブに行われ、通常はサポートチケットを受け取ってエスカレーションした後に行われます。
ITまたはSREチームが人的にも時間的にもリソース不足に陥っていることもよくあります。最近はどの組織のITチームやエンジニアリングチームも、大規模なクラウド移行やモダナイゼーションにかかりきりで、アップタイムに関するSLAは現状維持が精一杯です。また、デジタル化に向けてインフラやバックエンドサービスの刷新に取り組んでいる組織は、エンドユーザーエクスペリエンスのベンチマークと測定が簡単にできることに気付いていない場合もあります。この傾向は、アーキテクチャのモダナイズの初期段階にある組織によく見られます。チームが縦割りで、ユーザーエクスペリエンスをより大きな視点で捉える時間的、技術的余裕がないことが原因です。 個々のページやAPIの一般的なアップタイムとパフォーマンスは測定しているかもしれませんが、顧客満足度を包括的に監視できていません。
APMソリューションではユーザーエクスペリエンスを十分に定量化できないことがある
対策：
- すべての重要なサービス(Webサイト、アプリケーション、APIなど)のインベントリを作成します。
- 合成モニタリングによってサービスの可用性を監視し、障害発生時にすばやく対応できるようにアラートを設定します。
- サービスの可用性や傾向をビジネスチームに伝えるためのダッシュボードとレポートを作成します。
第2段階：ベンチマークの確立と傾向の把握
サービスの可用性が高いからといってユーザーエクスペリエンスが優れているとは限りません。成熟曲線の第2段階では、まず、サービスの遅延はサービスの停止と同じくらい問題であることを理解する必要があります。そして、アップタイム重視のリアクティブなアプローチを脱して、Google社のコアウェブバイタルのような、業界で研究されている詳細な測定基準を活用したユーザー重視のアプローチに移行する必要があります。ウェブバイタルは最新のリアルユーザー監視ソリューションや合成モニタリングソリューションで標準となっているため、これらのソリューションを導入すれば、アップタイムとともにユーザーエクスペリエンスを測定し、ページのパフォーマンスが低下したときにアラートを生成できます。
対策：
- 重要なページとサービスに関するパフォーマンスメトリクスを監視し、エクスペリエンスが低下したときにアラートを生成します。
- 個々のページとともに主要なビジネスフローとトランザクションを監視します。
- ユーザーの全体的な傾向を測定します。
- 合成モニタリングやリアルユーザー監視ソリューションで収集したラボデータとフィールドデータを使用してパフォーマンス改善の効果を測定します。
次に、各対策について詳しく説明しましょう。
パフォーマンスメトリクスの監視
重要なページやサービスについて、ユーザーエクスペリエンスのベースラインとなる測定基準を確立します。従来のページ読み込み時間の代わりにGoogle社のコアウェブバイタルを使用すれば、LCP (最も大きいコンテンツが表示されるまでの時間)、FID (最初のユーザー操作に対する反応時間)、CLS (レイアウトのずれの累積量)を測定して、ページのエンドユーザーエクスペリエンスをより正確に把握できます。これら3つのメトリクスは、ページコンテンツの表示速度、ページ読み込み後のユーザー操作に対する反応速度、ページの表示の安定性を定量化するために役立ちます。ユーザーエクスペリエンスを定量化してより正確に測定できれば、数値や傾向を分析して、SLOに合わせてデジタルエクスペリエンスを効果的に最適化できます。
ビジネストランザクションの監視
ホームページや商品ページなどの個々のページも重要ですが、多くの場合はユーザーのログインフロー、ユーザー認証、チェックアウト処理などのビジネストランザクションにも複雑な依存関係があり、注視する必要があります。最近のWebページでは、データの取得やサービス内でのページ遷移に複数のAPIやサードパーティサービスが使用されています。ビジネストランザクションを監視すれば、個々のページを監視するだけでは発見できない、トランザクション内のデータフローで発生する可用性やパフォーマンスの問題を検出できます。また、合成モニタリングを導入すれば、ユーザーの行動をシミュレートして、ページのパフォーマンスと機能を測定できます。
ビジネストランザクションに含まれる複数のページをシミュレートおよび測定する例
ユーザーの傾向の把握
ユーザー全体のパフォーマンスの傾向を把握するには、ディメンションデータ(位置情報、ブラウザ、接続タイプなど)を使ってトラフィックをグループ分けしてから、パーセンタイルに基づいてパフォーマンスを測定します。パーセンタイルは、大多数のエンドユーザーが実際に経験しているページパフォーマンスを把握するために役立ちます。たとえば75パーセンタイルの値を調べれば、異常な遅延による過度な影響を除外したページパフォーマンスやユーザーエクスペリエンスがわかります。ディメンションデータでは、サイト内を移動するユーザーの特徴を把握できます。このデータを収集することで、より多くのインサイトを取得し、ユーザーエクスペリエンスをより正確に測定できます。
パフォーマンス最適化の効果の測定
第2段階でパフォーマンスとユーザーエクスペリエンスを定量化したら、ベンチマークとベースラインを確立します。これにより、ITチームやエンジニアリングチームは、各種のパフォーマンス最適化がアプリケーションのKPIにどのような効果をもたらすかを測定できます。 たとえば、CDNの導入やJavaScriptの読み込みコードのリファクタリングでパフォーマンスが改善したかどうかを確認できます。
第3段階：リリース条件へのパフォーマンスとUXの追加
第3段階では、パフォーマンスとUXがビジネスに直接影響を及ぼすという認識を組織全体で共有します。 これにより、確立したベースラインやベンチマークに基づく主要なページやビジネストランザクションのパフォーマンスデータを開発プロセスで活用して、変更によるパフォーマンスの低下を防ぐだけでなく向上させることができます。
対策：
- パフォーマンスとユーザーエクスペリエンスに関するメトリクスをリリース条件に追加します。
- A/Bテストを実施して変更(新しい機能やコードの追加など)がパフォーマンスに与える影響を測定します。
- パフォーマンスやユーザーエクスペリエンスとともにビジネス成果を測定します。
デプロイプロセスとDevOpsプロセスにパフォーマンスを組み込む例
リリース条件へのパフォーマンスとユーザーエクスペリエンスの追加
今日、多くの組織で自動化が重要かつ大きな役割を果たす中、CI/CDプラクティスにパフォーマンス要件を組み込むことは、開発ライフサイクルの初期段階でパフォーマンスの問題を特定および解決するために有効です。パフォーマンスバジェットに合意したフロントエンドの開発チームまたはエンジニアリングチームは、ページの重さ、画像やスクリプトのサイズ、外部リソースの総数など、特定のページ条件に基づいてビルドの合否を自動判定できます。
A/Bテストによる変更の影響の測定
エンジニアリングチームは、新しいデプロイをプッシュする前に、コード、機能、サービスの追加や改善がもたらす影響を、前のビルドやバージョンとの比較によって測定できます。A/Bテストと合成モニタリングによって、新しいコードがパフォーマンスにもたらす影響をページごとに確認し、本番環境にプッシュする前に問題を検出できます。合成モニタリングとリアルユーザー監視を組み合わせてA/Bテストを行えば、高速ネットワークでの最適条件を、実際のユーザーエクスペリエンスを基準に評価できます。
パフォーマンスおよびUXとビジネス成果の同時測定
デジタルエクスペリエンス監視ソリューションのビジネス面での大きな目標は、Webパフォーマンスとビジネス成果を相関付けることです。ページの速度やユーザーエクスペリエンスを収益、コンバージョン率、利用率と正確に相関付けることは容易ではありませんが、パフォーマンスとビジネス成果の両方を測定すれば、エンジニアリングチーム、ITチーム、デジタルビジネスチームのリーダーにとって有用なインサイトや方向性を得ることができます。最近では、Google社のコアウェブバイタルをユーザーエクスペリエンスのベースラインとして採用する組織が増えています。さらに進んだ組織では、「スピードチーム」や「センターオブエクセレンス」を設置してユーザージャーニー全体のページパフォーマンスをベンチマークし、業界標準や競合他社と比較してデプロイを継続的に改善しています。
Webパフォーマンス改善のための組織レベルでの取り組み
時間とリソースに制約のあるITチームやエンジニアリングチームにとって、パフォーマンスのベストプラクティスを確立することは負担に感じるかもしれません。しかし、ユーザーエクスペリエンスのベースラインの設定、コアウェブバイタルの標準化、機能の追加や改善がパフォーマンスに与える影響の監視といったシンプルなステップを取り入れるだけで、ユーザー離れの防止、利用率の向上、収益の向上につなげることができるのです。
パフォーマンス成熟度の次の段階に進む準備はできていますか？Splunk Synthetic Monitoringの無料トライアルをぜひお試しください。
その他のリソース：
