Google I/O セッションJank Busters: Building Performance Web Appsを見たところです。講演者は、Chrome Web インスペクタのタイムラインで新しい「フレーム」ビューを使用する方法を説明しました。
開発中のページをスクロールしたときに得た記録の例を次に示します。
ご覧のように、一部のフレームに大きな遅延がありますが、タイムラインには明らかな原因はありません (黄色の「Timer Fired」イベントの間に大きなギャップがあります)。フレームレートを一貫して増加させるために、パフォーマンスの問題をトラブルシューティングするにはどうすればよいですか?
あなたの例は実際にはそれほど悪くはありません。コードは高速で実行され、ブラウザは 60 fps でしかレンダリングしないため、次のレンダリング サイクルを待機するのに少し時間がかかります (最大 16 ミリ秒)。
これは、Chrome Dev Toolsタイムラインパネルのフレームビューからの特に心配なスナップショットです。
ドキュメントによると：
バーの下部にある非常に小さな黄色と緑の領域は、イベント処理、ペイント、および合成がすべて非常に高速に実行されたことを示しています。時刻 (行は表示されません。)
詳細については、開発ツールのオプションを開いて以下を確認してください。
これを有効にすると、「RECORDS」バーに灰色の領域が表示されます。
灰色の各領域は、レンダラー スレッドが占有されていた期間を示します。多くのギャップが見られる場合、ブラウザーは GPU バウンドである可能性があります。
Chrome のエンジニアである Nat Duca が、この投稿で詳細を提供しています。
GPU の境界は通常、次の 2 つの要素から生じます。
- -webkit-filter を使用すると、要素の 3D プロパティが保持されます。それらは gpu で食べてしまいます... うーん、空腹の何か。
- 大きなレイヤーが多すぎます。
レイヤー？それらを表示するには、「合成レイヤーの境界線を表示」します。ほとんどの人が問題を起こすのは、層の数ではなく、層の面積です。
経験則: ほとんどのコンピューターは、メイン画面のすべてのピクセルに約 4 回タッチできるように設計されています。非常に単純な例として、2 年前の MacBook Air はその LCD のサイズに合わせてプロビジョニングされています。複数のレイヤーを持つ 30 インチ モニターを接続すると、GPU バインドが開始されます。
なぜこれが重要なのですか？[手を振る] 画面を描画すると、レイヤーがピクセルに 1 回接触します。レイヤーがウィンドウのサイズである場合、たとえば、-webkit-transform: translateZ(0) で width=100% height=100% div を取得した場合、画面のすべてのピクセルに 1 回触れています。したがって、レイヤーの面積を数え上げてください。モニターの面積の 4 倍を超えると、スペースに移動できない場合があります [GPU バウンドのため]。
GPU の境界をテストするには、各次元でウィンドウ サイズを 1/2 に縮小します。処理速度が遅い場合は、別のことが起こっています...処理速度が速くなった場合は、おそらく GPU に負荷がかかっています。
私の場合 (一番上の写真に示されています)、灰色のバーの原因を突き止めようとしています。コードは変更されておらず、以前はパフォーマンスが優れていました。Chrome の新しいビルド (現在は 31.0.1650.57 m を実行しています) は、何らかの理由でこのコードでうまく機能しない可能性があります。繰り返しますが、グレーの領域は、レンダリング スレッドがインストルメント化されていないコードでビジーだったことを示しているため、何が起こっているのかわかりません。
http://pagespeed.googlelabs.comを使用することをお勧めします
基本的に、ページが読み込まれているときに何が起こったのかを完全に詳細に表示するので、どこで作業すればよいかがわかります... (また、場合によっては特定の情報を見逃す可能性があると思います)
また、ページのメモリ プロファイリングを実行して、一部のオブジェクトがメモリにロードされるまでの時間を確認する必要があります。