Most people use the Network tab to look at a list of requests and their status codes. That’s a fraction of what it does. Here’s what you’re probably missing.

Throttle to a real connection, not “Slow 3G” guesswork

The Network tab’s throttling dropdown simulates bandwidth and latency, but the presets are rough. For anything you care about precisely, add a custom profile: Network tab → throttling dropdown → Edit → set your own download/upload speed and latency in ms. Test against what your actual users have — if you have analytics on connection type, match it, instead of testing against a preset that may not resemble anyone real.

Throttling only affects requests made while it’s active and the tab is open — it doesn’t persist across a reload if you’ve closed DevTools, so keep the panel open through the full test.

Block a request to see what breaks

Right-click any request in the list → Block request URL, or block by pattern (*.js, *analytics*) in the Network request blocking panel (⋮ menu → More tools → Network request blocking). This is the fast way to answer “does this page work if the ad blocker kills this script” or “what happens if this third-party API is down” without actually taking the dependency offline.

*doubleclick*
*/api/analytics/*

Add patterns to the blocking list, reload, and watch what actually breaks versus what you assumed would break.

Override a response without touching the server

Local Overrides (Sources tab → Overrides, or right-click a request in Network → Override headers) lets you edit a response body or headers and have DevTools serve your edited version on every subsequent request, persisting across reloads. This is different from just editing in-memory — it survives a refresh, which makes it usable for actually testing a change, not just eyeballing it once.

Read the waterfall, not just the status column

Click a request, open the Timing tab. The breakdown — Queueing, Stalled, DNS, Initial connection, TLS, Request sent, Waiting (TTFB), Content Download — tells you where the time went, not just that a request was slow. A request that’s slow because of Stalled time is usually a connection-limit problem (too many parallel requests to the same host). A request slow because of Waiting (TTFB) is your server or API being slow, not the network. Those need completely different fixes, and the summary “1.2s” doesn’t tell you which one you have.

Export a HAR file for a bug report

⋮ menu → Export HAR (or right-click on any request → Save all as HAR with content) saves the entire request/response log — headers, timing, bodies — as a JSON file. Attach it to a bug report or send it to support for a third-party API issue. It’s a far more useful artifact than a screenshot, since it has full timing and payload data.

# a HAR file is just JSON — you can grep it for a specific failing request
jq '.log.entries[] | select(.response.status >= 400) | .request.url' network.har

Filter by type and status fast

The filter bar accepts more than plain text:

status-code:404
method:POST
larger-than:100k
mime-type:application/json

Combine with - to exclude: -domain:googletagmanager.com hides the noise from third-party scripts so you can see only your own app’s requests.

The one habit worth building

Keep DevTools open with Disable cache checked (Network tab checkbox) while you’re actively developing. Otherwise you’ll chase a bug for twenty minutes that’s actually just your browser serving a cached response from before your fix, and every “why isn’t my change showing up” rabbit hole traces back to this one unchecked box.