フロントエンドのパフォーマンスのテストと最適化
5788 ワード
テストの目標
テストの目標は、Webアプリケーションをより速くすることですが、ブラウザによって異なります.すべてのブラウザがテストを行うのは困難であり、chromeのような急速なブラウザでテストを行うと、かかる時間に比べて特に適切ではありません.一般的に最も遅いブラウザIE 6で最高の速度に達すると、現代のブラウザでも良い速度になります.
ブラウザがどのように動作するか詳細なテストを行うには、ブラウザがどのように動作しているかを知る必要があります.原理を知ってこそシステムのボトルネックを見つけ、それに応じて最適化することができる.ブラウザのワークフローは大きく分けて次のようになります.
ダウンロード(ダウンロードのプロセスは、DNS解析、接続の確立、リクエストの送信、応答待ち、データの受信)に細分化できます.この部分の時間は主にサーバ側の動的html生成に費やされる.解析(解析は、解析、実行、描画、再描画などのプロセスに分けられ、html/CSS/JSの解析など、異なるオブジェクトに対して異なる)ブラウザのダウンロード開始から描画完了までの実行順序全体は以下の通りである.
この図はW 3 Cから源を発して、現在すでに1つの草案がweb応用に対するテストを実現しました:navigation-timing!この草案をサポートできるブラウザはまだありません.しかし、この図はブラウザのワークフローと重要ないくつかの点をよく示しています.
domLoading:このイベントがトリガーされる前の性能問題の多くはネットワークとサーバープログラムと大きな関係があり、フロントエンドでできることは34の軍規を守ることです(この軍規はdomLoadingに役立つだけでなく、その一部は他のプロセスにも卓越した加速効果があります!).domContentLoaded:このイベントはdomツリーの解析が完了したことを示しており、一般的に初期化用のJSの多くはこのイベントから始まる.LoadEventStart:このイベントはすべての外部リンクがロードされたことを示しています.loadイベントは一般的にあまり重要ではありません.後でロードできるJSをトリガーします.フロントエンドで最も便利なのは、プロセスとonLoadフェーズの最適化、つまりdomLoadingイベントの後です.これは、CSSとJavascriptの2つの側面のパフォーマンステストに関連しています.しかし、具体的な詳細をテストする前に、システムのボトルネック、すなわちWebページ全体のパフォーマンステストを見つける必要があります.
Webページのパフォーマンステストはどのようにテストしますか?Webページのパフォーマンスをテストするには、開始点が必要です.計算するのに一番便利なのはhtmlヘッダに短いscriptを追加することです.
開始時間を取得します.
次に、「ブラウザがレンダリングを開始する時間(Time To Start Render)」です.このイベントは、ブラウザがページの描画を開始し、その前にページが白画面になっていたことを示します.このイベントポイントを計算する鍵はdocumentを利用することにある.body.offsetHeightという属性は、描画を開始するとbodyの高さが変化します.タイマーでdocumentを問い合わせることができますbody.offsetHeightは、0より大きいとブラウザがページを描き始めます.白画面ではなくページが変化していることをユーザーが初めて体験した.幸いなことにFirefoxは、Time To Start Renderを表す独自のイベントも提供しています.https://developer.mozilla.org/en/Gecko-Specific_DOM_Events.計算コードは次のようになります.
次の時点はdomReady時点であり、この点の計算はdomReadyイベントを利用して容易に完了することができ、IEのようにdomReadyをサポートしていないブラウザに対してもdoScrollメソッドで模倣することができる.一般的なライブラリにはこの機能があります.この時点はdomが準備されていることを意味し、ページが基本的に描かれています(もちろん、画像、iframeなどの外部リソースはまだありません).
その後の1つの時点がonload時点にあるので、この計算はもっと便利です.この時間ノードが到着すると、ブラウザがhtmlで最初に表示された外部リソースのロードを終了したことを意味し、画像が表示されます.さらに重要なのは、ブラウザのロードプロンプトが終了したことです.多くのネット年齢のユーザーにとって、これは直感的な体験です.ユーザーに私たちのサイトがすでに使用できることを教えます.
最後の時点はインタラクション開始時間TTI時間であり、この時間の計算は異なるサイトによって異なり、コンテンツの性質のサイトであれば、TTI時間はdomReadyより前、Time To Start Renderより後であるべきである.コンテンツの性質のウェブサイトのため、ユーザーにとってコンテンツを見ただけでウェブサイトが利用可能であることを示す.インタラクティブなWebサイトTTI時間であれば、domReadyの後が一般的である(JSの実行はdomReadyの後が一般的である).インタラクティブなWebサイトは、ユーザーの操作に応答するためにJSがさまざまなイベントをバインドする必要があるためです.
すべての最適化はTTI時間を向上させるためであり,この時間を向上させることはユーザにとって最も直感的なウェブサイトの速度向上の表現である.TTI時点の計算は、Webサイトによって異なるため、一般的な方法は、特定の実行中にスクリプトを追加して時間を得ることです.
Time To Start Renderの時間を早めるには、ヘッダ内のリンク数(CSSのマージ、favour.ico待ち)を減らしhtmlのサイズを減らす(余分なhtmlを取り除き、構造を最適化する)サーバ側がより力を入れる方法が主な方法です.
domReady時間を最適化する方法は、スクリプトを最後にスクリプトをdomReadyに配置して実行する(これは一般的によくできているようで、jQueryが普及している基本的な知識)非同期のロードJSです.同時にdomReadyの後に非同期ロードを開始し、domReadyの前にスクリプトがJSをwrapperでロードすることを回避し、JSのロードと実行を分離します(http://mzhou.me/?p=95284)
どのようにonLoad時間点を最適化するか:最適化前のいくつかの時間点はすでにonLoad時間を繰り上げる目的を達成することができて、部門別ロード実行JSを実行して、初期化の時に必要なコードをdomReadyの時にロード実行して、非初期化コードをonLoadの後に実行します.たとえば、重要でないサードパーティ製プラグインをロードするなど、iframe形式のプラグインが多いので、onLoadに置いてから実行するのが最適です
どのようにTTIを最適化します:前の3つの最適化をやり遂げる時、すでにTTI時間を高めました最適化CSSの効率を減らしますdom元素を減らしてJSの効率を最適化しますコンテンツの性質のウェブサイトならば、コンテンツのhtmlを比較的に前の位置に置いてもしインタラクティブな性質のウェブサイトならば、特に重要なコアのコンポーネントのJSを剥離して前に放して、コンポーネントの初期化の時間点を速めます
TTIを最適化する方法は多く,その計算方法自体が統一的に定義しにくいためである.
このように悪くないと、システムのパフォーマンスのボトルネックを見つけることができます.どのようにしてボトルネックをより正確に特定しますか?ここでは主に二つの方面を説明する:CSSとJSの性能テストCSS性能テスト
なぜCSSの性能テストを行うのか、CSSの解析は性能消耗と比べて他には少ないが、AJAXの操作が豊富なサイトでは、CSSの性能が再描画の速度に影響し、遅すぎるとユーザーの体験に影響を与える.一般に,これらの性の再描画操作ユーザが耐えられる最大限度は200ミリ秒程度である.加えて、フロントエンドテンプレートがますます重視されているため、これらの大面積の再描画がAJAXウェブアプリケーションに登場する機会が多い.
テスト方法
htmlをリセットします.簡単に言えば、テストする部分のhtmlを削除し、追加します.CSSの性能を計算します.より正確な方法は、要素に対応するセレクタ(Class,IDなど)を取り除くことです.そうしないのは、操作するdomの回数が多すぎて、計算時間の精度が悪い可能性が高いからです.もう一つの原因は、実際にはこのように修正することはできません.innerHTMLを修正することが多いからです.テストのコードは次のとおりです.
最適化方法選択子階層を減らす(選択子が後から検索されることを覚えておく)ワイルドカード選択子を使うな*Dom要素を減らして空のclass backgroundを減らすfloatとpositionの位置決めを平らにしないほうがいいが、2番目の選択があればJavaScript性能テストを使わない
CSSに比べて、JSの性能テストツールは大きな問題を引き起こしている.ここではいくつかの使いやすいツールをお勧めします:dynaTrace:http://ajax.dynatrace.com/ajax/en/Default.aspx jsperf: http://jsperf.com/ regexbuddy: http://www.regexbuddy.com/ firebug: http://getfirebug.com/ pageSpeed: http://code.google.com/intl/zh-CN/speed/page-speed/ dragonFly:http://www.opera.com/dragonfly/もしあなたがもっと良いツールを知っていたら、ひざまずいて教えてください!
最適化方法domの操作回数を減らすfunction wrapperを用いて、実行とロードを分離し、必要に応じて実行する文章の冒頭でも述べたように、IE 6を最適化するだけで(文字列のつなぎ合わせは良い例であり、chromeのように高速ブラウザで+番号を告げる方法とarray joinの速度と同じであり、わずかに超えている)サイクル操作、タイマ、連続したイベント呼び出しを最適化の重点オブジェクトとして、一般的な使い捨て操作では大きな問題はありませんが、何度も問題があります.前にtwitterはwindowsでscrollイベントの操作にdom操作がバインドされすぎて、ブラウザがフリーズした場合、できるだけ組み込み関数を使用して問題を解決します.例えば、高度なブラウザにはArrayがあります.forEachメソッドは、配列を巡回してローカル変数でキャッシュするために複数回呼び出す必要があるグローバル変数を減らすオブジェクト検索の階層分時間最適化処理を調べて、あなたが使用しているライブラリを調べて、彼らのコードの問題かどうかを調べます.
テストの目標は、Webアプリケーションをより速くすることですが、ブラウザによって異なります.すべてのブラウザがテストを行うのは困難であり、chromeのような急速なブラウザでテストを行うと、かかる時間に比べて特に適切ではありません.一般的に最も遅いブラウザIE 6で最高の速度に達すると、現代のブラウザでも良い速度になります.
ブラウザがどのように動作するか詳細なテストを行うには、ブラウザがどのように動作しているかを知る必要があります.原理を知ってこそシステムのボトルネックを見つけ、それに応じて最適化することができる.ブラウザのワークフローは大きく分けて次のようになります.
ダウンロード(ダウンロードのプロセスは、DNS解析、接続の確立、リクエストの送信、応答待ち、データの受信)に細分化できます.この部分の時間は主にサーバ側の動的html生成に費やされる.解析(解析は、解析、実行、描画、再描画などのプロセスに分けられ、html/CSS/JSの解析など、異なるオブジェクトに対して異なる)ブラウザのダウンロード開始から描画完了までの実行順序全体は以下の通りである.
この図はW 3 Cから源を発して、現在すでに1つの草案がweb応用に対するテストを実現しました:navigation-timing!この草案をサポートできるブラウザはまだありません.しかし、この図はブラウザのワークフローと重要ないくつかの点をよく示しています.
domLoading:このイベントがトリガーされる前の性能問題の多くはネットワークとサーバープログラムと大きな関係があり、フロントエンドでできることは34の軍規を守ることです(この軍規はdomLoadingに役立つだけでなく、その一部は他のプロセスにも卓越した加速効果があります!).domContentLoaded:このイベントはdomツリーの解析が完了したことを示しており、一般的に初期化用のJSの多くはこのイベントから始まる.LoadEventStart:このイベントはすべての外部リンクがロードされたことを示しています.loadイベントは一般的にあまり重要ではありません.後でロードできるJSをトリガーします.フロントエンドで最も便利なのは、プロセスとonLoadフェーズの最適化、つまりdomLoadingイベントの後です.これは、CSSとJavascriptの2つの側面のパフォーマンステストに関連しています.しかし、具体的な詳細をテストする前に、システムのボトルネック、すなわちWebページ全体のパフォーマンステストを見つける必要があります.
Webページのパフォーマンステストはどのようにテストしますか?Webページのパフォーマンスをテストするには、開始点が必要です.計算するのに一番便利なのはhtmlヘッダに短いscriptを追加することです.
<script>window.startTime = +new Date();</script>開始時間を取得します.
次に、「ブラウザがレンダリングを開始する時間(Time To Start Render)」です.このイベントは、ブラウザがページの描画を開始し、その前にページが白画面になっていたことを示します.このイベントポイントを計算する鍵はdocumentを利用することにある.body.offsetHeightという属性は、描画を開始するとbodyの高さが変化します.タイマーでdocumentを問い合わせることができますbody.offsetHeightは、0より大きいとブラウザがページを描き始めます.白画面ではなくページが変化していることをユーザーが初めて体験した.幸いなことにFirefoxは、Time To Start Renderを表す独自のイベントも提供しています.https://developer.mozilla.org/en/Gecko-Specific_DOM_Events.計算コードは次のようになります.
if(/Firefox/.test(navigator.userAgent)){
window.addEventListener(
"MozAfterPaint",
functiongetStartDate(){
window.removeEventListener(
"MozAfterPaint"
, getStartDate,
false
);
window.startRenderTime =
new Date()*1;
},
false
);
}
else
{
function
getStartDate() {
if
( document.body && document.body.offsetHeight > 0 ){
window.startRenderTime =
new
Date()*1;
}
setTimeout( getStartDate, 30 );
}
getStartDate();
}
次の時点はdomReady時点であり、この点の計算はdomReadyイベントを利用して容易に完了することができ、IEのようにdomReadyをサポートしていないブラウザに対してもdoScrollメソッドで模倣することができる.一般的なライブラリにはこの機能があります.この時点はdomが準備されていることを意味し、ページが基本的に描かれています(もちろん、画像、iframeなどの外部リソースはまだありません).
その後の1つの時点がonload時点にあるので、この計算はもっと便利です.この時間ノードが到着すると、ブラウザがhtmlで最初に表示された外部リソースのロードを終了したことを意味し、画像が表示されます.さらに重要なのは、ブラウザのロードプロンプトが終了したことです.多くのネット年齢のユーザーにとって、これは直感的な体験です.ユーザーに私たちのサイトがすでに使用できることを教えます.
最後の時点はインタラクション開始時間TTI時間であり、この時間の計算は異なるサイトによって異なり、コンテンツの性質のサイトであれば、TTI時間はdomReadyより前、Time To Start Renderより後であるべきである.コンテンツの性質のウェブサイトのため、ユーザーにとってコンテンツを見ただけでウェブサイトが利用可能であることを示す.インタラクティブなWebサイトTTI時間であれば、domReadyの後が一般的である(JSの実行はdomReadyの後が一般的である).インタラクティブなWebサイトは、ユーザーの操作に応答するためにJSがさまざまなイベントをバインドする必要があるためです.
すべての最適化はTTI時間を向上させるためであり,この時間を向上させることはユーザにとって最も直感的なウェブサイトの速度向上の表現である.TTI時点の計算は、Webサイトによって異なるため、一般的な方法は、特定の実行中にスクリプトを追加して時間を得ることです.
window.ttiTime = +
new
Date();
?
Time To Start Renderの時間を早めるには、ヘッダ内のリンク数(CSSのマージ、favour.ico待ち)を減らしhtmlのサイズを減らす(余分なhtmlを取り除き、構造を最適化する)サーバ側がより力を入れる方法が主な方法です.
domReady時間を最適化する方法は、スクリプトを最後にスクリプトをdomReadyに配置して実行する(これは一般的によくできているようで、jQueryが普及している基本的な知識)非同期のロードJSです.同時にdomReadyの後に非同期ロードを開始し、domReadyの前にスクリプトがJSをwrapperでロードすることを回避し、JSのロードと実行を分離します(http://mzhou.me/?p=95284)
どのようにonLoad時間点を最適化するか:最適化前のいくつかの時間点はすでにonLoad時間を繰り上げる目的を達成することができて、部門別ロード実行JSを実行して、初期化の時に必要なコードをdomReadyの時にロード実行して、非初期化コードをonLoadの後に実行します.たとえば、重要でないサードパーティ製プラグインをロードするなど、iframe形式のプラグインが多いので、onLoadに置いてから実行するのが最適です
どのようにTTIを最適化します:前の3つの最適化をやり遂げる時、すでにTTI時間を高めました最適化CSSの効率を減らしますdom元素を減らしてJSの効率を最適化しますコンテンツの性質のウェブサイトならば、コンテンツのhtmlを比較的に前の位置に置いてもしインタラクティブな性質のウェブサイトならば、特に重要なコアのコンポーネントのJSを剥離して前に放して、コンポーネントの初期化の時間点を速めます
TTIを最適化する方法は多く,その計算方法自体が統一的に定義しにくいためである.
このように悪くないと、システムのパフォーマンスのボトルネックを見つけることができます.どのようにしてボトルネックをより正確に特定しますか?ここでは主に二つの方面を説明する:CSSとJSの性能テストCSS性能テスト
なぜCSSの性能テストを行うのか、CSSの解析は性能消耗と比べて他には少ないが、AJAXの操作が豊富なサイトでは、CSSの性能が再描画の速度に影響し、遅すぎるとユーザーの体験に影響を与える.一般に,これらの性の再描画操作ユーザが耐えられる最大限度は200ミリ秒程度である.加えて、フロントエンドテンプレートがますます重視されているため、これらの大面積の再描画がAJAXウェブアプリケーションに登場する機会が多い.
テスト方法
htmlをリセットします.簡単に言えば、テストする部分のhtmlを削除し、追加します.CSSの性能を計算します.より正確な方法は、要素に対応するセレクタ(Class,IDなど)を取り除くことです.そうしないのは、操作するdomの回数が多すぎて、計算時間の精度が悪い可能性が高いからです.もう一つの原因は、実際にはこのように修正することはできません.innerHTMLを修正することが多いからです.テストのコードは次のとおりです.
// CSS
var
$body = $(
'body'
),
$html = $body.html(),
old = +
new
Date();
$body.html($html);
console.log( +
new
Date() - old );
最適化方法選択子階層を減らす(選択子が後から検索されることを覚えておく)ワイルドカード選択子を使うな*Dom要素を減らして空のclass backgroundを減らすfloatとpositionの位置決めを平らにしないほうがいいが、2番目の選択があればJavaScript性能テストを使わない
CSSに比べて、JSの性能テストツールは大きな問題を引き起こしている.ここではいくつかの使いやすいツールをお勧めします:dynaTrace:http://ajax.dynatrace.com/ajax/en/Default.aspx jsperf: http://jsperf.com/ regexbuddy: http://www.regexbuddy.com/ firebug: http://getfirebug.com/ pageSpeed: http://code.google.com/intl/zh-CN/speed/page-speed/ dragonFly:http://www.opera.com/dragonfly/もしあなたがもっと良いツールを知っていたら、ひざまずいて教えてください!
最適化方法domの操作回数を減らすfunction wrapperを用いて、実行とロードを分離し、必要に応じて実行する文章の冒頭でも述べたように、IE 6を最適化するだけで(文字列のつなぎ合わせは良い例であり、chromeのように高速ブラウザで+番号を告げる方法とarray joinの速度と同じであり、わずかに超えている)サイクル操作、タイマ、連続したイベント呼び出しを最適化の重点オブジェクトとして、一般的な使い捨て操作では大きな問題はありませんが、何度も問題があります.前にtwitterはwindowsでscrollイベントの操作にdom操作がバインドされすぎて、ブラウザがフリーズした場合、できるだけ組み込み関数を使用して問題を解決します.例えば、高度なブラウザにはArrayがあります.forEachメソッドは、配列を巡回してローカル変数でキャッシュするために複数回呼び出す必要があるグローバル変数を減らすオブジェクト検索の階層分時間最適化処理を調べて、あなたが使用しているライブラリを調べて、彼らのコードの問題かどうかを調べます.