Debugging with Browser DevTools

You can show or hide columns by right-clicking the header, but six of them carry most of the signal:

• Name — the file or path that was requested (style.css, /api/orders/42, hero.jpg). This is how you find the specific request you care about in a long list.
• Status — the HTTP status code that came back. This is the first thing to scan: a wall of 200s is healthy, and a red 404 or 500 jumps out. You will also see 301/302 here for redirects and 304 Not Modified for a successful cache revalidation.
• Type — the kind of resource (document, stylesheet, script, font, xhr/fetch for API calls, png/jpeg for images). Handy for filtering: when you only care about your API calls, you filter to the Fetch/XHR type and the noise disappears.
• Protocol — the HTTP version used: h2 for HTTP/2, h3 for HTTP/3 over QUIC, http/1.1 for the older one. This column is the easiest way to confirm which version a site negotiated, the thing we discussed back in the connections chapter.
• Size — how many bytes came over the wire. The value here also tells you when a response didn't come over the wire at all, which is how you spot a cache hit (more on that below).
• Time — how long the request took end to end. Click this column header to sort by it, and the slowest request floats to the top. That single click is often the whole debugging session.

A small thing worth knowing early: the filter box at the top of the panel takes plain text (type orders to see only requests with "orders" in the name) and a handful of special filters like status-code:500 or method:POST. When a page makes a hundred requests, the filter is how you get down to the one that matters.

Clicking into one request

The table is the overview. Click any row and a detail view opens beside it, split into tabs. The names vary slightly between browsers, but the four that matter are consistent:

• Headers — the request line and headers your browser sent, and the status line and headers the server sent back. This is the same raw exchange we annotated line by line in the HTTP Messages section, now laid out in a panel. It is where you check whether the Authorization header went out, what Content-Type came back, or which Cache-Control the server set.
• Payload (sometimes "Request") — the request body, for a POST or PUT. If you sent JSON, you see the JSON; if you submitted a form, you see the form fields.
• Response (and a separate Preview) — the raw response body. Preview renders it nicely (formatted JSON, a rendered image), while Response shows the literal bytes. When an API call "isn't working," this tab usually has the answer the server actually sent.
• Timing — a breakdown of where the time went for this one request. This is the tab most people never open, and it is the most useful one in the panel.

Reading the timing breakdown

The Time column tells you a request was slow. The Timing tab tells you why. It splits the request's lifetime into phases, drawn as a stacked bar, and each phase maps onto a layer you already learned earlier in the course.

Reading the bar left to right:

• Queued / Stalled — the request is waiting before it even starts. The browser limits how many connections it opens at once, so a request can sit in line behind others, or wait for a free connection. A long stall usually means contention, not a slow server.
• DNS Lookup — turning the hostname into an IP address. This is the DNS resolution from the DNS chapter, measured. On a repeat visit it is often near zero because the browser and OS cached the answer.
• Initial connection (TCP) — the TCP three-way handshake from the TCP chapter, the SYN / SYN-ACK / ACK round trip that sets up the connection before any HTTP can flow.
• SSL / TLS — the TLS handshake from the TLS chapter, where the browser and server agree on keys and the server proves its identity with a certificate. On a plain http:// page this phase is simply absent.
• Waiting (TTFB) — "time to first byte." The request has been sent and the browser is waiting for the server to start replying. This phase is the server thinking: running your code, hitting a database, building the response. A big TTFB points at the backend, not the network.
• Content Download — the time spent actually receiving the response body. A big number here means a large response or a slow link, not a slow server.

Here is the insight that makes the bar worth reading: everything before Waiting is connection setup. DNS, the TCP handshake, and the TLS handshake all happen before your request body is even sent. That is exactly why connection reuse and keep-alive matter so much, and why the first request to a new host is slower than the rest. On later requests over the same connection, those first phases collapse to nothing and the bar is almost all Waiting and Download.

A common confusion: a slow Time with most of it in Waiting is a backend problem (the server is slow to respond), while a slow Time with most of it in Content Download is a payload or bandwidth problem (the response is too big). They look identical in the Time column and completely different in the Timing tab. That distinction alone changes who you go talk to.

The numbers are usually small and add up, so do not over-interpret a few milliseconds. The point of the breakdown is the shape: which phase dominates tells you which layer to suspect.

Spotting cache hits

The caching section spent a lot of time on what should be cached. The Network panel shows you what actually was. Look at the Size column. When a response is served from the cache, the byte count is replaced with a label instead of a number:

• (memory cache) — served from the browser's in-memory cache. Instant, and gone when you close the tab. You will see this for assets reused within the same page session.
• (disk cache) — served from the browser's on-disk cache. Survives a restart, and still much faster than a network round trip.

A 304 Not Modified status is a different, related win. There the browser did talk to the server (a small conditional request using the ETag or Last-Modified we covered in the cache-validation chapter), but the server confirmed the cached copy is still good, so no body came back. A 304 costs a round trip; a (memory cache) or (disk cache) hit costs nothing. Both beat re-downloading the file.

This is also where the reload type matters. A normal reload uses the cache where it is allowed to. A hard reload (Cmd+Shift+R / Ctrl+Shift+R) tells the browser to ignore the cache and fetch everything fresh, which is exactly what you want when you are testing whether a fix actually shipped versus seeing a stale cached file.

Seeing redirects and the protocol version

Two more things the panel makes obvious without any extra tooling.

Redirects show up as their own rows. If you request http://github.com you will see a 301 row whose response points elsewhere, then the row for the page it landed on. With "Preserve log" on, the whole chain stays visible, so a redirect loop (the same 301 repeating, or a chain that never reaches a 200) is immediately obvious as a stack of redirect rows. That is the same chain you would follow with curl -L, just drawn out as a list.

The HTTP version is right there in the Protocol column we mentioned earlier. If it is not shown, right-click the column header and enable "Protocol." Seeing h2 or h3 confirms the site negotiated HTTP/2 or HTTP/3; http/1.1 tells you it fell back to the older version. No special command needed, you just read the column.

Copy as cURL: from the browser to the terminal

Sometimes you find the broken request in the panel and want to poke at it repeatedly: change a header, drop a cookie, run it again, run it ten times. Doing that by clicking through a browser is slow. The browser has a bridge for exactly this.

Right-click any request in the table, choose Copy → Copy as cURL, and the browser hands you a complete curl command for that exact request: the same URL, the same method, every header the browser sent, the cookies, and the request body. Paste it into your terminal and you have reproduced the browser's request precisely, outside the browser.

This matters for two reasons. First, it removes the browser from the equation. If the curl command fails the same way, the bug is on the server, not in your front-end code. Second, it gives you a starting point you can edit freely without the browser fighting you. That bridge is exactly where the next chapter picks up: driving HTTP from the terminal with curl, where you control every byte of the request.

Try it now

Open any site you use often. Open DevTools, click Network, and reload the page so the table fills with rows.

1. Click the Time column header to sort by it. The slowest request rises to the top.
2. Click that slowest row, then open the Timing tab.
3. Read the bar and ask: which phase is the biggest? If it is Waiting (TTFB), the server was slow to respond. If it is Content Download, the response was large. If it is Queued/Stalled, it was stuck behind other requests. If a lot of it is DNS / Initial connection / SSL, you caught a fresh connection being set up.
4. Now look at the Size column for the image and font rows. Reload once more (a normal reload, not a hard one) and watch some of them switch to (memory cache) or (disk cache) — the second visit reusing what the first one fetched.

In one minute you have found a page's slowest request and explained why it was slow, using nothing but the browser. That is the panel earning its place as your first debugging tool.

What's Next

The Copy as cURL command you just learned is the handoff. Next we move into the terminal and drive HTTP with curl directly, so you can reproduce and isolate any request byte by byte.