> For the complete documentation index, see [llms.txt](https://docs.nexthink.com/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexthink.com/platform/ja/user-guide/applications/monitoring-applications/monitoring-web-applications/performance/page-loads/troubleshooting-slow-page-loads.md). # ページ読み込みが遅い場合のトラブルシューティング **ページ読み込み**ダッシュボードは、柔軟性、機能、使いやすさを備えており、IT 担当者は問題のある領域を迅速に特定し、アプリケーション内の特定のページで問題が発生している可能性のある従業員に注力できます。 パフォーマンスしきい値を確認し、フィルターを設定して、遅いページ読み込みのトラブルシューティングを行います。アプリケーションごとにしきい値を設定することも、デフォルト設定を使用することもできます。詳細については、[しきい値](/platform/ja/user-guide/applications/setting-up-and-managing-applications/configuring-applications/configuring-web-applications/thresholds.md)のドキュメントを参照してください。 低速なページ読み込みをトラブルシューティングするには、さまざまなアプローチがあります： * まず、上部にある**平均ページ読み込み時間**メトリックと、その横にある**バックエンド**、**デバイスとアプリのネットワーク**、**クライアント**メトリックを評価します。デフォルトでは、これらのメトリックは、異なるページ間のすべてのナビゲーションを考慮したアプリケーション全体のパフォーマンスを示します。 * バックエンド時間が長い場合は、サーバーがリクエストの処理に長い時間を要していることを示します。これは、非効率的なサーバーサイドコード、不十分なサーバーハードウェア、またはリソース集約型の操作が原因である可能性があります。バックエンド時間が長い問題に対処するには、アプリケーション開発者がコードを最適化するか、サーバーハードウェアをアップグレードする必要がある場合があります。[ウォーターフォールメトリック](#troubleshoot-waterfallmetricstodiagnoseslowpageloadswaterfall_metrics)を使用して、XMLHttpRequest（XHR）のリソースタイミングを確認できます。計算時間が長い XHR は、サーバー呼び出しが遅いことを示しており、それに応じて最適化できます。 * ネットワーク時間が長い場合は、ネットワークの輻輳、低速なインターネット接続、大きなファイルサイズ、またはサーバーとクライアント間の地理的距離などの問題を示している可能性があります。これらの問題を切り分けるには、国、エンティティ、location.type、ISP、アダプターの種類、最大のリソース別にネットワーク時間を確認できます。 * クライアント時間が長い場合は、ページ要素のレンダリングが遅い、JavaScript 処理が過剰である、CSS スタイルが非効率的である、またはデバイスや OS が他のタスクを処理しているといった問題を示している可能性があります。これらの問題に対処するには、アプリケーション開発者が HTTP リクエスト数の削減、CSS および JavaScript ファイルの圧縮、ブラウザーキャッシュの活用によって、クライアントサイドコードを最適化する必要がある場合があります。 * 次に、ページ読み込み時間の経時変化を示すタイムラインを使用して、パフォーマンスの最近の変化を確認します。このグラフでは、**バックエンド**、**デバイスとアプリのネットワーク**、**クライアント**メトリックを切り替えて、経時的な推移を確認できます。下の**従業員**グラフを使用して、利用率の高低がページ読み込み時間のパフォーマンスに与える影響を特定します。 * 時間フィルターを調整して、パフォーマンスが特に低下している期間に焦点を当てます。これは、グラフの Zoom 機能または右上隅の期間ピッカーを使用して行えます。 * その後、**主要ページと URL**の内訳を評価できます。最新の SaaS アプリケーションでは、ページごとに異なるパフォーマンス特性があります。このセクションでは、お客様の環境で最もフラストレーションを引き起こしているページを強調表示します。この内訳には、追加のコンテキストを提供する5つの列が含まれています。他と比較して**フラストレーションを引き起こすページ読み込みの割合**が特に高いページを探します。 * これらのページをクリックして、ダッシュボードにフィルターを適用します。ページ上部のグラフがそれに応じて更新されます。次に、上記の手順に従って、ページがバックエンド、ネットワーク、またはクライアントの問題により遅いかどうかを特定します。 * 残りの内訳（**デバイス**、**場所**、**組織**、**技術**）を確認して、著しく低い Experience に寄与している他のディメンションを特定します。ブラウザー、オペレーティングシステム、場所、またはその他のオプションでデータをフィルタリングします。位置情報の設定について詳しくは、[位置情報の設定](/platform/ja/user-guide/administration/system-configuration/data-management/environment/product-configuration.md#productconfiguration-geolocationtab)のドキュメントを参照してください。 * ウィジェットの右上隅にあるアクションメニューオプションを使用すると、Investigations モジュールで遅いページ読み込みの調査を続行できます。 ## 遅いページ読み込みを診断するためのウォーターフォールメトリック Web アプリケーションをより詳細にトラブルシューティングするには、ウォーターフォール分析メトリックを使用します。これらのメトリックは、パフォーマンスのボトルネックの正確な原因を特定し、エラーが発生しやすい要素を識別し、Web アプリケーション内のリソース集約型コンポーネントを明らかにするのに役立ちます。ウォーターフォールメトリックは、**Web アプリケーションのトラブルシューティング**ライブラリダッシュボードの**リソース分析**タブで利用できます。
2024-05-27_13-32-42.png
詳細については、[Web Application Advanced Troubleshooting](https://docs.nexthink.com/library/web-application-advanced-troubleshooting)のドキュメントを参照してください。 ### Web リソースの新しいウォーターフォールメトリックの一覧 Nexthink Application Experience ブラウザー拡張機能は、[Performance Resource Timing](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Resource_timing) API を使用してこれらのメトリックを収集します。 | 名前 | NQL 構文 | 説明 | | ----------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | ナビゲーション中の最長リソース（名前、種類、サイズ、期間） |

•最長リソースURL

•最長リソースタイプ

•最長リソース読み込み時間

•最長リソースサイズ

| **最長リソース**とは、Web ページのレンダリングに必要なすべての要素のうち、読み込み時間が最も長かったリソースを指します。特定のリソースの読み込みに他のリソースよりも著しく長い時間がかかる場合、Web アプリケーション全体の読み込み速度に影響している可能性があります。 | | ナビゲーション中の最大リソース（名前、種類、サイズ、期間） |

•最大リソースURL

•最大リソースタイプ

•最大リソース読み込み時間

•最大リソースサイズ

| **最大リソース**とは、Web ページの読み込み時に完全に読み込まれたファイルサイズが最も大きいリソースを指します。ユーザーのブラウザーで大きなリソースをダウンロードしてレンダリングする必要がある場合、レイテンシーの増加やページ読み込み時間の低下につながる可能性があります。大きなリソースを分析すると、サイズを削減するために最適化または圧縮できるファイルを特定するのに役立ちます。 | | 接続先ドメイン数 | 接続先ドメイン |

接続先ドメイン数は、画像、スクリプト、スタイルシート、フォントなどのさまざまなリソースの取得元となる、一意のドメイン名の数を示します。

これらのドメインには、アプリケーション自体のドメインに加え、分析スクリプト、広告、コンテンツ配信ネットワーク（CDN）などのサードパーティーリソース用のドメインも含まれます。

接続先の一意のドメインはそれぞれ、ブラウザーがリソースを取得する必要がある別個のサーバーを表しており、ページ全体の読み込み時間に影響する可能性があります。

| | リソース数 | リソース数 | **リソース数**は、ナビゲーションイベント中に読み込まれた画像、スクリプト、スタイルシート、その他のファイルなどのリソースの合計数を示します。 Web ページのリソース数が多いほど、ブラウザーでの読み込みとレンダリングに時間がかかる可能性があります。リソース数を分析することで、Web アプリケーションのパフォーマンスを最適化する機会を特定できます。たとえば、CSS ファイルや JavaScript ファイルを最小化または結合したり、画像を圧縮したり、キャッシュ手法を使用してサーバーへのリクエスト数を減らしたりすることを検討できます。 | | 大きなリソース数 | 大規模リソース数 | **大規模リソース数**は、ナビゲーションイベント中に100KBを超える画像、スクリプト、スタイルシート、その他のファイルなどのリソースの数を示します。ユーザーのブラウザーで大きなリソースをダウンロードしてレンダリングする必要がある場合、レイテンシーの増加やページ読み込み時間の低下につながる可能性があります。大きなリソースを分析すると、サイズを削減するために最適化または圧縮できるファイルを特定するのに役立ちます。 | | リソースエラー数 | リソースエラー数 | **リソースエラー数**は、ナビゲーションイベント中に読み込みに失敗した、またはエラーが発生した画像、スクリプト、スタイルシート、その他のファイルなどのリソースの数を示します。リソースエラーは、Web アプリケーションに特定のファイルまたはアセットが存在しないことを示している可能性があります。これにより、リンク切れ、画像の欠落、またはスクリプトの機能不全が発生する可能性があります。 | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.nexthink.com/platform/ja/user-guide/applications/monitoring-applications/monitoring-web-applications/performance/page-loads/troubleshooting-slow-page-loads.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.