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