Chrome DevTools Network Panel: A Developer’s Complete Guide

The Network panel in Chrome DevTools is where most performance and debugging work starts and ends. It records every network request the page makes, from HTML and JavaScript through API calls, images, and WebSocket frames. Understanding the panel’s columns, the waterfall model, and the less-visible filtering tools separates developers who can diagnose network problems quickly from those who scroll through a thousand rows hoping something obvious jumps out.

Opening and Basic Layout

Open DevTools with F12 or Ctrl+Shift+I (Cmd+Option+I on Mac). Click the Network tab. Then navigate or reload the page — the panel only records requests that happen while it’s open.

The panel layout: a toolbar at the top (filters, throttling, options), a waterfall chart in the main pane, and a detail panel that opens on the right when you click any request. The bottom status bar shows totals: number of requests, total transfer size, and DOMContentLoaded and Load event times.

Key toolbar controls to know immediately:

  • Preserve log — checked, requests from navigations persist; otherwise each navigation clears the panel. Turn this on when debugging redirects.
  • Disable cache — checked, no cached responses are served. Essential when testing changes that would otherwise be cached.
  • Throttle dropdown — simulate mobile network conditions. “Slow 3G” and “Fast 3G” presets are useful; “No throttling” is the default.
  • Record (dot icon) — toggles recording on and off.

The Request Waterfall: Reading It Correctly

Each row in the waterfall represents one request. The colored bars show when the request happened relative to the timeline. The bar segments correspond to timing phases, which you can see by hovering over a bar:

  • Queueing (white/light): The request was waiting in the queue before being sent. Common when the browser is at the connection limit for a domain (Chrome allows 6 concurrent connections per origin on HTTP/1.1) or when the request was delayed by a higher-priority request.
  • DNS Lookup (blue): Time to resolve the hostname to an IP address.
  • Initial Connection (orange): TCP handshake time.
  • SSL (orange, darker): TLS negotiation, for HTTPS only.
  • Request Sent (green, very thin): Time to transmit the request headers and body.
  • Waiting (TTFB) (green): Time To First Byte — the time from request sent to the first byte of the response. This is where server-side processing time shows up.
  • Content Download (blue): Time to receive the response body.

TTFB is usually the most diagnostic value for slow API endpoints. If TTFB is 800ms, the server is slow. If TTFB is 10ms but Content Download is 3s, you have a large response and should look at compression and payload size.

The Chrome DevTools documentation on network analysis covers the full timing breakdown with diagrams.

Filtering Requests

With hundreds of requests for a typical page, filtering is essential.

Type filters (the row below the toolbar): XHR, Fetch, JS, CSS, Img, Media, Font, Doc, WS, Wasm, Manifest, Other. These filter by resource type. “XHR” shows classic XMLHttpRequest and also fetch API calls in Chrome’s labeling.

Text filter box: Type in the filter box to match by URL, domain, or status code. Use - to exclude: -domain:tracking.example.com removes all requests to that domain. Use domain: to filter to one origin.

Status filter: Right-click any column header for additional filters. The Has blocked cookies, Blocked requests, and 3rd party columns are particularly useful.

Blocked requests: If you’re using a content blocker or the browser’s privacy settings are blocking requests, blocked requests appear with a strikethrough icon. This is invaluable for testing what a user with an ad blocker experiences.

The Detail Panel: What to Look At

Click any request row to open the detail panel. The Headers tab shows the full request and response headers. For API debugging:

  • Request Headers: Check Content-Type, Authorization, Origin, and custom headers. Confirm they’re what you intended.
  • Response Headers: Check Content-Type (an API returning HTML instead of JSON is a common confusion), Cache-Control, X-Frame-Options, CORS headers (Access-Control-Allow-Origin).
  • Status Code: 200 is success; 301/302 redirects, 304 “Not Modified” (cached), 401/403 auth errors, 429 rate limiting, 500/502/503/504 server errors.

The Preview tab renders the response if it’s JSON, HTML, or an image. For JSON APIs this shows the parsed structure. The Response tab shows the raw body.

The Initiator tab shows what triggered the request — which script on line which called fetch() or XHR.open(). Tracing an unexpected request back to its source goes through Initiator.

The Timing tab shows the full breakdown of timing phases described above, with exact millisecond values.

Inspecting WebSocket Traffic

WebSocket connections appear in the request list with a “WS” type. Click them to open the Messages tab, which shows every frame exchanged after the initial upgrade handshake. Frames you sent appear in a different color from frames you received. This is essential for debugging real-time features.

CORS and Preflight Requests

Cross-Origin Resource Sharing issues are a common source of confusion. When a cross-origin fetch includes custom headers or uses a non-simple method (anything other than GET/POST, or POST with a non-standard Content-Type), the browser sends an OPTIONS preflight request first. If the server doesn’t respond with appropriate Access-Control-Allow-Origin and Access-Control-Allow-Headers, the actual request is blocked.

In the Network panel, preflight requests appear as separate OPTIONS requests immediately before the blocked request. The error in the Console will say something like “CORS policy: No ‘Access-Control-Allow-Origin’ header is present.” Look for the preflight OPTIONS request in the Network panel to confirm the server’s response — if the preflight returns a 404 or doesn’t include CORS headers, that’s the problem.

The MDN CORS documentation covers the full algorithm.

HAR Export and Import

You can export the entire Network panel log as a HAR (HTTP Archive) file: right-click in the panel → Save all as HAR. This creates a JSON file with every request, response headers, timing data, and body (for non-binary responses).

HAR files are useful for: sharing a network trace with another developer who wasn’t present for the debugging session, analyzing requests in external tools (the HAR Analyzer at toolbox.googleapps.com parses them with nice summaries), and importing back into DevTools to review a session offline.

Practical Debugging Patterns

“Why is my page slow on first load?” Sort by Start Time, look for requests with long TTFB (server not responding), long DNS/SSL (resolve + connect overhead before the first resource even arrives), or long chains of blocking dependencies (JS that loads more JS that loads more JS).

“Why is my API call failing?” Filter to XHR/Fetch, find the call, look at the status code and response body in the Preview tab. If status is 0 (request never sent), check the Console for a CORS error.

“Something is making an unexpected request.” Filter to third-party requests by enabling the third-party column or filtering by -domain:yourdomain.com. Check Initiator to see what script triggered it.

“The page uses a stale version of my JS.” Check the response headers of the JS file for Cache-Control and ETag. If the browser served it from cache, the entry will have a “disk cache” or “(from memory cache)” note in the Size column.

FAQ

Can I record the network panel without opening DevTools first? No. The panel only records while it’s open. For capturing the full page load including the initial HTML request, open DevTools before navigating (or use Preserve Log and reload).

Does the Network panel show data from service workers? Yes. Requests served by service workers appear with a service worker icon in the Status column. You can filter to “service worker” in the Search filter. The service worker’s handling appears as a separate timing segment.

How do I capture traffic from a background page or extension service worker? Open the service worker DevTools context: go to chrome://extensions, find your extension, click “service worker” under the extension — this opens a DevTools window for that context with its own Network panel.

What’s the difference between the Resource Timing API and the DevTools network panel? The Resource Timing API is accessible from JavaScript at runtime (performance.getEntriesByType("resource")) and gives the same timing breakdown. DevTools reads from this API. The difference is that DevTools shows request/response headers and body; the Resource Timing API doesn’t expose headers (by design, to prevent cross-origin information leakage).