Core Web Vitals向けのChrome DevToolsネットワークパネル設定
すべてのCore Web Vitals監査で私が使用しているネットワークパネルの設定
Chrome DevToolsのNetworkパネルは、Core Web Vitalsのデバッグに最も役立つツールの1つです。しかし、デフォルト設定では必要な情報の半分が隠れています。すべての監査で私がどのようにNetworkパネルを設定しているかを紹介します。
最終レビュー：2026年3月、Arjen Karel
Table of Contents!
Networkパネルの設定
Networkパネルにアクセスするには、Chrome DevTools（F12またはCtrl+Shift+I）を開き、「Network」タブをクリックします。
Throttling
訪問者はオフィスのWi-Fiを使っているわけではありません。世界的に見ると、モバイル接続の30%は依然として3Gであり、55%は4Gです（GSMA Mobile Economy 2025）。ネットワークのスロットリング機能を使うと、ユーザーと同じ環境を再現できます。
Networkパネルの「No throttling」ドロップダウンをクリックします。「Fast 4G」、「Slow 4G」、または「3G」を選択して、モバイルネットワークの条件をシミュレートします。最適な選択肢は対象のユーザーによって異なります。ユーザーが主に高速なネットワーク環境でハイエンドのモバイルデバイスを使用している場合は、「Fast 4G」を有効にします。一般的なネットワーク環境がやや劣る場合は、「Slow 4G」を選択します。それ以外の場合は、安全を見て「3G」を選択します。
個別のリクエストのスロットリング（Chrome 145以降）
2025年12月以降、ページ全体ではなく単一のリクエストをスロットリングできるようになりました。Networkパネルで任意のリクエストを右クリックし、「Throttle request」を選択します。これにより、「サードパーティのスクリプトの読み込みが遅い場合、LCPはどうなるか」、「CDNは遅いがユーザーの通信速度は速い場合、ページはどう動くか」といった疑問に答えることができます。単一のリソースがパフォーマンスに与える影響を切り分けるための最速の方法です。
キャッシュの無効化
初めての訪問者が体験する状態と同じ条件でサイトをテストするために、Networkパネルの「Disable cache」チェックボックスをオンにします。
Big request rowsの有効化
Big request rowsを有効にすると、デフォルトのコンパクトビューでは隠れている重要な詳細が表示されます。
- size列には、各リクエストの圧縮サイズ（転送サイズ）と非圧縮サイズ（実際のサイズ）の両方が表示されます。
- name列には、ファイル名だけでなくフルパスが表示されます。
- priority列には、初期と最終のfetch priorityが表示されます。これにより、LCP画像がHigh優先度で読み込まれているかを確認したり、Chromeがリソースの優先度をいつ再設定したかを見つけることができます。
スクリーンショットの有効化
スクリーンショットを有効にすると、Chromeはページの読み込み中の視覚的な変化をフィルムストリップとして記録します。これにより、レイアウトシフトを見つけたり、LCP要素が期待通りのタイミングで描画されるかを確認できます。
- Networkタブを選択した状態で、Ctrl+F5（Macの場合はCmd+R）を押してページを更新します。
- Chromeがページ読み込みプロセスの間にスクリーンショットをキャプチャします。
- Networkパネルのチェックボックスの行の下に、これらのスクリーンショットのサムネイルが表示されます。
スクリーンショットの概要には、あまり知られていない便利な機能があります。
- スクリーンショットにカーソルを合わせると、キャプチャされたタイミングを確認できます。概要チャートに黄色の垂直線で示されます。
- スクリーンショットのサムネイルをクリックすると、そのスクリーンショットが撮られた後に発生したリクエストを除外してフィルタリングできます。
- サムネイルをダブルクリックすると、拡大してスクリーンショットの詳細を確認できます。
最適なNetwork列の有効化
デフォルトの列には重要なデータが欠けています。列のヘッダーを右クリックして追加してください。私がすべての監査で有効にしている列は以下の通りです。
| 列名 | 説明 | Core Web Vitalsにとって重要な理由 |
|---|---|---|
| Name | リクエスト名 | ブラウザがダウンロードするすべてのリソースを特定します。 |
| Status | HTTPステータスコード | TTFBに遅延を追加するリダイレクト（301、302）や、ネットワークのラウンドトリップを無駄にする404を見つけます。 |
| Protocol | 使用されているネットワークプロトコル | HTTP/3はHead-of-Lineブロッキングを排除します。Cloudflare Radarによると、HTTP/3を使用しているリクエストはわずか21%です。CDNがHTTP/3をサポートしているのにこの列にh3と表示されない場合は、DNSの構成を確認してください。 |
| Domain | リソースのドメイン | ファーストパーティのリクエストとサードパーティのリクエストを区別します。2024 Web Almanacによると、92%のページで少なくとも1つのサードパーティが読み込まれています。ドメインで並び替えることで、ウォーターフォールの中で制御できない部分がどれだけあるかが明らかになります。 |
| Type | リソースのタイプ | タイプでフィルタリングして、帯域幅を競い合っているスクリプト、画像、またはフォントを切り分けます。 |
| Initiator | リクエストのトリガー | どのスクリプトやスタイルシートが各リクエストをトリガーしたかを調べます。これにより、遅いクリティカルリクエストの連鎖を発生源まで追跡できます。 |
| Size | 転送サイズと実際のサイズ | 圧縮されていない、またはサイズが大きすぎるリソースを見つけます。モバイルページの中央値は、合計2.3 MB、66個のリクエストを読み込みます（2024 Web Almanac）。 |
| Priority | リソースの読み込み優先度 | 初期および最終のfetch priorityを表示します。LCP画像がHighで読み込まれ、重要ではないスクリプトがLowで読み込まれているかを確認します。 |
| Waterfall | リクエストの視覚的なタイムライン | どこに時間が費やされているかを示すタイムラインです。最初の描画よりも前にある長いバーは、LCPとFCPに直接影響します。 |
カスタムレスポンスヘッダーの有効化
| 列名 | 説明 | Core Web Vitalsにとって重要な理由 |
|---|---|---|
| Cache-Control | リソースのキャッシュ動作 | 静的アセットのキャッシュ有効期間が長く設定されており、HTMLが適切に再検証されているかを確認します。キャッシュの設定が不十分だと、リピーターがリソースを再ダウンロードすることになり、すべての指標が悪化します。参考：Cloudflareのキャッシュ構成 |
| Link | Linkレスポンスヘッダー | 103 Early Hintsなどを介して、サーバーがpreloadまたはpreconnectのヒントを送信しているかを確認します。 |
| Content-Encoding | 使用されているエンコーディング | サーバーがgzipではなくBrotli（br）を送信しているかを確認します。BrotliはgzipよりもJavaScriptを15〜20%小さく圧縮します。2024 Web Almanacによると、JavaScriptリソースにおいてBrotliがgzipを上回っています（45%対41%）。 |
すべてのページでDevToolsを開かずにレスポンスヘッダーを一括で分析したい場合は、HTTP Header Performance Analyzerを試してください。
Performanceパネルへの接続
Networkパネルは、何が・いつ読み込まれるかを示します。各リソースがCore Web Vitalsにどのように影響するかを確認するには、Performanceパネルに切り替えます。現在では、記録を行わなくてもLCP、CLS、およびINPのスコアがリアルタイムに表示され、実際のユーザーからのCrUXのfield dataをオーバーレイできます。診断にはNetworkパネルを使用し、確認にはPerformanceパネルを使用します。
単一のデバッグセッションを超えて継続的に監視する場合は、Real User Monitoringツールを接続します。これにより、Networkパネルでの修正が実際にfield dataを長期的に改善しているかを追跡できます。
完全な設定
これらの設定でページを再読み込みすると、Networkパネルは次のようになります。各列は、Core Web Vitalsに影響を与える何らかの要素に対応しています。
