New RelicのBrowserエージェントによるリソースの追跡でページレンダリングのパフォーマンスを向上

Web開発者として充実した機能と視覚的に美しいアプリケーションを提供することに重点を置くことがよくあります。しかし、画像、スクリプト、スタイルシートなどのアセットがアプリケーション全体にどのように読み込まれるかといった、ユーザー体験に直接影響を与える目に見えない複雑なレイヤーがあります。これらがなぜ重要なのか説明するために実世界の例を共有させていただき、 PerformanceResourceTiming APIを活用することで隠れた問題を明らかにして実用的なインサイトを得る方法を説明します。

画像が欠落している場合

あなたは高品質な製品画像を使用して顧客に購入を促すECサイトを運営しているとします。開発中はすべてが順調に進んでいるように見えますが、製品画像が時々読み込まれないと顧客から不満が寄せられます。さらに悪いことに問題は一貫していないようです。問題を報告するユーザーもいれば、報告しないユーザーもいます。

調査したところ、特定の画像の読み込みに時間がかかりすぎていたり、完全には読み込めていないことがわかりました。アプリケーションとユーザーベース全体の個々のリソースのパフォーマンスを可視化できなければ、根本原因を特定することはほぼ不可能です。ここでPerformanceResourceTiming APIの出番です。

PerformanceResourceTiming APIの仕組み

PerformanceResourceTiming APIは、アプリケーションにリソースがどのように読み込まれるかについての詳細を提供します。ブラウザが画像やスクリプトなどのリソースを読み込むと、リストにエントリが作成されます。各エントリには、次のような詳細なメトリクスが含まれます。

• startTime：リソースの要求が開始されたとき
• fetchStart：ブラウザがリソースの取得を開始したとき
• responseEnd：リソースの読み込みが完了したとき
• duration：リソースの読み込みに要した合計時間
• transferSize：圧縮後のリソースのサイズ
• initiatorType：リソースの種類（ 「img」、「script」、「css」など）

他にも多くの分かりやすいタイミング値があります。このデータをローカルで確認するには、ブラウザの開発者コンソールに「performance.getEntriesByType('resource')」と入力します。

このデータを使用すると、リソースの読み込みにかかった時間、遅延が発生した場所、リソースがキャッシュされたかどうかを確認できます。データ属性の一般的な用途には次のようなものがあります。

• TCPハンドシェイク時間の計測（connectEnd - connectStart）
• DNSルックアップ時間の計測（domainLookupEnd - domainLookupStart）
• リダイレクト時間の計測（firstInterimResponseStart - finalResponseHeadersStart）
• 中間リクエスト時間の計測（firstInterimResponseStart - finalResponseHeadersStart）
• リクエスト時間の計測（responseStart - requestStart）
• TLSネゴシエーション時間の計測（requestStart - secureConnectionStart）
• フェッチ時間の計測（リダイレクトなし）（responseEnd - fetchStart）
• ServiceWorkerの処理時間の計測（fetchStart - workerStart）
• コンテンツが圧縮されているかどうかの確認（decodedBodySizeはencodedBodySizeであってはならない）
• ローカルキャッシュがヒットしたかどうかの確認（transferSizeは0でなければならない）
• 最新の高速プロトコルが使用されているかどうかの確認（nextHopProtocolはHTTP/2またはHTTP/3でなければならない）
• 正しいリソースがレンダリングブロックされているかどうかの確認（renderBlockingStatus）

すべてのユーザーのすべてのページにわたるパフォーマンスデータを集計

ここで、1ページだけでなくアプリケーション全体の全ページについてこのデータを収集できるとします。1人のユーザーだけでなく、すべてのページのすべてのユーザーに適用されます。PerformanceResourceTiming APIをNew Relicを統合すると、リソースタイミングメトリクスを大規模に集約できます。仕組みは次のとおりです。

1. ウェブアプリケーションにBrowserエージェントをインストールします 。
2. ページリソースのタイミングデータを自動収集するように、Browserエージェントを設定できます。方法はこちらをご覧ください。ウェブアプリケーションのすべてのページでNew Relic Browserエージェントを実行すると、ページリソースのタイミングデータが「BrowserPerformance」イベントとして自動的に収集されます。
3. one.newrelic.comのブラウザエンティティにアクセスして、インサイトを可視化します。実用的なライブデータを使用して、平均読み込み時間、失敗したリクエスト、転送サイズなどのメトリクスを可視化します。

BrowserPerformanceイベントに関連付けられた地理データとユーザーデータを利用し、アプリケーション全体ですべてのエンドユーザーのデータを集約することで、他の方法では気づかなかった問題を発見できるようになります。

問題の解決

元の例に戻ると、New RelicのBrowserPerformanceイベントデータを活用することで、すべてのユーザーに対して特定の画像セットの読み込みに時間がかかっていることがわかります。リダイレクト時間を確認すると、このセット内のすべての画像でリダイレクトの遅延が発生しています。エンジニアリングチームと協力して、無効なアセットパスをリダイレクトを必要としない直接パスに置き換えます。

リダイレクトの問題に対処した後でも、データを再確認すると、特に東南アジアのユーザーに対して、CDNでホストされている画像の読み込みが大幅に遅くなっています。startTimeとresponseEndメトリクスを分析すると、CDNのエッジサーバーとユーザーの場所の間のネットワーク遅延に問題があることがわかります。このデータを利用し、CDNプロバイダーと協力してその地域でより近いエッジノードを有効にします。