「サイトの速度低下」を定量化しようとしています。昔は、HTMLが軽量で、画像が最適化され、サーバーが過負荷にならないことを確認していました。最新のコンテンツ管理システムの上に構築されたハイエンドサイトには、さらに多くの変数があります：サードパーティの広告、トラッカー、その他のさまざまなコールアウト、CDNのパフォーマンス（興味深いことに、コンテンツ配信ネットワークが事態を悪化させることがあります）、javascriptの実行、cssの過負荷、および長いクエリなどのあらゆる種類のサーバー側の問題。
明らかな答えは、すべての開発者がキャッシュをクリアし、Firebugプラグインの「ネット」セクションを継続的に確認することです。「サイトドラッグのお尻」を測定する他の方法は何ですか？
Yslowはあなたを助けるはずのツール（ブラウザ拡張機能）です。
YSlowは、高性能Webサイトに関するYahoo!のルールに基づいて、Webページとその速度が遅い理由を分析します。
Web 開発者にとって必須の Firefox 拡張機能であるFirebugは、Web ページ上のさまざまな要素の読み込み時間を測定できます。少なくとも、読み込みに時間がかかりすぎる CSS、JavaScript、およびその他の要素を除外できます。
JavaScript と CSS の読み込み時間を短縮する必要がある場合は、改行文字やコメントなどの不要なテキストを単純に削除するさまざまな JavaScript および CSS コンプレッサが Web 上にあります。もちろん、通常版は開発用に置いておきます。
PNG を使用している場合、私は最近、 OptiPNGと呼ばれる PNG サイズを縮小できる PNG オプティマイザに出会いました。
「ページ読み込み時間」は、一般的に定義するのは本当に簡単ではありません。使用するブラウザーによって異なります。ブラウザーが異なればより多くの要求を並行して処理できるため、javascript はブラウザーごとに速度が異なり、レンダリング時間が異なるためです。
したがって、関心のあるブラウザーを使用して実際のページ読み込み時間を実際に測定することしかできません。すべてがページに表示された後に Ajax リクエストが発生する可能性があるため、ページ読み込みの終了も定義が難しい場合があります。それはページの読み込みをカウントしますか？
最後になりましたが、実際のページの読み込み時間はそれほど重要ではないかもしれません。なぜなら、「知覚されるパフォーマンス」が重要だからです。ユーザーにとって重要なのは、続行するのに十分な情報がいつ得られるかです。
ページの認識された読み込み時間を自動的に測定する方法を知りません（少なくとも、私はあなたに言うことができません:]）。
IE の場合はAOL Pagetest、Firefox の場合は YSlow (上記のリンクを参照) を使用して、読み込み時間の「感覚」をつかみます。
適切なデバッグ プロキシをインストールしてください ( Charlesを徹底的にお勧めします) 。
応答時間/サイズの完全な内訳を確認できるだけでなく、後で分析/比較するためにデータを保存したり、要求/応答などをいじったりすることができます。
(編集: Charles による SOAP リクエストのデバッグのサポートは、そのシェアウェア料金のわずかな金額に見合うだけの価値があります。おかげで、今週だけで半日分の脱毛を節約できました!)
私は定期的にwebpagetest.orgを使用しています。これを使用して、さまざまな場所から、さまざまなブラウザー (msie 7-9 のみですが) で、さまざまな設定 (反復回数、接続速度、初回実行と 2 回目の訪問、特定のものを除く) を使用してパフォーマンス テストを実行できます。必要に応じてリクエスト、必要に応じて資格情報、...)。
その結果、ページの読み込み時間に関する非常に詳細なレポートが作成され、最適化方法に関するアドバイスも提供されます。
それは本当に素晴らしい（無料の）ツールです！
前回、大量の Web サイトに取り組んだとき、次のようないくつかのことを行いました。
簡単に見てみたい場合は、最初の概算を言うと、YSlowを使用して、アプリのページ読み込み時間に影響を与える主な要因が何であるかを確認します。
Well, call me old fashioned but..
time curl -L http://www.example.com/path
in linux :) Other than that, I'm a big fan of YSlow as previously mentioned.
PageSpeedは Google によるオンライン チェック ツールで、非常に正確で信頼性があります。
If it's asp.net you can use Trace.axd.
Yahoo provide yslow which can be great for checking javascript
上記のようにYSlow。
これを Fiddler と組み合わせます。最も多くの帯域幅を使用しているページ オブジェクト、サーバーで圧縮されているページ オブジェクト、予期しないラウンドトリップ、およびキャッシュされているオブジェクトを確認する場合に便利です。また、サーバーとクライアントの間でかかる時間と比較して、クライアントの Web ブラウザーでの処理時間に関する一般的なアイデアを得ることができます。
応答時間を特定する方法はいくつかあることは明らかですが、ブラウザで費やされるレンダリング時間をどのように測定するかが常に課題でした。
アプリケーションをテストするためにいくつかの自動化されたツールを使用する、制御されたテスト フェーズがあります。このテストから生成される出力の 1 つは、各トランザクション (クリック) のフィドラー トレースです。次に、フィドラー トレースを分析して最後のバイトの時間を把握し、それをページにかかった全体の時間から差し引くことができます。
このようなもの 1. A = 自動化ツールによって測定された合計応答時間 (この場合は QTPro を使用) 2. B = 最後のバイトまでの時間 (サーバー + ネットワーク時間、フィドラー トレースから) 3. C = AB (おおよそのレンダリング時間、またはブラウザで費やされた時間)
上記で説明したすべてを標準のテスト プロセスにすることができ、テストの最後に、レンダリング時間、ネットワーク時間、データベース呼び出しなど、各レイヤーで費やされた時間の内訳を生成できます。
Safariでは、ネットワーク タイムライン([開発] メニューの下にあり、特に有効にする必要があります) は、個々のページ コンポーネントの読み込み時間に関する有用な情報と、各コンポーネントの読み込み開始時刻を示します。
Yslow は良いですし、IE の HttpWatch も素晴らしいです。ただし、どちらもユーザーにとって最も重要な指標である「ページ (スクロールせずに見える範囲) をユーザーが使用できるようになるのはいつですか?」を見逃しています。まだ一つも解決していないと思います...