Chrome Dev Tools を使用してページのパフォーマンスを分析する方法 (フロントエンドのパフォーマンス最適化)

背景

開発やデバッグには Chrome Dev Tools がよく使用されますが、ページのパフォーマンスを分析するために Chrome Dev Tools を使用する方法を知っている人はほとんどいません。この記事では、ページのパフォーマンス分析に Chrome Dev Tools を使用する方法と、パフォーマンスレポートデータを解釈する方法について詳しく説明します。

分析パネルの紹介

上の画像は Chrome Dev Tools のスクリーンショットです。画像で丸で囲まれたモジュールの機能は、主にページのパフォーマンスを素早く分析するために使用されると思います。簡単に紹介します。

ネットワーク: ページ上のさまざまなリソース要求。ここでは、リソース名、ステータス、使用されているプロトコル (http1/http2/quic...)、リソースタイプ、リソースサイズ、リソースタイムラインなどを確認できます。
パフォーマンス: ページのさまざまなパフォーマンス指標のフレームチャート。白画面時間、FPS、リソース読み込みタイムライン、ロングタスク、メモリ変更曲線などの情報を確認できます。
メモリ: 特定の瞬間のページメモリの状態を記録できます。通常はメモリリークの分析に使用されます。
JavaScriptプロファイラ：関数の消費時間を記録できるので、より多くの時間を消費する関数を見つけやすくなります。
レイヤー: ページ内のレイヤーを表示します

分析手順

まず、分析を行う際には、プラグインなどの要素がページのパフォーマンスに与える影響を排除するために、シークレットモードでページを開くことをお勧めします。次に、ページキャッシュのチェックを外してキャッシュが無効になっている状況をテストし、ネットワーク条件を調整します。コンピューターを使用してページを開くときは、通常、Wi-Fi などに接続されています。ページのパフォーマンスをより現実的にテストするには、図に示すように、ネットワークを 3G などに調整することをお勧めします。

調整後、パフォーマンスパネルに切り替えます。以下に、機能を説明するボタンをいくつか示します。

上の図は、左から右に次のものを表しています。

手動で録画を開始し、開始後に手動で終了する必要があります
ページを自動的に再起動し、ページの読み込みプロセス全体を記録します。これは最もよく使用されるものです。通常、ページのパフォーマンスを分析する場合は、これをクリックするだけです。
明確なパフォーマンス記録
ページパフォーマンス記録データをアップロードする
ページパフォーマンス記録データをダウンロード
表示するパフォーマンスレコードを選択します。複数の分析を実行した可能性があります。ここで切り替えて、各分析の結果を表示できます。
ページの読み込みプロセスのスクリーンショットをキャプチャするかどうか。通常はチェックされています
メモリの変更を記録するかどうか、通常はチェックされている
ガベージコレクション、クリックするとガベージコレクションが実行されます

ここでは、JD.com のページを例に、キャッシュの無効化をチェックし、Fast 3G ネットワークを使用して、パフォーマンス結果を理解し、最適化ポイントを見つける方法を説明します。

ネットワークパネルから分析する

利用可能な情報を確認するには、ネットワークパネルを見てみましょう。次の図に示すように:

図からわかるように、ページ上のパフォーマンス最適化方法は次のとおりです。

ページはすぐに表示されます。https https://wq.jd.com/wxportal/index_v6と入力すると、ページによって読み込まれたドキュメントはレンダリングされたHTMLページです。
画像の最適化、異なる CDN ドメイン名での展開、webp/dpg およびその他の形式の画像の使用、画像の切り取りなど。
一部のhttpプロトコルは、リソースの読み込みを高速化するためにhttp2の多重化を使用しています。
小さなロゴはbase42を使用して処理されます
オンデマンドでロードすると、メニューは最初に最初の画面のアイコンをロードし、次に2番目の画面にスライドすると2番目の画面のアイコンをロードします。

写真から判断すると、パフォーマンス最適化方法として次のような方法も考えられます。

html のサイズは 138kb で、コンテンツのダウンロード時間は 700 ミリ秒以上です。ページを分割して、1 画面または 2 画面を占めないコンテンツを個別に読み込むことができると思います。
TTFB (Time To First Byte) が 500 ミリ秒を超えている場合、最初のバイトをダウンロードするまでの待機時間が長すぎることを意味します。ただし、これは主にユーザーのネットワーク状況によって影響を受けるため、これについてできることはあまりありません。 DNS 解決の最適化、バックエンドサービスの処理時間の短縮など。
スプライト画像を結合します。大きなカルーセルの下のメニューカテゴリのアイコンは、スプライト画像を使用してグループ化できます。
上部のカルーセルの場合、初めて読み込むときに、画像の最初のフレームを最初に読み込み、次の数フレームを遅らせることができます。
写真が多数ある場合は、可能であれば http2 プロトコルを使用してください。

パフォーマンスパネルから分析する

パフォーマンスパネルに切り替えて、ページの自動再起動をクリックし、ページの読み込みプロセス全体を記録して、結果を分析します。

ネットワーク&&ホワイトスクリーン

パフォーマンスパネルには数多くのパラメーターがありますが、ここではより一般的なパラメーターのいくつかを見ていきます。まず、以下に示すように、白い画面の時間とネットワークの読み込みステータスを確認します。

上の写真では、いくつかの情報を見ることができます。

このページの読み込みにかかる白い画面の時間は約1000ミリ秒です
FPS 曲線は赤くマークされていません。赤い線が多数ある場合、ページのレンダリング遅延が多いことを意味します。
ネットワークリソースの読み込み状況から判断すると、画像はhttp2を有効にしていないため、同時に読み込むことができる画像の数は限られており、読み込まれていない画像には待機プロセスがあります。
リソースの読み込み時間も確認できます。たとえば、カルーセルの背景画像の読み込みには約 700 ミリ秒かかり、少し長いです。

また、リソースのロードに空白期間があるかどうかも確認できます。上図では空白期間はありませんが、リソースのロードの間に空白期間がある場合は、リソースのロードのアイドル時間が十分に活用されていないことを意味し、調整が可能です。

フレームグラフ

フレームグラフは主にメインパネルにあります。これは、特定の関数の時間消費を分析するために最もよく使用されるパネルです。図に示すように、それを見てみましょう。

まず、パネルには多くのタスクがあります。時間のかかるタスクであれば、右上隅が赤くマークされます（画像には表示されませんが、これはページの最初の画面の論理処理が適切に分散されていることを意味します）。このとき、赤くマークされたタスクを選択し（ここで 1 つを選択するだけです）、拡大（選択してマウスをスライドして拡大）すると、その特定の時間のかかるポイントを確認できます。

拡大すると、実行されている操作と各関数にかかる時間を確認できます。ここのコードは圧縮されており、圧縮された関数名を確認できます。次に関数をクリックすると、パネルの下部に、その関数が何であるか、どのくらいの時間がかかるか、どのファイルのどの行であるかなどのコード情報が表示されます。この方法では、時間のかかる機能を簡単に見つけることができます。

タブを水平に切り替えてコールスタックやその他の情報を表示することもできるため、対応するコードを見つけやすくなります。ぜひお試しください〜

タイムラインとメモリの状態

「タイミング」領域では、この読み込みの主要な時間を確認できます。

FCP: 初めてのコンテンツペイント
LCP: 最大のコンテンツペイント
FMP: 最初の意味のあるペイント
DCL: DOMContentLoaded イベント
L: オンロードイベント

領域を選択して（今回はページの読み込みプロセスを表す白い画面からコンテンツのある領域までの領域を選択）、上記の時間と比較することができます。スクリーンショットは次のとおりです。

また、JS ヒープなどのページ内のメモリ使用量も確認できます。曲線が伸び続ける場合は、メモリリークが発生していることを意味します。図からわかるように、メモリ曲線は長い間下がっていません。メモリリークの可能性があります。メモリは Onload 後に解放されます。メモリリークの詳しい原因と分析方法については、私の記事「Chromeブラウザのガベージコレクションの仕組みとメモリリークの分析」を参照してください。

下部には、ページの時間消費の概要が表示されます。スクリプト時間が長すぎる場合は、js がロジックを実行しすぎていることを意味するため、js の最適化を検討できます。レンダリング時間が長すぎる場合は、レンダリングプロセスの最適化を検討してください。アイドル時間が長すぎる場合は、ページのアイドル時間にいくつかのレポート操作を入れてからレポートするなど、アイドル時間を最大限に活用することを検討できます。

その他のパネル

上記は、パフォーマンスパネルで表示できる情報の一部です。さらに、レイヤーパネルを使用して、ページのレイヤーの 3D ビューを表示できます。レンダリングパネル (その他のツール -> レンダリングをクリックして開きます) で、レイヤーボーダーをチェックして、合成レイヤーと RenderLayer 領域を確認します。これは、アニメーションの詰まりを分析したり、GPU アクセラレーションをオンにするかどうかなどを調べるのに役立ちます。メモリパネルと JavaScript プロファイラーパネルは、主にメモリリークを分析するために使用されます。ここではそれらについては説明しません。別の記事「Chrome ブラウザのガベージコレクションメカニズムとメモリリークの分析」をお読みください。

監査ツールで分析する

Audits は実際には LightHouse であり、Google のオープンソースの自動テストツールです。一連のルールに従って Web ページを評価および分析し、最終的に評価レポートを生成します。パネルは次のようになります。

全体的な状況

監査では主に 5 つの側面に基づいて Web ページにスコアを付けますが、もちろん評価の特定の側面を除外することもできます。デバイス、評価の側面、ネットワークの状態、その他のオプションを選択した後、「監査の実行」をクリックするとレポートが表示されます。

上の図は全体的なレポートです。このページのパフォーマンスが標準に達していないことがわかります。もちろん、単一のテストでは何も説明できず、参考としてのみ役立ちます。パフォーマンス指標を見てみましょう。

最初のコンテンツペイント: コンテンツが初めてペイントされます。
最初の意味のあるペイント: これは、ユーザーが Web ページのメインコンテンツを表示するのにかかる時間として簡単に理解できます。スコアが低いほど、ページのメインコンテンツの表示が速くなります。図の例では、Web ページの最初の実効描画時間は 2.5 秒です。
スピードインデックス: スピードインデックスは、ページコンテンツがどの程度速く読み込まれるかを示すページ読み込みパフォーマンスインジケーターです。このメトリックのスコアが低いほど、優れています。
最初のCPUアイドル: 最初のCPUアイドル時間
インタラクティブになるまでの時間: ページ内のほとんどのネットワークリソースの読み込みが完了し、CPU が長時間アイドル状態になるまでに必要な時間。このとき、CPU は非常にアイドル状態であり、ユーザーインタラクション操作をタイムリーに処理できることが期待できます。
最大潜在的初回入力遅延: 最大入力遅延時間。入力応答性は、ユーザーがアプリケーションのパフォーマンスをどのように認識するかに重要な役割を果たします。アプリケーションは、ユーザー入力に応答するのに 100 ミリ秒かかります。これより時間がかかると、ユーザーはアプリが応答していないと認識します。

これらの時間については、画像内の赤いボックスをクリックして表示モードを切り替えることができます。対応する時間の説明が添付され、「詳細を見る」をクリックすると詳細なインジケーターの紹介が表示されます。この文書では、各指標は、このレビューが重要な理由、このレビューに合格する方法、このレビューを達成する方法の 3 つの部分に明確に分割されています。

パフォーマンス指標の最適化提案の解釈

パフォーマンスの推奨事項は、主に機会（最適化可能な項目）、手動診断項目、承認済みレビュー項目の 3 つのカテゴリに分けられます。例は次のとおりです。

図内の各項目を展開すると、次のような詳細な説明が表示されます。

最適化には 2 つの提案があります。

遅延によりリソース読み込みのレンダリングがブロックされます。ここに navfoot.6bf68af7.css があります。
ビューポート外の画像の読み込みを遅らせます。読み込む必要のない画像は次のとおりです（これは、上で述べた最適化の提案と一致しています、笑）

この項目の内容は、LightHouse が直接最適化できると発見したいくつかのポイントを示しています。それに応じて最適化することができます。

手動診断項目には 6 つの提案があります。

メインスレッドの作業を最小限に抑える
JavaScriptの実行時間を短縮する
DOMが大きくなりすぎないようにする
効果的なキャッシュ戦略を通じて静的リソースをキャッシュする
重要なリクエストの連鎖を避ける
リクエスト数と転送サイズを低く抑える

これらの項目は、LightHouse が現在の状況が良いか悪いかを判断することはできませんが、詳細がリスト化されており、各項目の状況を手動で確認することができます。

合格したレビュー項目

ここに良い点をリストします。この記事には 16 の例があります。ただし、それらがうまくできているとしても、注意深く見る価値はあります。すべてのエントリと同様に、ここにある各エントリにも showmore があり、クリックしてその背後にある知識と原則を注意深く学ぶことができます。

アクセシビリティ

アクセシビリティとは、「通常の」ユーザーの範囲外にあり、予想とは異なる方法で Web ページにアクセスしたり操作したりするユーザーのエクスペリエンスを指します。この記事の例では、次の図が示されています。

アクセシビリティカテゴリでは、スクリーンリーダーやその他の支援技術がページで適切に動作するかどうかをテストします。たとえば、要素に応じて属性を使用するか、タグが標準化された方法で使用されているか、img タグに alt 属性が欠けているかどうか、認識可能な要素名などです。この項目については詳しく説明しません。ただし、監査の推奨事項に従って Web ページを変更することをお勧めします。

その他の項目については、この記事の例のベストプラクティスが高く評価されていますが、例はPWAをサポートしておらず、SEOを考慮する必要がないため、ここでは詳しく説明しません。該当するニーズがある場合は、詳細を確認してください。

要約する

最後にまとめると、Chrome Dev Tools を使用してページのパフォーマンスを分析し、次の指標を参考にしています。

ネットワークパネルから分析する
パフォーマンスパネルから分析する
メモリパネルなどからメモリリークを分析します。
監査ツールで分析する

これらの分析方法については、この記事で詳しく説明します。真剣に見てもいいですよ〜

これで、Chrome Dev Tools を使用したページパフォーマンス分析 (フロントエンドパフォーマンス最適化) の手順に関するこの記事は終了です。Chrome Dev Tools のページパフォーマンスに関する関連コンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: