もちろん、開発マシンでの Web サイト ページの読み込み時間は、パフォーマンスの大まかな指標にすぎません。本番環境に移行する際には、他にも多くの要因がありますが、それでも基準としては有用です。
開発中のページの読み込み時間はどのくらいを目標にしているのでしょうか。
実際のマシンに関しては、さまざまなパフォーマンスがある可能性があることを知っています。大まかな数値を探しているだけです。
ありがとう
サーバー側の問題を特定するために使用する最も有用なベンチマークの 1 つは、Web サーバー自体が要求を受信してから応答をフラッシュするまでの「内部」時間です。これは、ネットワーク トラフィック/レイテンシとページ レンダリング時間を無視することを意味します。
この時間を測定し、それを HTTP 応答ヘッダーに挿入するカスタム コンポーネント (.net) がいくつかあります (X-Server-Response というヘッダーを設定します)。自動テストツールを使用してこのデータを抽出できます。つまり、時間の経過とともに (および環境間で) 測定できます。
この時間を測定することで、生のアプリケーション パフォーマンスについてかなり信頼できるビューを得ることができます。また、レンダリングに時間がかかる低速のページがあり、HTTP 応答ヘッダーが 50 ミリ秒で作業を終了したと表示している場合は、ネットワーク /ブラウザの問題。
アプリケーションを本番環境にプッシュしたら、キャッシング、静的ファイルのサブドメイン、js/css のミニフィケーションなどを用意する必要があります。これらはすべて、大幅なパフォーマンスの向上 (特にキャッシング) を提供できますが、基盤となるものをマスクすることもできます。アプリケーションの問題 (何百もの db 呼び出しを行うページなど)。
つまり、今回使用する値は 1 秒未満です。
パフォーマンスに関してクライアントに提供するものに関しては、通常、読み取り専用ページには 2 ～ 3 秒、トランザクション ページ (登録、チェックアウト、アップロードなど) には最大 5 秒を使用します。
ひっかけ問題。
通常の Web アプリの場合、ページの読み込み時間が 5 秒を超えないようにする必要があります。しかし、次のことを忘れないでください。
したがって、私の意見では、単純な Web アプリ (たとえば、Spring/Tapestry を使用) の大まかな数値を取得するための簡単な方法を次に示します。
それが私の開発マシン上にある場合は、基本的にすぐに実行できると思います。ここでは数十ミリ秒の話をしています。もちろん、これは HTML を生成して配信するためのものです。
それとも、完全なページの読み込み/レンダリング時間 (html のダウンロード/解析/レンダリング、画像のダウンロード/表示、css のダウンロード/解析/レンダリング、javascript のダウンロード/実行、フラッシュのダウンロード/プラグインの起動/実行など) を意味しますか? ? 後者は、かなりの時間がクライアント マシンの Web ブラウザで消費されるため、定量化するのは非常に困難です。
ローカル ネットワーク上の非課税サーバーで適切なダウンロード + レンダリング時間を概算しようとしているだけの場合は、数秒間撮影します... 5 位以下です (クライアント マシンが適切であると仮定します)。