Chrome のネットワークタブから学べること

Chrome のネットワークタブは、ウェブサイトが遅く感じられる理由を明らかにします。コードが完璧であっても、1枚の巨大な画像や動作の遅い API エンドポイントがユーザー体験を台無しにする可能性があります。このパネルを理解することで、パフォーマンスの問題を推測する段階から、正確に診断できる段階へと成長できます。

ネットワークウォーターフォール分析の理解

Chrome DevTools のネットワークパネルにあるウォーターフォールチャートは、ページ読み込みのミリ秒単位の物語を語ります。各横棒は、リクエストの開始から完了までの過程を表しています。色は装飾ではなく、重要なタイミング情報をエンコードしています。

緑色のセグメントは待機時間(TTFB - Time to First Byte)を示し、サーバーが応答するまでの時間を表します。青色はコンテンツのダウンロード時間を表します。緑色が支配的な場合、サーバーがボトルネックです。青色が支配的な場合、大きなリソースまたは帯域幅の制約に直面しています。

最近のブラウザは複数のリクエストを同時に実行し、ウォーターフォール内に並列の棒を作成します。HTTP/2 接続はこの並列化を増幅し、単一の接続で数十のリクエストを可能にします。階段状のパターンに注目してください。これらは、あるリソースが別のリソースをブロックする依存関係チェーンを明らかにし、読み込み戦略を再構築する機会を示していることがよくあります。

TTFB とダウンロード時間のボトルネックの区別

ウェブパフォーマンスのデバッグは、遅延がサーバーから来ているのか、ネットワークから来ているのかを特定することから始まります。任意のリクエストをクリックして、Timing タブを確認してください。「Waiting (TTFB)」が 200ms を超える場合は、バックエンドを調査してください。データベースクエリ、API ロジック、またはサーバー構成の最適化が必要な可能性があります。

ダウンロード時間が長い場合は、異なる解決策を示しています。5MB の JavaScript バンドルは、光回線では瞬時に読み込まれるかもしれませんが、モバイルネットワークでは遅くなります。Size 列には、転送サイズ(圧縮済み)と実際のサイズ(非圧縮)の両方が表示されます。これらの数値が大きく異なる場合、圧縮が正常に機能しています。似たような数値の場合、gzip または Brotli を有効にすることで、パフォーマンスが劇的に向上する可能性があります。

接続のオーバーヘッドは、タイミングの内訳に DNS Lookup、Initial Connection、SSL ネゴシエーションとして表示されます。初回訪問者はこれら3つすべてを経験しますが、再訪問者は通常、接続の再利用によってこれらをスキップします。同じドメインへの複数のリクエストは接続を共有する必要があります。共有していない場合、ラウンドトリップを無駄にしています。

実際の環境をテストするためのネットワークスロットリングの使用

開発マシンのギガビット接続は、パフォーマンスの問題を隠蔽します。Chrome のネットワークスロットリングは、現実的な条件をシミュレートします。スロットリングドロップダウンから「Slow 3G」または「Fast 4G」を選択して、モバイルユーザーと同じようにサイトを体験してください。

スロットリングはリソースの競合を明らかにします。帯域幅が不足すると、Priority 列が重要になります。ブラウザは、レンダリングをブロックするリソースに Highest 優先度を割り当て、表示される画像に High、スクロール下のコンテンツに Low を割り当てます。優先度の不整合(トラッキングピクセルが High 優先度など)は、貴重な初期帯域幅を無駄にします。

カスタムスロットリングプロファイルを使用すると、特定のシナリオに合わせることができます。ユーザーの最良のシナリオではなく、中央値の接続品質をシミュレートするために、ダウンロード/アップロード速度とレイテンシを設定してください。

HTTP リクエストと API レスポンスのデバッグ

Chrome DevTools のネットワークパネルは、HTTP リクエストのデバッグに優れています。失敗したリクエストは赤色で表示され、すぐに注意を引きます。クリックしてヘッダーを検査すると、CORS エラー、認証の失敗、または不正なリクエストが明らかになります。

Response タブには実際のサーバー出力が表示されます。これは、API が 200 ステータスコードにもかかわらず、レスポンスボディにエラーメッセージを返す場合に非常に有用です。Preview タブは、JSON レスポンスを読みやすい折りたたみ可能なツリーでレンダリングし、複雑な API レスポンスをナビゲート可能にします。

リクエストイニシエーターは因果関係を明らかにします。Initiator 列にカーソルを合わせると、完全なコールスタックが表示されます。これにより、問題を発生源まで追跡できます。その 404 エラーは、あなたのコードではなく、サードパーティのスクリプトから発生している可能性があります。

特定のリソースのフィルタリングと分離

Filter 入力は高度なクエリを受け付けます。larger-than:100k と入力すると、肥大化したリソースを見つけることができます。-domain:yourdomain.com を使用して、サードパーティのリクエストを分離します。/\.(jpg|png|gif)/ のような正規表現で関連するリソースをグループ化します。

Fetch/XHR フィルタリングは、API 呼び出しをアセット読み込みから分離します。これは、アプリケーションロジックとパフォーマンスの問題をデバッグする際に不可欠です。検索機能(Cmd+F)は、すべてのレスポンスボディとヘッダーを検索します。機密データが漏洩する可能性のある場所を見つけたり、特定の API レスポンスを追跡したりするのに最適です。

実践的なパフォーマンスインサイト

Coverage タブ(DevTools メニューからアクセス可能)は、ネットワークデータにコード使用統計をオーバーレイします。2MB の JavaScript バンドルは、初期読み込み時にコードの 30% しか使用していない可能性があります。これは、コード分割を実装する明確なシグナルです。

HAR(HTTP Archive)エクスポートは、WebPageTest などの専門ツールでの分析やチームメンバーとの共有のために、ネットワークセッション全体をキャプチャします。任意のリクエストを右クリックして「Copy as cURL」を選択すると、ターミナルや Postman で正確なリクエストを再現できます。

まとめ

Chrome のネットワークタブは、謎めいたパフォーマンスの問題を実行可能なインサイトに変換します。ウォーターフォールチャートをマスターし、タイミングの内訳を理解し、スロットリングを使用してユーザーの接続を通してサイトを見てください。これらのスキルは、サイトが速いことを願う開発者と、なぜ速いのか(または速くないのか)を正確に知っている開発者を区別します。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.