この前、ChromeのDevToolsでできることを調べてみたが、その時はNetworkパネルとPrerformanceパネルの違いがあまりよくわからなかったので、改めてまとめてみることにする。
まずは、RaiseTechの授業で質問。
こうやって実際に聞ける環境があるというのが、本当にイイ。
NetworkはHTTPリクエストの中身(通信内容)を見るのによく使うし、Performanceはその名の通りパフォーマンスを見るのに使うらしい。先生はPerformanceよりも、Networkのほうをよく使うんだって。
一緒に受講している受講生さんが、阿部寛のHPがNetwork確認するのにわかりやすいよって教えてくれた。(ありがとうございます！！)
ホントだ。すごいシンプルなサイトなので、めちゃくちゃわかりやすいw
こういう情報をポンっと教えてもらえるのも、学校形式のメリットかも。
改めて、NetworkパネルとPerfoemanceパネルでできることを、今回はより具体的にまとめてみる。
Networkパネル
例によって、阿部さんのページで確認ww
わー。シンプル。
では早速見ていきましょう。
まずは、パネル上部のグラフから。
青い線：DOMContentLoaded
最初のHTMLの読み込みと解析が完了したタイミング(CSSとか画像とか読み込む前)。
この画像だと、151ms。
赤い線：Load
全リソースのロード完了タイミング。
この画像だと548msかかっている。
画面下半分の一覧表は、発生したHTTPリクエスト一覧。
Name
リソースのファイル名
Status
HTTPのステータスコード。
今回の場合は、すべて「200 OK」なので、すべてのリクエストが正常に処理されましたよってこと。
Type
MIME(Multipurpose Internet Mail Extentions)タイプ。
例えば、HTMLなのかJavaScriptなのか、というファイルの形式や性質を表す情報。
ブラウザは、URLを処理する方法を決めるときに、ファイルの拡張子ではなく、MIMEタイプを使用するらしい。
なので、Webサーバー側は、ブラウザに正しく表示させるために、レスポンスとしてMIMEタイプを返す必要がある。
Initiator
どこからファイルが呼び出されているか？といった、ファイルを呼び出す起点となるファイル。
Size
サイズ。(レスポンスヘッダーと中身)
Time
ダウンロードにかかる時間。
重い画像など、ここで時間がかかっているかどうか確認することができる。
リクエストをクリックすることで、さらに詳細な情報を見ることができる。
Headers
HTTPリクエスト・レスポンスヘッダ。
画面が上手く表示されない場合なんかは、正しいHTTPリクエストとレスポンスが返ってきているかの確認をするときになんかに使う。
ここ一番使いそう。
Preview
プレビュー。
画像などの場合は、ここに画像が表示される。
Response
HTTPリクエストに対して、返ってきたHTTPレスポンス本体。
HTMLやJavaScriptが表示される。
Initiator
さっきも書いた通り、どこから呼ばれたかの起点がツリーで見ることができる。
Timing
ファイルをロードするのにかかった時間をグラフで表示。
- Queueing：処理待ちのためキューに溜まっていた時間(優先度が低い場合など)
- Stalled：リクエストが送信できるようになるまでの待機時間
- DNS Lookup：DNS参照にかかった時間
- Initial Connection：TCPやSSLなどの接続の確立にかかった時間
- Request sent：TCP確立後にリクエストを出す時間(とても短い)
- Waiting(TTFB=Time to First Byte)：最初のバイトデータを受け取るまでの時間
- Content Download：レスポンスデータにかかった時間
この部分が「Network」パネルといわれる所以か。
ページの表示が遅い場合に、ネットワークのどのあたりに原因があるのかの当たりを付けられる。
DNSの参照に時間がかかっているのか、セッションの確立に時間がかかっているのか、はたまた、サーバーが遅延してデータの受信に時間がかかっているのか、そもそもデータ自体が重くて時間がかかっているのか・・・などの情報がここから読み取れる。
Performance
これは逆に阿部さんのページだと変化が少なすぎてわかりにくいので、自分のブログで確認。(このあたりからも、NetworkとPerformanceの使い分けの違いが出るところだ。)
画面全体はこんな感じ。
まずは、Performanceパネルの上側のグラフエリアから。
FPS
Frame per Second(1秒間に何フレーム表示させたか)。
一般的なディスプレイのリフレッシュレートは60FPSなので、1フレーム16.7ms以上かかっていると、表示が遅いとかカクカクするとか感じてしまうのかもしれない。
緑色のグラフが大きい(背が高い？)ほど、FPSが高い。つまり、感覚的にはなめらかということだ。
赤い部分は、FPSが低いところ、つまりフレームを表示させるのに時間がかかっているところ。(改善ポイント。)
緑色のグラフのFPSは、1フレーム当たり何msという数値として、中央当たりのグラフに表示されている。
基準値を下回っている。(無念・・・)
CPU
グラフの高さがCPUの負荷の高さを示す。
色によってCPUを使っている処理(リソース)がわかるようになっていて、
- 青色 ： Loading(HTTPリクエストやHTMLのパース処理)
- オレンジ：Scripting(JavaScriptで行われた処理)
- 紫色 ：Rendering(スタイルの評価やレイアウト算出)
- 緑色 ：Painting(ペイント処理や画像のラスタライズ)
- グレー ：Other(その他)
この色と一致している。
NET
ネットワークの通信状態を示す。
濃い目の青が優先度が高いリソースへのリクエスト、薄めの青は優先度が低いリソースへのリクエストになる。
Networkの帯の左上の小さな■の色で優先度がわかる。
HEAP
JavaScriptのヒープ領域のメモリ使用量。
ここがぐんぐ上がり続けていたら、メモリリークしてる。
次に、Performanceパネルの中央付近の詳細なグラフエリア。
Network
リソースごとに色分けされているが、種類については前述の通り。
よくよく見ると、最大値・最小値・四分位範囲を表現する箱ひげ図のようになっている。
これにはちゃんと意味があって、
- 左側のグレーの線：リクエストを送信するまでの時間(優先度が低いとか、サーバーとの接続に時間がかかったりするとこの線が長くなる)
- 薄い緑の帯：TTFB＝リクエストを送信してから最初のデータを受信するまでの時間(サーバーが重かったりすると、この帯が長くなる)
- 濃い緑の帯：TTFB後、すべてのデータを受け取るまでの時間(画像が大きくて重い場合などは、この帯が長くなる)
- 右側のグレーの線：データをすべて受信しきった後、メインスレッドがデータを処理するまでの時間(優先度が低くて、メインスレッドが別のことをやっていると、この線が長くなる)
Frame
NETのところで触れたので、省略。
Interactions
Web描画に関する指標のいくつかが確認できる。
例えば、この図を例にすると、以下の指標のタイミングがわかる。
- FP：First Paint(最初の描画)
- FCP：First Contentful Paint(最初のコンテンツ描画)
- DCL：DOM Content Loaded(最初のHTML文書の読み込みと解析が完了)
- LCP：Largest Contentful Paint(最大コンテンツの描画)
また、Layout Shiftとは、ユーザーが意図しないレイアウトのずれのこと。
このページでもいくつか起こっている模様。(そうなんだ・・・)
原因としては、サイズ指定のない画像を埋め込んだり、Webフォントを読み込んだりするときにおこることがあるらしい。
Webフォントを使うときには、そういうのが起こらないように注意して、最適化を行う必要があるんだって！(へ～！)
Main
メインスレッドの処理を実行している時間。
これもリソースごとに色分けされているが、種類については前述の通り。
NetworkとMainを組み合わせることで、より細かい分析が可能になる。
例えばこの画像だと・・・、
CSSとWebフォントをダウンロードして、メインスレッドでHTMLのパース処理をして、レンダリングした後に、ペイント処理をしているのがわかる。
こういう確認をして、あまりにも時間がかかっている処理があれば、改善項目になるっていう感じかな。
それ以外にも、Raster、GPU、・・・などまだまだイロイロあるが、この辺でやめとく。
(疲れたｗ)
使う機会があったときに必要に応じて追記する。
結局、NetworkパネルとPerformanceパネルの違いとは？
なんで違いがあまりないと思ってしまったのか自分を疑うくらい、違ってたｗｗ
そもそもの目的が違うわ。
Networkパネルは、ページのリクエストが要求されてから表示されるまでに行われたHTTP通信の内容、ファイルサイズやロードまでにかかった時間などを調べるときに使う。
例えば、
- ページの表示が遅くなっている原因を特定
- ページが表示されない場合などに、HTTP通信のリクエスト・レスポンス内容の確認(エラーコードも重要な手がかり)
とか。(ほんの一例だけど)
Networkっていう言葉がしっくりこないんだよなぁ。
「HTMLリクエスト・レスポンス」パネルでいいじゃん。長いけど。
Performanceパネルは、ほんとそのまんまだけど、性能評価的な感じ。
- ページの読み込みとか描画が遅い原因の特定
- メモリリークを特定
CPU負荷やHeap領域の確認など、Networkパネルで確認できることよりも幅広い視点で調査できるツールであった。
構造が複雑になればなるほど、DevToolsを使いこなせるかどうかが効いてくる。
やっぱり触ってみないとだめだなぁ。
かるーく、表面的に調べてわかった気になってることは、やっぱりわかってないんだと反省。
と、いうわけで、すっきり解決。
ようやく次の課題に着手できそう。
