今回やること
この記事では、DevToolsのNetworkパネルを使って、ページ読み込みやAPI通信を確認します。
Networkは「ブラウザが何を取りに行き、何に失敗したか」を見る場所です。
Step 1: Networkを開いてリロードする
Chromeでページを開き、DevToolsを表示します。
Cmd/Ctrl + Shift + I
Networkタブを開いたら、ページをリロードします。
Cmd/Ctrl + R
Networkは、開いた後の通信を記録します。先にNetworkを開いてからリロードするのが基本です。
Step 2: 赤い行を見る
読み込みに失敗したリクエストは、赤く表示されることがあります。
見る項目:
- Name
- Status
- Type
- Size
- Time
たとえば、画像が404なら次のように見えます。
logo.png 404 png 0 B
この場合、画像ファイルのパスや配置を確認します。
Step 3: Statusを見る
Statusは、HTTPの結果です。
| Status | 意味 |
|---|---|
| 200 | 成功 |
| 301/302 | リダイレクト |
| 304 | キャッシュ利用 |
| 400 | リクエストが不正 |
| 401 | 認証が必要 |
| 403 | 権限がない |
| 404 | 見つからない |
| 500 | サーバ内部エラー |
まずは、失敗しているリクエストのStatusを見ます。
Step 4: Headersを見る
リクエストをクリックすると、詳細が表示されます。Headersでは、URLや送受信ヘッダーを確認できます。
見る項目:
- Request URL
- Request Method
- Status Code
- Response Headers
- Request Headers
APIが失敗している時は、Request URLが正しいか、MethodがGETなのかPOSTなのかを確認します。
Step 5: Responseを見る
Responseタブでは、サーバから返ってきた中身を見られます。
JSON APIなら、エラーメッセージが返っていることがあります。
{
"message": "token is expired"
}
画面には「通信に失敗しました」としか出ていなくても、Responseを見ると原因が書かれていることがあります。
Step 6: SizeとWaterfallを見る
表示が遅い時は、SizeとWaterfallを見ます。
確認すること:
- 画像が大きすぎないか
- JSやCSSが大きすぎないか
- 外部CDNの読み込みが遅くないか
- 同じファイルを何度も読んでいないか
画像が数MBある場合、最初の表示が遅くなる原因になります。
Step 7: フィルターを使う
Networkにはフィルターがあります。
| フィルター | 見るもの |
|---|---|
| Fetch/XHR | API通信 |
| JS | JavaScript |
| CSS | CSS |
| Img | 画像 |
| Doc | HTML |
APIだけ見たい時は、Fetch/XHRに切り替えると探しやすくなります。
ポイント: Networkでは「どのURL」「何番のstatus」「返ってきた中身」をセットで見ます。
まとめ
DevTools Networkは、通信の事実を見る場所です。画面だけでは分からない404、500、CORS、画像の重さ、APIレスポンスを確認できます。
表示が遅い、画像が出ない、APIが動かない時は、まずNetworkを開いてリロードします。
次に読む記事
ケース：JSON APIのはずがHTMLを返す
statusが200でもResponse先頭が<!doctype html>なら、JSON parsing errorは応答形式の不一致です。Request URLがfrontend serverへ向く、proxy prefixがない、redirect後にlogin pageへ着く可能性をHeadersで確認します。
Content-Typeがtext/htmlならAPI契約のapplication/jsonと一致しません。Previewの印象ではなくHeadersと本文を根拠にします。二件並ぶ時はpreflight、redirect、retry、二重clickをmethodとInitiatorで分けます。OPTIONSとPOSTは正常な組ですがPOST二件ならlistener重複やbuttonとform submitの両方を疑います。
証拠にはmethod、最終URL、status、Content-Type、response概要を残します。Disable cacheは調査条件として記録し、通常cacheへ戻して確認します。Networkを開いた時だけ成功するなら、cache無効化やtiming変化が影響している可能性があります。
Headersとbodyの照合
AcceptとContent-Typeを混同しません。前者は受け取りたい形式、後者は送信body形式です。JSONなのにform形式、multipartなのにboundary不足ならserverが解釈できません。Payloadとraw bodyを見ます。
Content-Encodingと転送Sizeも確認します。元Sizeと転送量は異なり、cacheならtransferがほぼない場合があります。認証情報の値は共有せず、送信有無、cookie属性、Set-Cookie有無を確認します。
GraphQLで200のbodyにerrors、204でbodyなし、HEADでbodyなしという契約もあります。一般的status表だけで誤りとせず対象API仕様と比較します。requestとresponseが合意したmethod、形式、認証、cache契約を一項目ずつ確認します。
query parameterの配列、空文字、日時形式はserver frameworkによって解釈が違います。URLの表示を読み、期待したencodingになっているかを確認します。+、space、日本語、timezone offsetを含む値では、frontendの元変数だけでなく実際に送信されたURLが証拠です。
Service Worker経由のresponseはNetworkの表示やSizeが通常通信と異なる場合があります。Application panelで登録状態を確認し、bypass条件を記録します。workerを解除して直っただけなら、cache versionと更新戦略の問題を残したままにしません。
通信結果の判断表
| 観測 | 言えること | 次の確認 |
|---|---|---|
| 行がない | browserから未送信 | handler、Console、validation |
| 301/302後に別URL | redirect | Location、method、認証 |
| 200でHTML | API想定と形式違い | Content-Type、最終URL |
| blocked | HTTP応答前に遮断 | CORS、Mixed Content |
| canceled | navigation等で中断 | Initiator、AbortController |
status 200は画面処理の成功を保証しません。 JSON契約違反やHTML応答もあります。304はcache検証結果で単純な失敗ではありません。
Networkの動作確認
Networkを開いて操作をやり直し、APIならFetch/XHRへ絞ります。Preserve log利用時は過去分と時刻を区別します。PayloadやHARのpassword、token、Cookieは共有前に除去します。修正後はmethod、最終URL、status、Content-Type、body、重複送信の有無を確かめます。Networkは通信事実を示し、期待値はAPI仕様と照合します。
