ラボ
この手順は、New Relic ブラウザー監視を使用して Web アプリをトラブルシューティングする方法を説明するラボの一部です。
ラボの各手順は最後の手順に基づいているため、この手順を開始する前に、最後の手順 であるアプリケーションのエラーをデバッグするを完了していることを確認してください。
アプリケーションの JavaScript エラーを修正した後、あなたとあなたのチームは自信を持っています。ダウンタイムの準備ができて、ソーシャル メディアに向かいますが、Twitter をチェックすると、混乱している顧客が何人かいます。
ええとああ!あなたの顧客は幸せそうに見えません。New Relic ブラウザー監視を使用して、遅延の原因を発見する時が来ました。
アプリケーションのデバッグの遅さ
New Relic ホームページから Browser に移動し、 Relicstaurants アプリケーションを選択します。
ここには、ブラウザ アプリケーションに関連するすべてのデータが表示されます。これには、 JavaScript エラーのあるページ ビュー、 主要なウェブ バイタル、 サイトでのユーザー時間、 最初のページの読み込みとルートの変更などがあります。
Largest Contentful Paint (LCP)に注目してください。
Largest Contentful Paint (LCP) は、Web ページのメイン コンテンツが読み込まれる速度を表します。理想的には、コンテンツの読み込みに 1 ~ 2 秒以上かかるべきではありません。ここでは、サイトの読み込みに 5 秒以上かかっていることがわかります。ユーザーが文句を言うのも不思議ではありません!
しかし、この遅延の原因は何ですか?バックエンド?
下にスクロールして、 Front end vs. back end[フロント エンドとバック エンドの] グラフを確認します。
Back end (time to first byte) (50%) をクリックしてグラフをフィルタリングし、バックエンドの読み込みにかかる時間を確認します。
このグラフは、最悪の場合、バックエンドがリクエストを処理するのに最大 140 ミリ秒かかったことを示しています。これは、フロントエンドが遅延を引き起こしているということですか?
Front end (Window load + AJAX) (50%)[フロント エンド (ウィンドウ ロード + AJAX) (50%)]をクリックします。
そこで問題です!グラフは、遅延がフロントエンドで発生していることを示しています。
フロント エンドでのデラットの原因を絞り込むには、 Initial page load and route change[初期ページ ロードとルート変更] グラフを詳しく見てください。
Initial page load (Window load + AJAX)[初期ページの読み込み (ウィンドウの読み込み + AJAX)]をクリックします。
グラフは 、Initial page load (Window load + AJAX)[最初のページの読み込み (ウィンドウの読み込み + AJAX)] に 5 ~ 6 秒かかっていることを示しており、これは驚くべきことです。
詳細を表示するには 、Initial page load and route change[最初のページの読み込みとルートの変更] をクリックします。
これにより、 Page views[ページ ビュー]が表示されます。
最も時間がかかるでページを並べ替えます。
最初のページの読み込みに約 90% の時間がかかっていることに注意してください。
それをクリックして詳細を表示します。
このページには、 Page view breakdown[ページ ビューの内訳]、 Median initial page load time[初期ページ読み込み時間の中央値]、およびその他の重要な詳細が表示されます。Page view breakdown[ページビューの内訳] グラフは、ページに時間がかかっている理由と場所を絞り込むのに役立つため、ここでは特に重要です。このグラフをよく見ると、 Page rendering[ページのレンダリングに] 5000 ミリ秒もかかっていることがわかります。
最初のページのレンダリングにかなりの時間がかかり、アプリケーションが遅くなることがわかりました。次に、 Session traces[セッション トレースを] 観察して、レンダリング プロセスを遅らせている原因を特定します。
右上隅の X をクリックして、このビューを終了します。
左側のナビゲーションから Session traces に移動し、それらを Page loadの降順で並べ替えます。
ここでは、 Page load[ページの読み込み] 時間順に並べ替えられたセッション トレースが表示されます。
リストから、最初のものをクリックします。
これにより、 Session traces[セッション トレースの] 詳細ページが表示されます。
ここに、その特定のセッションの完全なトレースが表示されます。このページには、 Backend、 Dom Processing、 Page Load、およびその他のトレース関連情報も表示されます。
Page load[ページの読み込みに] 予想よりも時間がかかっていることに注意してください。負荷の詳細なタイムラインが必要です。ポインターを左右にスクロールして、タイムラインを調整します。
トレースをスクロールしてタイム ウィンドウを移動し、このセッション中の個々のイベントの詳細を確認します。
特定のイベントに 5 秒以上かかっていることに注意してください。
イベントをクリックすると詳細が表示されます。
イメージですのでご了承ください。特に、読み込みに 5 ~ 6 秒かかり、遅延の原因となっているのはアプリケーションの背景画像です。
これらの調査結果に基づいて、背景画像がここでの犯人であるという仮説を立てます。高解像度で最適化されていない画像は、Web サイトの速度低下の最も一般的な原因です。朗報です!理由がわかったので、問題を解決できます。
概要
要約すると、アプリケーションの遅さを観察し、New Relic ブラウザ監視を使用して次のことを行いました。
- サイトの主要なウェブ バイタルを観察する
- 速度低下の原因を絞り込む
宿題
素晴らしい!モニタリングをすぐに開始できるようになったので、ジャーニーの次のステップに進むのに役立つドキュメントをいくつか紹介します。