🔧

Chrome の devtools を使いこなす Part3 | パフォーマンス編

2024/05/11に公開

はじめに

今回は devtoolsを使いこなせるようになろうPart3、パフォーマンスパネル編です.
(各パートごとに紹介する内容を分けているので、Part1を読んでなくても大丈夫です！)

この記事は、devtools のドキュメントを参考にしています.
(参考)

歯車アイコン > CPU から throttling でCPUのパフォーマンスを落としてシミュレーションできるようになる
録画アイコンでページをキャプチャする
- 停止する
- Screenshotsのチェックボックスをonにして実行すると、各フレームにおける画面の表示を確認できる
- FPS, CPU, NETグラフの任意の場所にカーソルを合わせると、合わせた位置におけるページのスクリーンショットが表示される
Cmd+Shift+p でコマンドメニューを開き、Renderingと入力 Show Renderingを選択
- Frame Rendering Stats を有効にすると、fps の値を画面に常時表示できる

CPUのところで、赤色のバーが表示されていると、FPSが低くUXに悪影響がある

パフォーマンスが悪くなってる
Summaryを見て、フルカラー表示だった場合は、CPUの最大値が続いていたことを意味する

計測中、常にCPUが動いていたことが分かる

Idle状態が大半を占めているため、パフォーマンスがいい
↑から紫色のRendering時間が大半を占めていることが分かる
- これを減らせたら良さそうという指針ができる
- ↓Mainセクションの各バー=イベントの幅が広いほど、イベントに時間がかかってる. Y軸はコールスタック
  
  Mainセクションのイベント
↓イベントの右上に赤い三角が付いていたら、問題が発生している可能性があることを警告している
- イベントをクリックすると、Warning 内容を確認できる
- 該当のソースコードへのリンクも見れる
  - 該当箇所がパフォーマンスのボトルネックとなっているので、改善する
    
    赤い三角の警告

RAILとは、Response Animation Idle Loadの略で、UXを主要なアクションに分割し、各アクションのパフォーマンス目標を定義しています.

ここでは、目標だけ紹介します！

60FPS (1フレーム16ms)でレンダリングされていると、滑らかであると認識される
0-100ms 以内に応答すると、即座に結果が得られると感じる
100-1000ms: ページの読み込みや表示の変更はこれぐらいかかっても大丈夫 (早いに越したことはない)
- 1000ms 以上: ユーザーは集中できなくなる
- 10,000ms 以上: ユーザーは離脱する

より詳しい情報はこちらのページに書いてあります.

今回は、パフォーマンスパネルの使い方と、記録の見方を紹介しました！
パフォーマンス改善の方針から、改善方法まで分かったと思います.

パフォーマンスパネルに関するドキュメントには、他にもさらに詳細な情報が載っているので、ぜひ一度見て見てください！