Skip to main content

The Chrome DevTools Network Tab: Debug Site Speed

· Updated on · 9 min read

Chrome's developer tools provide a lot of information on what's slowing down your site and how to make it faster. This article explains how to use the DevTools Network tab to debug performance issues.

Getting started: is the network the performance bottleneck?

Before looking at the requests made by the page we first need to check if the network is actually what's slowing it down. Heavy CPU processing is also a common cause of slow page load times.

To check what's slowing down your page, open Chrome DevTools by right-clicking on the page and selecting Inspect. Then select the Performance tab and click the Start profiling and reload page button.

If the CPU timeline contains a lot of orange then the page is running a lot of JavaScript, and it might be better to look into that instead of focussing on the network.

Example 1: Youtube homepage

The Youtube homepage spends a lot of time running JavaScript and rendering the UI.

Youtube homepage CPU timeline

Switching to the Network tab, we can see that the document request could probably be sped up, and the JavaScript bundle could be loaded more quickly. But, compared to the 6.5s of JavaScript execution time, this isn't too important.

Youtube DevTools Network tab

Example 2: Getty Images homepage

By comparison, the Getty Images homepage doesn't require a lot of CPU processing.

Getty images CPU timeline

Instead rendering is blocked by a large number of concurrent image requests, slowing down a render-blocking script.

Getty Images network tab

Here the Network tab will help identify opportunities to improve site performance.

Finding the cause of a slow request

If a request is slow, then either the server needs to respond to requests more quickly, or the size of the response needs to be reduced.

To break down the duration of a request, either hover over the Waterfall column, or click on the request and select the Timing tab.

This way you can find out if the request is slow because the response takes a long time to download (left), or if the server takes a long time before starting to send the response (right).

Long Content download on the left, long Waiting (TTFB) on the right

Large responses

If a response takes too long to download you need to make the response body smaller.

For example, if the the slow request loads an image:

  • Serve a modern format like WebP to browsers that support it
  • Increase image compression
  • Resize the image so it's not larger than necessary

Or, for JavaScript files:

  • Use gzip or brotli to compress the response
  • Minifiy the JavaScript code
  • Remove large dependencies
  • Lazy load non-essential code

Slow server responses

To resolve slow server responses you'll need to look at your backend code. It might be doing unnecessary work or run slow database queries.

Learn more about reducing slow Time To First Byte (TTFB).

Run A Free Page Speed Test

Test Your Website:

  • No Login Required
  • Automated Recommendations
  • Google SEO Assessment

Network throttling

As a developer you probably use a relatively fast internet connection. So a 10MB image might load quickly on your computer, but will take a long time on a 3G connection. Likewise, running your server locally means there's practically no round-trip latency.

To make investigating performance easier, Chrome DevTools includes a network throttling option that artificially increases response delays and reduces bandwidth. This lets you simulate how your site loads on a slower connection.

To enable throttling, select an option from the dropdown on the right of the "Disable cache" checkbox.

Chrome DevTools network throttling

Here's a site on a fast connection without any throttling.

Loading a site without throttling

And here's the same site loaded using the Slow 3G setting.

Loading a site with network throttling

Throttling the network allows you to watch your page render gradually, observe what order content is displayed in, and which block rendering.

Note that DevTools uses a relatively basic type of network throttling. Learn more about the different types of network throttling.

Network round-trips

A network request to a new website consists of multiple sequential round-trips that are needed to create a server connection:

  • DNS lookup to resolve the domain name
  • Establish TCP connection
  • Establish SSL connection
  • Make the actual HTTP request

The DevTools waterfall shows each part of the request in a different color.

Network round-trips on first load, includes DNS and TCP time

Again, you can hover over the request to get an explanation of the breakdown.

Chrome DevTools request breakdown showing DNS lookup, Initial TCP connection, and SSL time

However, you'll only see these round-trips if Chrome hasn't previously connected to the website's server. If you load the same page again you'll only see the actual request round-trips, as the existing server connection is reused.

Second load reuses existing server connection

Clearing the DNS and connection caches

To simulate the first load experience you need to clear Chrome's DNS and connection caches.

1. Clear OS-level DNS cache

On Mac OS, run this in the terminal:

sudo killall -HUP mDNSResponder

On Windows:

ipconfig /flushdns

2. Clear DNS cache via Chrome

Go to chrome://net-internals/#dns and click Clear host cache.

This button sounds like it should clear the OS-level cache, but my experience just doing this isn't enough by itself.

Chrome DNS page

3. Close existing server connections

Go to chrome://net-internals/#sockets and click Flush socket pools.

Chrome Sockets page

Then reload the page you're testing and you should see the DNS lookup again, as well as the time spent on establishing the TCP connection.

DevTools DNS and TCP roundtrips

Monitor Page Speed & Core Web Vitals

DebugBear monitoring includes:

  • In-depth Page Speed Reports
  • Automated Recommendations
  • Real User Analytics Data

DevTools Network settings

Click the gear icon in the top right corners of the Network tab to view the Network tab settings.

Gear icon for DevTools network settings

Large request rows

This setting means additional information will be shown in each row, for example the Size column will show both the compressed response size that's transmitted over the network, as well as the full unzipped size of the response body.

The Time column will show the server response time in addition to the total request duration.

Large DevTools network request rows with additional information


Check Capture screenshots to view a rendering filmstrip alongside your requests. This helps identify requests that block a particular part of your page from loading.

Hovering over a screenshot shows a yellow line in the waterfall column, indicating when that screenshot was taken.

Screenshots above network requests table

Group by frame

The Group by frame option can make the list of requests more manageable if a lot of requests are made by iframes.

Requests grouped by iframe

Request columns

You can customize what information Chrome shows about each request.

Customized request columns showing Connection ID and content encoding

Right-click on the requests table to select the columns you want to see.

Context menu showing column options

Connection ID

This column shows which server connection was used for each request. Ideally you want to avoid creating a new connection and instead use the same connection for many requests. This avoids the round-trips involved in establishing a new server connection.

If the Protocol column shows h2 for HTTP/2 then the browser can reuse the same connection for multiple concurrent requests.


The initiator column explains why Chrome made the request. This could be because of an image tag in the HTML, or because of a fetch call in the JavaScript code. Click on the link in the column to see the relevant source code.

If you hover over the initiator of a resource that was loaded via JavaScript, you can see a call stack showing where the request was made.

JavaScript initiator call stack


This column shows the number of cookies that were sent when making the request.

Content-Encoding header

This shows how the response body was compressed, e.g. using gzip or br (Brotli).

Copy as fetch/cURL

This menu option generates code for making the selected request and copies it to the clipboard. For example, it can generate a browser fetch call or a cURL command that can be run in the terminal.

Copy as fetch dialog

This is an example of a fetch call generated by Chrome DevTools:

fetch("", {
headers: {
"accept-language": "en-US,en;q=0.9",
"cache-control": "no-cache",
pragma: "no-cache",
"upgrade-insecure-requests": "1",
referrerPolicy: "strict-origin-when-cross-origin",
body: null,
method: "GET",
mode: "cors",
credentials: "omit",

This feature is helpful when debugging failing requests in the front-end, or to make it easy for a backend developer to replicate a request error.

Highlight initiators

Hold the Shift key while hovering over the list of requests to see how different requests relate to each other.

The request's initiator is shown in green. Requests that it initiated are shown in red.

View request initiators in Chrome DevTools

Export and import HAR

If you want to share more in-depth debugging information you can export an HTTP Archive (HAR) file that contains information about all requests made on that page.

Another developer can then investigate the issue on their machine and figure out what went wrong.

The import/export HAR buttons are in the top right corner of network tab.

DevTools import and export HAR buttons

Viewing request headers and response status

Click on each request to view the request headers as well as the response headers and status returned by the servers.

Here you can see what cache settings the server provided, or what cookies were sent along with the request.

DevTools network details showing request and response headers

Filtering requests

Click on the funnel icon to search the list of requests or only show specific request types.

The search filter supports regular expression, so if you want to see both CSS and font files you could use /css|woff2/ as a filter.

DevTools network requests regex filtering

You can search the response text of all page requests using the search feature. Click on the magnifying glass to the left of the "Preserve log" checkbox to start a search.

Full-text search in Chrome DevTools

Monitoring site speed over time

DebugBear is a site speed monitoring service that continuously tests your website.

In addition to keeping track of site speed metrics, we also provide in-depth debug data to help you speed up your website and understand performance regressions.

Page weight regression in DebugBear

Get a monthly email with page speed tips