実行時のパフォーマンスとは、ページの読み込み時ではなく実行中のページのパフォーマンスを示すものです。このチュートリアルでは、Chrome DevTools の [パフォーマンス] パネルを使用してランタイム パフォーマンスを分析する方法について説明します。このチュートリアルで学ぶスキルは、RAIL モデルに関して、ページのレスポンス フェーズ、アニメーション フェーズ、アイドル フェーズを分析するのに役立ちます。
使ってみる
このチュートリアルでは、ライブページで DevTools を開き、[パフォーマンス] パネルを使用して、ページ上のパフォーマンスのボトルネックを見つけます。
- Google Chrome をシークレット モードで開きます。シークレット モードでは、Chrome をクリーンな状態で実行できます。たとえば、多くの拡張機能がインストールされている場合、それらの拡張機能によってパフォーマンスの測定値にノイズが生じることがあります。
シークレット ウィンドウで次のページを読み込みます。これがプロファイリングを行うデモです。そのページには、たくさんの小さな青い四角形が上下に動いている。
https://googlechrome.github.io/devtools-samples/jank/
Command+Option+I キー(Mac)または Ctrl+Shift+I キー(Windows、Linux)を押して DevTools を開きます。
図 1. 左がデモ、右が DevTools
モバイル CPU のシミュレート
モバイル デバイスの CPU 性能は、デスクトップ パソコンやノートパソコンに比べてはるかに低くなります。ページをプロファイリングするときは、必ず CPU スロットリングを使用して、モバイル デバイスでのページのパフォーマンスをシミュレートします。
- DevTools で、[パフォーマンス] タブをクリックします。
- [スクリーンショット] チェックボックスがオンになっていることを確認します。
- [Capture Settings] をクリックします。DevTools に、パフォーマンス指標の取得に関連する設定が表示されます。
[CPU] で [2x speeddown] を選択します。DevTools は、CPU が通常の 2 倍遅くなるように CPU をスロットリングします。
図 2. 青色の枠で示されている CPU スロットリング
デモをセットアップする
このウェブサイトのすべての読者に対して一貫して機能するランタイム パフォーマンスのデモを作成するのは、困難です。このセクションでは、特定の設定に関係なく、デモをカスタマイズして、このチュートリアルで紹介するスクリーンショットや説明とエクスペリエンスが相対的に整合するようにします。
- 青い四角形が以前より著しく遅くなるまで [10 を足す] をクリックし続けます。ハイエンド マシンでは 20 回程度のクリックが必要です。
[最適化] をクリックします。青い四角形が速くスムーズに動きます。
[最適化を解除] をクリックします。青い四角形は動きが遅くなり、またジャンクが増えています。
ランタイム パフォーマンスの記録
最適化されたバージョンのページを実行すると、青い四角形はより速く移動します。なぜでしょう。どちらのバージョンも、同じ時間内に各正方形が同じ量のスペースを移動すると想定されています。[パフォーマンス] パネルで記録を行い、最適化されていないバージョンでパフォーマンスのボトルネックを検出する方法を確認します。
DevTools で、記録アイコン をクリックします。DevTools は、ページの実行時にパフォーマンス指標をキャプチャします。
図 3: ページのプロファイリング
数秒待ちます。
[停止] をクリックします。 DevTools が記録を停止し、データを処理して、結果が [パフォーマンス] パネルに表示されます。
図 4: プロファイルの結果
すごいデータ量ですね。でも心配はいりません。必要なのはすぐに理解できるはずです。
結果を分析する
ページのパフォーマンスを記録したら、ページのパフォーマンスの低さを測定し、原因を特定できます。
フレーム/秒の分析
アニメーションのパフォーマンス測定の主な指標は、フレーム/秒(FPS)です。アニメーションが 60 FPS で実行されると、ユーザーは満足できます。
FPS グラフを確認します。[FPS] の上に赤いバーが表示された場合は、フレームレートが非常に低く、ユーザー エクスペリエンスに悪影響がある可能性があることを意味します。一般に、緑色のバーが高いほど FPS は高くなります。
図 5: 青い枠で示された FPS グラフ
[FPS] グラフの下に、[CPU] グラフが表示されます。CPU グラフの色は、パフォーマンス パネルの下部にある [概要] タブの色に対応しています。CPU チャートがフルカラーで表示されている場合は、記録中に CPU が最大だったことを意味します。CPU の最大値が長時間不足する場合、これは作業を減らす方法を見つけるための手がかりとなります。
図 6: 青い輪郭が描かれている CPU グラフと [サマリー] タブ
[FPS]、[CPU]、または [NET] のグラフにカーソルを合わせます。DevTools に、その時点でのページのスクリーンショットが表示されます。マウスを左右に動かして記録を再生します。これはスクラブと呼ばれ、アニメーションの進行を手動で分析する場合に便利です。
図 7: 記録の 2,000 ミリ秒マーク付近のページのスクリーンショットを表示する
[フレーム] セクションで、緑色の四角形のいずれかにカーソルを合わせます。DevTools に、その特定のフレームの FPS が表示されます。各フレームはおそらく目標の 60 FPS を大幅に下回っています。
図 8: フレームにカーソルを合わせた状態
もちろん、このデモでは、ページのパフォーマンスが良好でないことがよくわかります。しかし、実際のシナリオではそれほど明確でない可能性があるため、測定にはこれらのツールがすべて必要です。
ボーナス: FPS メーターを開く
もう 1 つの便利なツールは FPS メーターです。これは、ページの実行中にリアルタイムで FPS の推定値を算出するものです。
- Command+Shift+P キー(Mac)または Ctrl+Shift+P キー(Windows、Linux)を押してコマンド メニューを開きます。
- コマンド メニューで「
Rendering
」と入力し、[Show Rendering] を選択します。 [レンダリング] タブで、[FPS メーター] を有効にします。新しいオーバーレイがビューポートの右上に表示されます。
図 9: FPS メーター
FPS メーターを無効にし、Esc キーを押して [レンダリング] タブを閉じます。このチュートリアルでは使用しません。
ボトルネックを見つける
アニメーションのパフォーマンスが良好でないことを測定、確認したら、次はその理由を確認しましょう。
[summary] タブに注目してください。イベントが選択されていない場合、このタブにはアクティビティの内訳が表示されます。 ページのレンダリング時間の大半を占めています。パフォーマンスとは作業量の削減を図るため、レンダリング処理に費やす時間を減らすことが目標です。
図 10: 青い輪郭線で囲まれた [Summary] タブ
[Main] セクションを開きます。DevTools に、メインスレッドのアクティビティのフレーム チャートが時系列で表示されます。X 軸は記録量の推移を示しています。各バーはイベントを表します。バーの幅が広いほど、イベントに時間がかかっていることを意味します。Y 軸はコールスタックを表します。イベントが重なって表示されている場合は、上位のイベントが下位のイベントの原因となっていることを意味します。
図 11: 青い枠で表示されているメイン セクション
この録画には大量のデータが含まれています。FPS、CPU、NET のグラフを含むセクションである [Overview] をマウスで長押ししながらドラッグすると、1 つのAnimation Frame Fired イベントを拡大できます。[Main] セクションと [Summary] タブには、選択した部分の記録に関する情報のみが表示されます。
図 12: 単一のアニメーション フレーム配信イベントにズームイン
[Animation Frame Fired] イベントの右上に赤い三角形が表示されます。赤い三角形が表示されている場合は、このイベントに関連する問題が発生している可能性があることを警告しています。
[Animation Frame Fired] イベントをクリックします。[概要] タブに、そのイベントに関する情報が表示されます。reveal リンクに注目してください。クリックすると、DevTools でアニメーション フレームの呼び出しイベントを開始したイベントがハイライト表示されます。app.js:94 リンクにも注意してください。これをクリックすると、ソースコード内の関連する行に移動します。
図 13: アニメーション フレーム配信イベントの詳細
app.update イベントの下に、紫色のイベントが多数あります。幅が広いと、それぞれに赤い三角形があるように見えます。紫色のレイアウト イベントのいずれかをクリックします。DevTools の [Summary] タブに、イベントの詳細情報が表示されます。実際には、強制リフロー(レイアウトの別の言葉)に関する警告があります。
[Summary] タブで、[Layout Forced] の下にある [app.js:70] リンクをクリックします。DevTools により、レイアウトを強制するコード行が表示されます。
図 13: 強制レイアウトが発生したコード行
これで多くのことを学びましたが、ランタイム パフォーマンスを分析するための基本的なワークフローに関する強固な基盤ができました。これで完了となります。
参考: 最適化されたバージョンを分析する
先ほど学習したワークフローとツールを使用して、デモの [Optimize](最適化)をクリックして最適化されたコードを有効にし、パフォーマンスをもう一度記録して、結果を分析します。フレームレートの改善から、メイン セクションのフレーム チャートでのイベントの削減まで、最適化されたバージョンのアプリのほうが作業量が大幅に減り、パフォーマンスが向上することがわかります。
次のステップ
パフォーマンスを理解するための基盤は RAIL モデルです。このモデルは、ユーザーにとって最も重要なパフォーマンス指標を示します。詳しくは、RAIL モデルでパフォーマンスを測定するをご覧ください。
[パフォーマンス] パネルに慣れるには、練習が役立ちます。ご自身のページをプロファイリングし、結果を分析してみてください。結果について質問がある場合は、google-chrome-devtools
タグで Stack Overflow の質問を開いてください。可能であれば、スクリーンショットまたは再現可能なページへのリンクを含めます。
ランタイム パフォーマンスのエキスパートになるには、ブラウザが HTML、CSS、JS を画面上のピクセルに変換する仕組みを学んでください。まずは、レンダリング パフォーマンスの概要をご覧ください。The Anatomy Of A Frame で、さらに詳細に説明しています。
最後に、ランタイム パフォーマンスを改善する方法はたくさんあります。このチュートリアルでは、特定のアニメーションのボトルネックに焦点を絞って [パフォーマンス] パネルの使い方を説明しますが、これは多くのボトルネックの 1 つにすぎません。残りのレンダリング パフォーマンス シリーズには、ランタイム パフォーマンスの次のようなさまざまな側面を改善するために役立つヒントが数多く含まれています。