はじめに
本文の第一部は Chrome DevTools ドキュメントからの翻訳です:How to Use the Timeline Tool
昨年にもこれを行いました。Chrome DevTools を参照してください。Chrome バージョンとドキュメントは継続的に更新されており、Timeline パネルの機能はより強力になり、レイアウトもいくつか変化しました
一.訳文
Chrome DevTools の Timeline パネルを使用して、アプリケーション実行時のすべてのアクティビティを記録・分析でき、アプリケーションのパフォーマンス問題を調査するために使用できます
[caption id="attachment_1260" align="alignnone" width="625"]
timeline-panel[/caption]
コンテンツ概要
-
タイムライン記録を生成して、ページ読み込み後またはユーザーインタラクション後に発生するすべてのイベントを分析
-
概観ペインで FPS、CPU、ネットワークリクエストを表示
-
フレームチャート(flame chart)の各イベントをクリックして詳細情報を表示
-
記録の一部を拡大して分析可能
Timeline パネル概要
[caption id="attachment_1263" align="alignnone" width="938"]
timeline-annotated[/caption]
Timeline パネルは上から下へ順に:
- 制御オプション
記録開始、記録停止、記録プロセス中にどの情報をキャプチャするかを設定
-
概観
ページパフォーマンスの高度な要約。詳細は以下
-
フレームチャート
CPU スタックトレースの視覚化表現
フレームチャートには 3 本の縦の点線が表示される場合があります。青線は DOMContentLoaded イベント、緑線は最初の描画時点、赤線は load イベントを示します
- 詳細情報
イベントを選択すると、最下部の詳細情報ペインにそのイベントの詳細情報が表示されます。イベントが選択されていない場合は、選択された時間範囲の総合情報が表示されます
概観ペイン
[caption id="attachment_1265" align="alignnone" width="954"]
overview-annotated[/caption]
3 種類のグラフが含まれます:
-
FPS
毎秒フレーム数。緑のバーが高いほど FPS が高い。FPS グラフ上部の赤いブロックは長帧を示し、スタッター(jank)が発生する可能性があります
-
CPU
CPU リソース。エリアチャート(area chart)はどのタイプのイベントが CPU リソースを消費したかを示します
-
NET
各色のバーはリソースを表し、バーが長いほどリソース取得に時間がかかります。各バーの浅色部分は待機時間(リソースリクエストから最初のバイトを取得するまでの時間)を表します。深色部分はデータ転送時間(最初のバイトを取得してから最後のバイトを取得するまでの時間)を表します
バーの色の意味は以下の通り:
HTML:青 Scripts:黄 CSS:紫 Media:緑 その他のもろもろのリソース:灰
記録の生成
Timeline パネルを開き、記録したいページを開き、ページを reload します。Timeline パネルは reload プロセスを自動的に記録します
ページインタラクションを記録するには、まず Timeline パネルを開き、記録ボタンをクリックするか、ショートカットキー Cmd+E(Mac) または Ctrl+E(Windows/Linux) を押します。記録ボタンが赤くなると記録中であることを示します。ページインタラクションを実行し、再度記録ボタンをクリックするか、キーボードショートカットを押して記録を停止します
記録終了時、DevTools はどの部分が最も関心があるかを推測し、自動的にその部分を選択します
溫馨提示:
-
記録プロセスをできるだけ短く。短いほど分析しやすい
-
不要なアクションを避ける。記録分析したい部分と関係のない外部アクション(マウスクリック、ネットワーク読み込みなど)を避ける。例えば、ログインボタンクリック後に発生するイベントを記録したい場合、同時にページをスクロールしたり、画像を読み込んだりしないでください
-
ブラウザキャッシュを無効にする。ネットワーク操作を記録する際は、DevTools 設定パネルまたはネットワーク状況(Network conditions)オプションを通じてブラウザキャッシュを無効にするのが最善です
-
プラグインを無効にする。Chrome プラグインはアプリケーションの Timeline 記録に影響を与える可能性があります。シークレットモード(incognito mode)で Chrome ウィンドウを開くか、新しい Chrome ユーザープロファイル(Chrome user profile)を作成して、環境にプラグインがないことを保証できます
記録詳細の表示
[caption id="attachment_1269" align="alignnone" width="936"]
details-pane[/caption]
フレームチャートでイベントを選択すると、詳細情報ペインにイベントに関する追加情報が表示されます
Summary などの一部のタブはすべてのイベントタイプにあり、他の一部のタブは特定のイベントタイプにのみあります。記録タイプの詳細情報は Timeline event reference を参照
記録プロセス中のスクリーンショット
[caption id="attachment_1270" align="alignnone" width="625"]
timeline-filmstrip[/caption]
Timeline パネルはページ読み込みプロセス中にスクリーンショットを撮影でき、この特性は映画のフィルムストリップのようです
記録開始前に、制御ペインで Screenshots チェックボックスをオンにすると、スクリーンショットが記録され、スクリーンショットは概観ペイン下部に表示されます
スクリーンショットまたは概観ペイン上にマウスをホバーすると、その時点の拡大スクリーンショットを表示できます。マウスを左から右に移動してアニメーション効果をシミュレートできます
JS パフォーマンス分析
[caption id="attachment_1271" align="alignnone" width="625"]
js-profile[/caption]
記録開始前に、JS Profile チェックボックスをオンにすると、タイムライン記録中の JS 呼び出しスタックをキャプチャできます。JS Profile を有効にすると、フレームチャートには呼び出された各 JS 関数が表示されます
描画パフォーマンス分析
[caption id="attachment_1272" align="alignnone" width="625"]
paint-profiler[/caption]
記録開始前に、Paint チェックボックスをオンにすると、Paint イベントを詳細に確認できます。描画パフォーマンス分析を有効にすると、Paint イベントをクリックすると、詳細情報ペインに Paint Profiler タブが表示され、より細かい粒度のイベント情報が表示されます
レンダリング設定
[caption id="attachment_1273" align="alignnone" width="822"]
rendering-settings[/caption]
メイン DevTools メニューを開き、More tools > Rendering settings を選択してレンダリング設定を行います。描画問題のデバッグに役立ちます。レンダリング設定を開くと、Console タブの隣にタブが表示されます(ない場合は esc を押して表示)
記録の検索
[caption id="attachment_1274" align="alignnone" width="690"]
find-toolbar[/caption]
イベントを表示する際、1 つのタイプのイベントのみに注目したい場合があります。例えば、各 Parse HTML イベントの詳細情報を表示する必要があるかもしれません
Timeline パネルで Cmd+F(Mac) または Ctrl+F(Windows/Linux) を押して検索ツールバーを開き、表示したいイベントタイプ名��例えば Event)を入力します
ツールバーは現在選択されている時間フレームにのみ有効で、選択された時間フレーム外のすべてのイベントは検索結果に表示されません
上下矢印で結果内を時間順に移動できます。したがって、最初の結果は選択された時間枠で最も早いイベントで、最後の結果は最も遅いイベントです。上下矢印をクリックするたびに、新しいイベントが選択されるため、詳細情報ペインでその詳細情報を表示できます。上下矢印をクリックするのは、フレームチャートのイベントをクリックするのと同じです
タイムラインの一部を拡大
[caption id="attachment_1275" align="alignnone" width="625"]
zoom[/caption]
記録の一部を拡大して、より簡単に分析できます。概観ペインを使用して記録の一部を拡大でき、拡大後、フレームチャートは自動的にその部分に対応して拡大されます
タイムラインの一部を拡大するには:
-
概観ペインで、マウスでタイムラインの一部をドラッグして選択
-
定規領域の灰色スライダーを調整
一部を選択した後、WASD で選択範囲を調整できます。W と S は拡大縮小、A と D は左右移動
記録のエクスポートとインポート
[caption id="attachment_1276" align="alignnone" width="517"]
save-open[/caption]
概観またはフレームチャートペインで右クリックして保存と開く、および関連オプションを選択できます
二.アニメーションパフォーマンス指標
フレームレート
最も直観的なのはフレームレート(単位は FPS、毎秒フレーム数を表す)で、30 以下は人眼が明らかにスタッターを感じ、60 以上は目で違いが分からず、30-60 は基本的に滑らかです
パフォーマンス目標はアニメーションフレームレートをできるだけ 60FPS に近づけることで、こうすれば一コマ一コマ的感觉がなくなります。したがって、アニメーションライブラリは一般的にこのようにします:
/* rAF shim. Gist: https://gist.github.com/julianshapiro/9497513 */
var rAFShim = (function() {
var timeLast = 0;
return window.webkitRequestAnimationFrame || window.mozRequestAnimationFrame || function(callback) {
var timeCurrent = (new Date()).getTime(),
timeDelta;
/* Dynamically set delay on a per-tick basis to match 60fps. */
/* Technique by Erik Moller. MIT license: https://gist.github.com/paulirish/1579671 */
timeDelta = Math.max(0, 16 - (timeCurrent - timeLast));
timeLast = timeCurrent + timeDelta;
return setTimeout(function() {
callback(timeCurrent + timeDelta);
}, timeDelta);
};
})();
requestAnimationFrame をサポートしている場合は直接使用し、ブラウザに実行頻度を決定させます(一般的に毎秒60 回以上)。サポートしていない場合のフォールバック方案は setTimeout です:
// 16 = 1000 / 60
timeDelta = Math.max(0, 16 - (timeCurrent - timeLast));
毎秒 60 回に到達するには、実行間隔は 16ms を超えてはいけません。したがって、setTimeout の遅延時間は一般的に 16 - 関数実行に必要な時間 です。関数実行時間が 16ms を超える場合、遅延は 0 です
フレームレートには多くの影響要因があります。例えば、計算集約的な JS タスクが大量の CPU 時間を占有してアニメーション関連 JS の実行が遅れる、レイアウト変更により頻繁な再描画 Rendering/Painting の時間消費が増大、コンポジットレイヤーが大きすぎる・多すぎることで Composite Layers の時間消費が増大し GPU 描画圧力が増大して時間消費が長くなるなど
メモリ
本来アニメーションとメモリには直接関係ありませんが、ハードウェアアクセラレーションにより、アニメーション要素にハードウェアアクセラレーションを適用->コンポジットレイヤーを作成->メモリを消費 という関係が生じます
CPU と GPU はメモリを共有しないため、コンポジットレイヤーを作成するには、要素レンダリング後に対応するビットマップデータをパッケージ化して GPU に送信する必要があります。このデータが「アニメーションが消費するメモリ」です。したがって、アニメーションのスタッターは、自分で引き起こした可能性があり、メモリもアニメーションパフォーマンス指標の 1 つです
アニメーションに対応すると、コンポジットレイヤーの数 と コンポジットレイヤーのサイズ になります。コンポジットレイヤーが多く大きいほど、ビットマップデータは大きくなり、消費メモリも大きくなります
三.アニメーションパフォーマンスデバッグ方法
フレームレートとメモリの 2 方面に対して、いくつかのデバッグ方法があります:
###1.何が最も時間を消費するか
Timeline ツールを使用して、比較的スタッターを感じる部分を記録し、FPS 欄に赤いバーがある部分を選択し、最下部の詳細情報ペインの Summary を見て、円グラフから最も時間を消費するものを見つけます。例えば:
Range: 294ms - 1.17s
Total: 878.74?ms
29.1?ms Loading
197.0?ms Scripting
43.0?ms Rendering
4.4?ms Painting
116.3?ms Other
489.0?ms Idle
JS が最も時間を消費している場合、Event Log タブをクリックし、時間消費順にソートし、最初の数項を展開して、具体的な JS ファイルを特定し、時間消費の原因を分析し、最適化方案を検討します
Rendering が最も時間を消費している場合、HTML 構造を簡素化し、不要な要素を削除し、レイアウトを簡素化し、reflow を減らすことを検討すべきです。Painting の場合、コンポジットレイヤーに注目すべきで、コンポジットレイヤーが多すぎる・大きすぎないか、余分な・見えないコンポジットレイヤーを削除することを検討し、アニメーション要素の z-index を増やして、暗黙的にコンポジットレイヤーを作成するのを回避します
P.S. まずシークレットモードを有効にしてから、Timeline で記録することを推奨します。否则、各種プラグインの JS が原因特定の邪魔になります(円グラフが不正確になります)
###2.何が最もメモリを消費するか
記録時間枠のメモリグラフを観察し、ピーク部分を選択し、Event Log タブで関連イベントを見つけ、イベントに関連する JS を検討します
しかし、一般的に JS の影響はコンポジットレイヤーの影響よりもはるかに小さいため、直接コンポジットレイヤーの状況を確認できます:概観ペインで FPS に赤いバーがある時間区間をドラッグして選択し、詳細情報ペインの Layers タブを表示し、document 下の各レイヤーを展開し、いくつかの事項に注目します:
-
コンポジットレイヤーの数は予想通りか、出現すべきでないレイヤーはないか?
-
レイヤーをクリックすると、そのサイズとメモリ消費およびそのレイヤーの作成原因を表示でき、メモリ消費が大きすぎないかを確認
大サイズのコンポジットレイヤーは非常にメモリを消費します。例えば、375x667 のレイヤーは 1.5MB のメモリを消費します。このような大サイズのレイヤーが多い場合、大量のメモリを占有し、メモリが逼迫すると確実にスタッターします
31x31 の小サイズボタンでも 16KB 必要です。したがって、大サイズアニメーション要素に注目するだけでなく、コンポジットレイヤーの数も重要な要因です。例えば、泡、煙など大量の小要素で実現する必要があるアニメーションは、効果のダウングレードまたは要素数の削減を検討し、擬似要素および border、outline、box-shadow などの属性を使用して複雑な HTML 構造を簡素化します
P.S. コンポジットレイヤーを削減し、メモリ消費を低減するより多くの方法については、[CSS アニメーションと GPU-パフォーマンス最適化テクニック](/articles/css 动画与 gpu/#articleHeader10) を参照
コメントはまだありません