Open the Network panel and capture activity

Open DevTools with the keyboard shortcut or the browser menu, then select the Network tab. The panel starts recording once opened. Reload the page to see the initial set of requests. Each row represents one resource. The top row is usually the main HTML document, and later rows show files requested by scripts or stylesheets.

By default the log clears on reload. Enable the Preserve log checkbox if you need to keep entries across navigations. The panel records activity only while DevTools remains open, so leave it visible during testing.

  • Click the record button (red circle) to pause or resume logging if needed.
  • Use the filter box to show only XHR/Fetch, JS, CSS, or Img resources.
  • Right-click any row and choose Reveal in Sources panel when you need the originating code.

Read status codes and response headers

Status codes appear in the Status column. A 200 code means success. 304 indicates the browser used a cached copy. 404 means the file was not found. 500-series codes point to server errors. Red text on a row usually signals a blocked or failed request.

Click any row to open the detail pane. The Headers tab lists request and response headers. Check Content-Type to confirm the server sent the expected data format. Look for Cache-Control and ETag values when investigating stale content. The Preview tab renders images or basic HTML, while the Response tab shows raw body content.

  • Filter the log by typing status:404 or status:500 to surface errors quickly.
  • Blocked requests often show a status of (blocked) or (failed) and appear in red.
  • CORS preflight OPTIONS requests appear separately before the actual cross-origin call.

Examine timing and the request waterfall

The Timing tab breaks down each request into phases: queueing, DNS lookup, initial connection, SSL negotiation, request sent, waiting (TTFB), and content download. Long TTFB values usually indicate server processing delays. Large content download times suggest oversized payloads or slow network links.

The waterfall view shows requests stacked by start time. Overlapping bars reveal parallel downloads limited by browser connection rules. Hovering a bar displays exact millisecond values for each phase.

  • Sort the log by the Time column to find the slowest individual requests.
  • Enable the waterfall column if it is hidden to see visual timing bars.
  • TTFB above a few hundred milliseconds on API calls often points to backend work rather than network latency.

Check caching behavior

Cached resources show a 304 status or a Size value of (from memory cache) or (from disk cache). When a stylesheet or script fails to update, the cache is the usual culprit. Disable the cache checkbox in the Network panel to force fresh downloads during testing. Response headers such as Cache-Control: no-cache or max-age control how long browsers keep copies.

Clearing the browser cache through settings removes stored files but does not affect the current DevTools session unless you reload after clearing.

  • Use the Size column to distinguish transferred bytes from cached bytes.
  • Search the Headers tab for Cache-Control to audit caching policies across resources.
  • Service workers can intercept requests and serve their own cached responses; the Initiator column helps trace these.

Identify and debug failed or blocked resources

Failed requests appear with red status text or a (failed) label. Common causes include incorrect URLs, missing files on the server, CORS policy blocks, or ad blockers. The Initiator column shows which script or stylesheet triggered the request, making it easier to trace the source of an unexpected call.

Enable request blocking in the panel to simulate missing resources during development. The Search tab lets you scan all headers and response bodies for a string such as an error message or header name.

  • Click a blocked row to see the exact blocking reason in the Headers tab.
  • Third-party requests can be filtered by enabling the third-party column or using the domain filter.
  • WebSocket connections appear with type WS and open a Messages tab for frame inspection.

Apply the panel to everyday troubleshooting

Start every investigation by reloading the page with the Network panel open. Note the first failing request and its status code. Check timing if the page feels slow. Verify cache headers when content does not update. Use the filter and search tools to narrow the log quickly. The same workflow applies in Firefox Network Monitor and Edge DevTools with only minor UI differences.

Remember that the panel shows only network activity. Layout, JavaScript, or rendering problems require the Console, Elements, or Performance panels instead.

  • Export the HAR file from the panel menu when you need to share a full request log with another developer.
  • Keep the panel open while testing form submissions or button clicks to capture runtime requests.
  • Close the detail pane when finished to keep the log view uncluttered.