• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は参考用に提供されます。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、 を参照してください。

問題を作成する

ラボ パート 4: アプリケーションのフロントエンドの速度低下をデバッグする

ラボ

この手順は、New Relic を使用して Web アプリのトラブルシューティングを行う方法を説明するラボの一部です。

ラボの各手順は最後の手順に基づいているため、この手順を開始する前に、最後の手順 であるアプリケーションのエラーをデバッグするを完了していることを確認してください。

アプリケーションの JavaScript エラーを修正した後、あなたとあなたのチームは自信を持っています。ダウンタイムの準備ができて、ソーシャル メディアに向かいますが、Twitter をチェックすると、混乱している顧客が何人かいます。

ええとああ!あなたの顧客は幸せそうに見えません。New Relic ブラウザー監視を使用して、遅延の原因を発見する時が来ました。

重要

New Relic でデータを表示するには、この手順でブラウザーの監視を有効にする必要があります。

まだ行っていない場合は、 ブラウザ エージェントを使用してアプリをインストルメント化します

アプリケーションのデバッグの遅さ

New Relic ホームページからBrowserに移動し、 Relicstaurantsアプリケーションを選択します。

ここには、Page views with JavaScript errorsCore web vitalsUser time on the siteInitial page load and route changes などを含む、 browserアプリケーションに関連するすべてのデータが表示されます。

largest contentful paint (LCP)に注目してください。

最大コンテンツフル ペイント (LCP) は、Web ページのメイン コンテンツが読み込まれる速度を表します。 理想的には、コンテンツの読み込みに 1 ~ 2 秒以上かかることはありません。 ここでは、サイトの読み込みに 5 秒以上かかっていることがわかります。 ユーザーが不満を言うのも不思議ではありません。

しかし、この遅延の原因は何ですか?バックエンド?

下にスクロールして、 Front end vs. back endグラフに注目してください。

Back end (time to first byte) (50%)をクリックしてグラフをフィルタリングし、バックエンドの読み込みにかかる時間を確認します。

このグラフは、最悪の場合、バックエンドがリクエストを処理するのに最大 140 ミリ秒かかったことを示しています。これは、フロントエンドが遅延を引き起こしているということですか?

Front end (Window load + AJAX) (50%)をクリックします。

そこで問題です!グラフは、遅延がフロントエンドで発生していることを示しています。

フロントエンドでの遅延の原因を絞り込むには、 Initial page load and route changeグラフを詳しく見てください。

Initial page load (Window load + AJAX)をクリックします。

グラフは、 Initial page load (Window load + AJAX)に 5 ~ 6 秒かかっていることを示しており、これは憂慮すべきことです。

詳細を表示するには、 Initial page load and route changeをクリックしてください。

これにより、 Page viewsに移動します。

ページをMost time-consumingで並べ替えます。

最初のページの読み込みに約 90% の時間がかかっていることに注意してください。

それをクリックして詳細を表示します。

このページには、 Page view breakdownMedian initial page load time 、およびその他の重要な詳細が表示されます。 Page view breakdownグラフは、ページに時間がかかる理由と場所を絞り込むのに役立つため、ここでは特に重要です。 このグラフを詳しく見ると、 Page rendering 5000 ミリ秒もの時間がかかっていることがわかります。

最初のページのレンダリングにかなりの時間がかかり、アプリケーションが遅くなっていることがわかりました。 次に、 Session tracesを観察して、レンダリング プロセスを遅らせている原因を特定します。

右上隅にあるXをクリックして、このビューを終了します。

左側のナビゲーションからSession tracesに移動し、 Page loadの降順に並べ替えます。

ここでは、セッショントレースがPage load時間の順に並べ替えられていることがわかります。

リストから、最初のものをクリックします。

これにより、 Session tracesの詳細ページが表示されます。

ここでは、その特定のセッションの完全なトレースが表示されます。 このページには、 BackendDom ProcessingPage Load 、およびその他のトレース関連情報も表示されます。

Page loadには予想より時間がかかっていることに注意してください。 負荷の詳細なタイムラインが必要です。 ポインタを左右にスクロールしてタイムラインを調整します。

トレースをスクロールしてタイム ウィンドウを移動し、このセッション中の個々のイベントの詳細を確認します。

特定のイベントに 5 秒以上かかっていることに注意してください。

イベントをクリックすると詳細が表示されます。

イメージですのでご了承ください。特に、読み込みに 5 ~ 6 秒かかり、遅延の原因となっているのはアプリケーションの背景画像です。

これらの調査結果に基づいて、背景画像がここでの犯人であるという仮説を立てます。高解像度で最適化されていない画像は、Web サイトの速度低下の最も一般的な原因です。朗報です!理由がわかったので、問題を解決できます。

概要

要約すると、アプリケーションの遅さを観察し、New Relic ブラウザ監視を使用して次のことを行いました。

  1. サイトの主要なウェブ バイタルを観察する
  2. 速度低下の原因を絞り込む

宿題

素晴らしい!モニタリングをすぐに開始できるようになったので、ジャーニーの次のステップに進むのに役立つドキュメントをいくつか紹介します。

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.