Inspect the request cycle

The request/response cycle is easier to trust once you have seen it in a tool you already have open.

Open any page, then open your browser developer tools and select Network. Reload the page so the panel records every exchange from a clean start.

Click the first row. That is usually the main HTML document. In the details pane, find:

• the full request URL
• the request method (almost always GET for a navigation)
• the response status (often 200, sometimes 304 from cache)
• the remote IP address
• the protocol (h2 for HTTP/2, http/1.1 for HTTP/1.1)
• timing: how long DNS, connection, waiting, and download took

One HTML response rarely stands alone. The browser parses it, discovers linked CSS, JavaScript, images, and fonts, and fires a separate HTTP request for each. Scroll the Network list and count how many rows appear for a single page view. That number is why front-end performance work is mostly HTTP work.

Filter the list to make patterns obvious. Try Doc for the HTML, CSS for stylesheets, Img for images. A missing stylesheet often shows as a red row with 404. A slow hero image shows up as a long Content Download bar.

Compare the browser view with the terminal. Run curl -I https://flaviocopes.com/ and note the status and headers. Then find the same document request in Network and open its Headers tab. The status code and many header names should match. The browser adds cookies and different Accept values, but the core exchange is the same protocol.

My advice is to keep Network open while you develop. When a page looks wrong, check whether the HTML arrived, whether assets 404’d, and whether anything blocked on CORS or mixed content. Those answers live in this panel before you touch server logs.

Try this on your own project: reload your homepage with Network recording, screenshot the waterfall, and note the slowest third of requests.

Quick check

Start quiz

Result

You got of right.

Try again