DevTools Network panel: how to read a page load

What the panel shows

When a page loads, the browser requests the HTML, then the files the HTML points to, then the files those files point to. The Network panel logs all of it. Each row is one request. You can sort the rows, filter them and open any one for detail.

Use it to answer plain questions: how many requests does this page make, how heavy are they, which hosts are involved, which file is the biggest, what is slow to start, and what failed.

The documentation we used for this guide dates from 2023, and DevTools changes often. Menu positions may differ in your version.

Set up a fair test

1. Open DevTools first, then load the page. The panel's totals only count requests logged since DevTools was open, and earlier requests are not included. The documentation warns about this for both the request count and the transfer size.
2. Use a private window, so extensions do not add requests or work.
3. Check Disable cache to see what a first-time visitor sees. The documentation says this more accurately emulates a first-time user's experience, because requests are served from the browser cache on repeat visits. Uncheck it to see a returning visitor. You can also clear the browser cache by hand: right-click the table and choose Clear browser cache.
4. Choose a network speed from the throttling menu, with presets such as Slow 3G and Fast 3G, or make your own. A warning icon next to the tab reminds you that throttling is on.
5. Turn on screenshots in the panel's settings if you want to see what a visitor sees as the page loads. After you reload with the panel in focus, you can click a screenshot to hide the requests that came after it.
6. Preserve the log if you want the list to keep requests across page loads, for example to see a redirect.

Read the table

The table shows these columns by default:

You can add more columns by right-clicking the header: among them Domain, Protocol, Priority and Cookies. The priority and protocol columns are worth turning on. See HTTP/2 and HTTP/3 and resource hints.

Compressed and uncompressed size

The Size column shows the transferred size. To see the size after the browser unpacks the file, turn on Use large request rows in the settings. The bottom value is then the uncompressed size. The documentation's example is a page of 43.8 KB on the network and 136 KB unpacked. If both numbers are the same for a text file such as HTML, CSS or JavaScript, the file was probably sent without compression. See text compression.

Totals

The bottom of the panel shows the number of requests and the size transferred and loaded. Remember the caution above: only requests since DevTools opened are counted.

Read the waterfall

The waterfall shows when each request started and ended, in relation to the others. Requests are sorted by start time, so ones further left started earlier. In each bar, the lighter part is time spent waiting and the darker part is time spent downloading. A blue line marks the DOMContentLoaded event and a red line marks the load event.

Look for:

• A long chain. A file that starts only after another finished, which started after another. Each step adds a round trip. Hold Shift and hover over a request: its initiators turn green and its dependencies red. This shows what a request waited for.
• A late main image. The image's bar should start early. If it starts late, it was found late. See how to fix a slow LCP.
• A wide light part. A long wait before the download means the server, or a queue, was slow to answer.
• Many hosts. Each new host needs a connection. See DNS, TLS and connections.

For a request started by a script, hover over the Initiator column to see the stack trace that led to it.

Read the timing of one request

Click a request and open the Timing tab. The phases, as the documentation explains them:

Read it like this:

• A long Waiting (TTFB) on the page itself points to the server. See time to first byte and server response time.
• A long Initial connection points to distance or a slow secure handshake. See TLS.
• A long Queueing on HTTP/1.1 points to too many requests to one host.
• A long Content Download on a small file may mean a slow network, or a busy main thread. The documentation notes that larger than expected values can mean the browser was busy doing other work.

Filters that find problems fast

The filter box accepts words and properties. Properties can be combined with spaces, as an AND. The documentation's example is mime-type:image/gif larger-than:1K. Useful ones:

• larger-than:200k shows the files over 200 kilobytes. Start with the biggest.
• status-code:404 shows missing files. Each is a wasted request.
• scheme:http shows files loaded over plain HTTP, which cause mixed-content problems.
• domain:*.example.com limits the list to one host, and the 3rd-party requests checkbox shows only requests to hosts other than your own. See third-party scripts.
• priority: with a value shows requests at one priority.
• has-response-header: and the Headers tab show which files send which headers, for caching checks. See HTTP caching headers.

The buttons above the table filter by type: documents, stylesheets, scripts, images, fonts and so on.

Block a file to see what it costs

You can load the page as if one file did not exist. Press Control+Shift+P (Command+Option+P on a Mac) to open the Command Menu, type block, choose Show Request Blocking, click Add Pattern, type part of the file's address, and reload. Blocked requests appear in red in the list. Chrome's own tutorial uses this to see how a page behaves when a resource is unavailable. You can use it for speed too. Block a chat widget's address or a tag manager's host, reload, and compare the page weight and the time with and without it. Uncheck Enable request blocking when you are done. See third-party scripts.

Save and share

DevTools can export all the requests logged since it was opened as a HAR file, a standard format that other tools and DevTools itself can import, so a developer can see what you saw. You cannot filter what goes into the HAR file. To share one request, right-click it and use Copy: the options include the link address, the response, a cURL command and a fetch call.

What it cannot tell you

• It is not the place to start for ideas. Chrome's own tutorial says that if you want to improve load performance, you should not start with the Network panel, because many load problems are not about the network. Start with Lighthouse for targeted suggestions, and use this panel to check what is actually downloaded.
• It shows one load on your computer. Throttle, repeat, and confirm on a phone. See testing on real devices.
• It shows requests, not rendering. To see what the main thread did with those files, use the Performance panel. See the Performance panel.
• It starts when you open it. Anything earlier is missing from the totals.

Check your own page

Run the free audit, then load the same page in the Network panel with the cache disabled. Compare the biggest files and the number of hosts with the audit's list of findings. Use the filters above to find the largest files, the third-party requests and the 404s.

Sources

• Network features reference in the Chrome DevTools documentation: the recording options, throttling, filters, columns, the waterfall and the timing phases.
• Inspect network activity in the same documentation: when to use the panel, and blocking requests.