このページは Cloud Translation API によって翻訳されました。

ランタイムパフォーマンスを分析する

Kayce Basques

ランタイムパフォーマンスとは、ページの読み込み時ではなく、実行中のページのパフォーマンスのことです。このチュートリアルでは、Chrome DevTools の [Performance] パネルを使用してランタイムパフォーマンスを分析する方法について説明します。RAIL モデルに関しては、このチュートリアルで学習するスキルは、ページのレスポンス、アニメーション、アイドルフェーズの分析に役立ちます。

使ってみる

このチュートリアルでは、[パフォーマンス] パネルを使用して、ライブページのパフォーマンスのボトルネックを見つけます。まずは以下の手順を行います。

Google Chrome をシークレットモードで開きます。シークレットモードでは、Chrome をクリーンな状態で実行できます。たとえば、インストールされている拡張機能が多いと、パフォーマンス測定にノイズが生じる可能性があります。
シークレットウィンドウで次のページを読み込みます。これはプロファイリングするデモです。ページには、小さな青い正方形が上下に動いているのが示されます。

https://googlechrome.github.io/devtools-samples/jank/
Command+Option+I（Mac）または Ctrl+Shift+I（Windows、Linux）を押して DevTools を開きます。

注: 残りのスクリーンショットでは、内容を見やすくするために、DevTools は別のウィンドウにドック解除されています。

モバイル CPU をシミュレートする

モバイルデバイスの CPU パワーは、デスクトップパソコンやノートパソコンに比べてはるかに少なくなります。ページをプロファイリングするときは、CPU スロットリングを使用して、モバイルデバイスでのページのパフォーマンスをシミュレートします。

DevTools で [パフォーマンス] タブをクリックします。
[スクリーンショット] チェックボックスが有効になっていることを確認します。
[Capture Settings] をクリックします。DevTools には、パフォーマンス指標の取得方法に関連する設定が表示されます。
[CPU] で [4x slowdown] を選択します。DevTools では、CPU が通常の 4 倍遅くなるようにスロットリングされます。

注: 他のページをテストする際、低価格帯のモバイルデバイスで確実に動作するようにするには、CPU スロットリングを 20 倍の遅延に設定します。このデモは 20 倍の低速化ではうまく機能しないため、説明のために 4 倍の減速を使用しています。

デモを設定する

このウェブサイトのすべての読者に一貫して動作するランタイムパフォーマンスのデモを作成するのは困難です。このセクションでは、デモをカスタマイズして、特定の設定に関係なく、このチュートリアルに表示されるスクリーンショットや説明と比較的一致するようにエクスペリエンスを設定できます。

青い正方形の動きが以前よりも明らかに遅くなるまで、[10 を追加] をクリックし続けます。ハイエンドのマシンでは、20 回ほどクリックする必要がある場合があります。
[最適化] をクリックします。青い正方形がより速く、よりスムーズに移動するはずです。

注: 最適化されたバージョンと最適化されていないバージョンに大きな違いがない場合は、[Subtract 10]（10 個減算）を数回クリックしてもう一度試してください。青い四角形を追加しすぎると、CPU が最大限に使用されているだけで、2 つのバージョンで結果に大きな違いは見られません。
[最適化を解除] をクリックします。青い四角形は動きが遅く、再びジャンクが増えます。

ランタイムパフォーマンスを記録する

最適化されたバージョンのページを実行すると、青い正方形が速く動きます。なぜでしょう。どちらのバージョンも、各正方形を同じ量のスペースを同じ時間内に動かすことになっています。[パフォーマンス] パネルで録画を作成して、最適化されていないバージョンのパフォーマンスボトルネックを検出する方法を確認します。

DevTools で [記録] をクリックします。DevTools は、ページの実行中にパフォーマンス指標をキャプチャします。
数秒待ちます。
[停止] をクリックします。 DevTools は記録を停止し、データを処理して、結果を [パフォーマンス] パネルに表示します。

大量のデータですね。心配はいりません。この後詳しく説明します。

結果を分析する

パフォーマンスレコーディングを取得すると、ページのパフォーマンスがどの程度低いかを分析し、原因を特定できます。

フレーム/秒の分析

アニメーションのパフォーマンスを測定する主な指標は、フレーム/秒（FPS）です。アニメーションが 60 FPS で実行されると、ユーザーは満足します。

FPS グラフを確認します。[FPS] の上に赤いバーが表示される場合は、フレームレートが非常に低下し、ユーザーエクスペリエンスに悪影響を与えている可能性があります。
[FPS] グラフの下に [CPU] グラフが表示されます。[CPU] グラフの色は、[パフォーマンス] パネルの下部にある [概要] タブの色に対応しています。CPU グラフがすべて色付きになっているのは、記録中に CPU が最大限に使用されたことを意味します。CPU が長時間最大値に達している場合は、負荷を軽減する方法を見つける必要があります。
[FPS]、[CPU]、[NET] のグラフにカーソルを合わせます。DevTools に、その時点でのページのスクリーンショットが表示されます。マウスを左右に動かして録音を再生します。これはスクラブと呼ばれ、アニメーションの進行を手動で分析する場合に便利です。
[フレーム] セクションで、緑色の正方形のいずれかにカーソルを合わせます。DevTools には、その特定のフレームの FPS が表示されます。各フレームは 60 FPS のターゲットよりはるかに低いと思われます。

もちろん、このデモでは、ページのパフォーマンスが良好でないことは明らかです。ただし、実際のシナリオでは、それほど明確でない場合があります。そのため、測定を行うためのこれらのツールがすべて揃っていると便利です。

参考: FPS メーターを開く

FPS メーターも便利なツールです。ページの実行中に FPS のリアルタイム推定値を確認できます。

Command+Shift+P（Mac）または Ctrl+Shift+P（Windows、Linux）を押してコマンドメニューを開きます。
コマンドメニューで「Rendering」と入力し、[レンダリングを表示] を選択します。
[Rendering] パネルで、[Show Rendering stats] を有効にします。ビューポートの右上に新しいオーバーレイが表示されます。
FPS メーターを無効にし、Esc キーを押して [Rendering] パネルを閉じます。このチュートリアルでは使用しません。

ボトルネックを特定する

アニメーションのパフォーマンスを測定して確認したところで、次は「なぜか？」です。

[概要] タブに注目します。イベントが選択されていない場合、このタブにはアクティビティの内訳が表示されます。ページのレンダリングにかかる時間が長い。パフォーマンスとは、負荷を回避することであり、あらゆる作業の効率を可能な限り高めることに関連します。
[メイン] セクションを開きます。DevTools には、メインスレッド上のアクティビティのフレームチャートが時系列で表示されます。X 軸は時間の経過に伴う録音を表します。各棒はイベントを表します。バーが長いほど、イベントに時間がかかったことを示します。Y 軸はコールスタックを表します。イベントが重ねて表示されている場合、上のイベントが下のイベントの原因であることを示します。
記録に含まれているデータが大量にあります。[概要]（FPS、CPU、NET のグラフを含むセクション）をクリックしてマウスを長押しし、ドラッグして、単一の Animation Frame Fired イベントを拡大します。[Main] セクションと [Summary] タブには、記録の選択された部分に関する情報のみが表示されます。

ヒント: WASD を使用して録画を移動することもできます。メインセクションの背景をクリックするかイベントを選択してフォーカスを合わせます。フォーカスは、W キーで拡大、S キーでズームアウト、A キーで左スクロール、D キーで右スクロールできます。
Task イベントとレイアウトイベントの右上にある赤い三角形に注目してください。赤い三角形が表示された場合は、このイベントに関連する問題が発生している可能性があることを警告しています。タスクに赤い三角形が表示されている場合は、長いタスクだったことを意味します。
[Animation Frame Fired] イベントをクリックします。[Summary] タブに、そのイベントに関する情報が表示されます。[Initiated by] の横にあるリンクをクリックすると、[Animation Frame Fired] イベントを開始したイベントが DevTools でハイライト表示されます。また、app.update @ リンクもメモします。クリックすると、ソースコード内の関連する行に移動します。

注: イベントを選択したら、矢印キーを使用してその隣のイベントを選択します。
[app.update] イベントの下に、紫色のイベントが多数あります。幅が広い場合は、各行に赤い三角形が表示されているように見えます。紫色の [レイアウト] イベントのいずれかをクリックします。DevTools の [概要] タブには、イベントの詳細が表示されます。実際には、強制リフロー（レイアウトの別名）に関する警告が表示されます。
[Summary] タブで、[First Layout Invalidation] の [app.update @] の横にあるリンクをクリックします。レイアウトを強制したコード行が表示されます。

注: このコードの問題は、各アニメーションフレームで各スクエアのスタイルを変更し、ページ上の各スクエアの位置をクエリすることです。スタイルが変更されたため、ブラウザは各正方形の位置が変更されたかどうかを認識できないため、正方形の位置を計算するために正方形を再レイアウトする必要があります。詳しくは、強制同期レイアウトを回避するをご覧ください。

ぜひここまでの内容は多岐にわたりましたが、これでランタイムパフォーマンスを分析するための基本的なワークフローの基礎を学びました。これで完了となります。

ボーナス: 最適化されたバージョンを分析する

学習したワークフローとツールを使用して、デモで [最適化] をクリックして最適化されたコードを有効にし、別のパフォーマンスレコーディングを取得して結果を分析します。フレームレートの向上から、[Main] セクションの炎グラフでのイベント数の減少まで、最適化されたバージョンのアプリでは処理が大幅に減り、パフォーマンスが向上していることがわかります。

注: この最適化されたバージョンでも、各スクエアの top プロパティが操作されるため、あまり効果的ではありません。合成にのみ影響するプロパティに限定することをおすすめします。詳しくは、アニメーションの形状と不透明度の変更の使用をご覧ください。

次のステップ

パフォーマンスを理解するための基盤となるのが RAIL モデルです。このモデルは、ユーザーにとって最も重要なパフォーマンス指標を示します。詳細については、RAIL モデルのパフォーマンスを測定するをご覧ください。

パフォーマンスパネルを使いこなすには、実際に使ってみることが大切です。独自のページをプロファイリングして結果を分析してみてください。結果についてご不明な点がございましたら、google-chrome-devtools タグを付けて StackOverflow で質問を投稿してください。可能であれば、再現可能なページのスクリーンショットまたはリンクを添付してください。

ランタイムパフォーマンスのエキスパートになるには、ブラウザが HTML、CSS、JS を画面上のピクセルに変換する仕組みを学ぶ必要があります。まずは、レンダリングパフォーマンスの概要をご覧ください。フレームの構造では、さらに詳しく説明しています。

最後に、実行時のパフォーマンスを改善する方法はたくさんあります。このチュートリアルでは、パフォーマンスパネルの詳細なツアーを提供するために、特定のアニメーションボトルネックについて説明しましたが、これは遭遇する可能性のある多くのボトルネックの 1 つにすぎません。レンダリングパフォーマンスシリーズの残りのパートでは、次のようなランタイムパフォーマンスのさまざまな側面を改善するための多くのヒントを紹介しています。