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.
Example 1: Youtube homepage
Example 2: Getty Images homepage
By comparison, the Getty Images homepage doesn't require a lot of CPU processing.
Instead rendering is blocked by a large number of concurrent image requests, slowing down a render-blocking script.
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).
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
- Use gzip or brotli to compress the response
- 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).
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.
Here's a site on a fast connection without any throttling.
And here's the same site loaded using the Slow 3G setting.
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.
A network request to a new website consists of multiple sequential round-trips:
- 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.
Again, you can hover over the request to get an explanation of the breakdown.
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.
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
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.
3. Close existing server connections
Go to chrome://net-internals/#sockets and click Flush socket pools.
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 Network settings
Click the gear icon in the top right corners of the Network tab to view the Network tab 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.
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.
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.
You can customize what information Chrome shows about each request.
Right-click on the requests table to select the columns you want to see.
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
This column shows the number of cookies that were sent when making the request.
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.
This is an example of a
fetch call generated by Chrome DevTools:
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.
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.
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.
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.
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.
Full text search
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.
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.