Core Web VitalsのためのChrome DevTools Networkパネル設定
筆者が毎回のCore Web Vitals診断で行っているNetworkパネルの設定
Chrome DevToolsのNetworkパネルは、Core Web Vitalsのデバッグに最も役立つツールの1つです。しかし、デフォルト設定では必要な情報の半分が隠れています。筆者が毎回の診断で行っているNetworkパネルの設定は以下のとおりです。
最終レビュー: Arjen Karel（2026年3月）
Table of Contents!
Networkパネルの設定
Networkパネルを開くには、Chrome DevToolsを開き（F12またはCtrl+Shift+I）、「Network」タブをクリックします。
スロットリング
訪問者はオフィスの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はページ読み込み中のすべての視覚的変化をフィルムストリップとして記録します。これにより、layout shiftsを発見し、LCP elementが想定どおりのタイミングで描画されているかを確認できます。
- Networkタブを選択した状態で、Ctrl+F5（MacではCmd+R）を押してページを再読み込みします。
- ページ読み込みの過程でChromeがスクリーンショットをキャプチャします。
- Networkパネルのチェックボックス列の下に、キャプチャされたサムネイルが表示されます。
スクリーンショットの概要表示（Overview）には、意外と知られていない便利な機能があります。
- サムネイルにカーソルを合わせると、キャプチャされたタイミングが確認できます。Overviewチャート上に黄色の縦線で位置が示されます。
- サムネイルをクリックすると、そのスクリーンショットが撮影された後に発生したリクエストを除外して絞り込めます。
- サムネイルをダブルクリックすると拡大表示され、詳細を確認できます。
最適なNetwork列の有効化
デフォルトの列表示では重要なデータが不足しています。列ヘッダーを右クリックして列を追加してください。毎回の診断で必ず有効にしている列は以下のとおりです。
| 列名 | 説明 | Core Web Vitalsにおける重要性 |
|---|---|---|
| Name | リクエスト名 | ブラウザがダウンロードするすべてのリソースを特定します。 |
| Status | HTTPステータスコード | TTFBの遅延を招くリダイレクト（301、302）や、ネットワークの往復を無駄にするリソースの404エラーを特定します。 |
| Protocol | 使用されているネットワークプロトコル | HTTP/3はヘッドオブラインブロッキングを解消します。Cloudflare Radarによると、HTTP/3を使用しているリクエストは全体のわずか21%です。CDNが対応しているにもかかわらずこの列にh3が表示されない場合は、DNS設定を確認してください。 |
| Domain | リソースのドメイン | ファーストパーティとサードパーティのリクエストを区別します。2024 Web Almanacによると、92%のページが少なくとも1つのサードパーティを読み込んでいます。ドメイン順に並べ替えると、ウォーターフォールのうち自身で制御できない領域がどれだけあるかを把握できます。 |
| Type | リソースの種類 | タイプで絞り込み、帯域を奪い合っているスクリプト、画像、フォントを個別に特定します。 |
| Initiator | リクエストのトリガー | 各リクエストの発生元となったスクリプトやスタイルシートを特定します。遅延を引き起こしているcritical requestsの連鎖を、大元の原因まで遡って追跡できます。 |
| Size | 転送サイズと実サイズ | 未圧縮のリソースやサイズが大きすぎるリソースを検出します。モバイルページの中央値では、計66件のリクエストで合計2.3MBが読み込まれています（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はJavaScriptをgzipより15〜20%小さく圧縮します。2024 Web Almanacによると、JavaScriptリソースにおいてBrotliの採用率はすでにgzipを逆転しています（45%対41%）。 |
ページごとにDevToolsを開かずにレスポンスヘッダーを一括分析したい場合は、HTTP Header Performance Analyzerを活用してください。
Performanceパネルとの連携
Networkパネルは、何が、いつ読み込まれたかを示します。各リソースがCore Web Vitalsにどう影響しているかを確認するには、Performanceパネルに切り替えます。Performanceパネルは、プロファイリングを記録しなくてもリアルタイムのLCP、CLS、INPのスコアを表示し、実際のユーザーから収集されたCrUXのfield dataをオーバーレイ表示できます。Networkパネルで診断し、Performanceパネルで検証します。
単発のデバッグにとどまらず継続的に監視するには、Real User Monitoringツールを連携します。これにより、Networkパネルを基に行った改善が、長期的に実際のfield dataを向上させているかを追跡できます。
設定完了後の全体像
これらの設定を適用してページを再読み込みすると、Networkパネルは以下のようになります。各列が、Core Web Vitalsに影響を与える重要な要素に対応しています。
