Can Chrome DevTools' Network be used like this?

If you were to pick the most used feature in Chrome DevTools, Network would definitely be one of them.

As front-end engineers, when we see a web page, we habitually open Chrome DevTools to view the network requests.

However, although it is used every day, there are still some advanced functions that most people don’t know about.

Today, let’s sort out some very useful but less known functions:

filter

A website will have many requests. When you want to find a certain request, how do you filter it?

Keyword search?

But keyword search can only be filtered based on URL.

Many times this isn't enough.

For example, if I want to search for video requests, how can I filter them based on the URL? For example, if I want to search for requests larger than 1M, how can I filter them based on the URL?

This is when you can use the filter function.

Enter mime-type followed by a colon, and Chrome DevTools will list all mime types requested by the current web page. Select a certain type and it will filter out requests of that mime type.

For example, to filter mp4 requests:

Filter webp requests:

Or, instead of mime-type, filter by the general category of the resource:

Enter resource-type and add a colon or press the right arrow key to display all resource categories, including document, stylesheet, image, etc.:

In fact, this is the Network part:

You can also hold down the command key to make multiple selections.

In addition to resource types, you can also filter by status code:

For example, 200, 404, 500, etc., but the page I tested did not have any requests like 404.

Status code 0 represents a deleted or canceled request. Network requests can be canceled, and this can be filtered by status code 0.

You can also filter by resource size:

By specifying a size limit of 100, 300k, 2M, etc., you can filter out requests whose size is larger than this value.

You can also filter based on the request method, whether it is GET, POST, etc.:

Filter based on whether a response header is included:

has-response-header:Set-Cookie filters out requests that have set cookies.

has-response-header:access-control-allow-origin filters out requests that support cross-domain requests

Filter by whether a certain cookie is included:

The commonly used filters are:

• has-response-header: Filters requests whose responses contain a certain header
• method: filter requests based on GET, POST and other request methods
• domain: filter by domain name
• status-code: Filter requests with response code xxx, such as 404, 500, etc.
• Larger-than: Filter requests that are larger than a certain size, such as 100k, 1M
• mime-type: filter requests of a certain mime type, such as png, mp4, json, html, etc.
• is: filter requests of a certain status, such as from cache, or running.
• resource-type: filter by request category, such as document request, stylesheet request, fetch request, xhr request, preflight request
• cookie-name: Filter requests with cookies of a certain name

Of course, you don't need to remember these, just type a - and all the filters will be displayed:

But the minus sign should be removed, it means negative:

Same function as the inert option on the right.

Moreover, these filters can be combined by adding a space in between.

But some students may ask, these filters do not seem to support filtering based on content.

Indeed, the filter does not support this, but you can search it yourself:

developer resources

Seeing the sourcemap, some students may ask, by the way, why can't the sourcemap file be seen in the Network?

The sourcemap file will obviously be downloaded, why have I never seen it?

In fact, this is filtered out by the Network, and the request to see these files is in another place:

Click show console drawer:

Open the developer resources:

You can see all sourcemap requests:

custom columns

What columns are displayed in the request list can be customized:

For example, cookies and set-cookies can see all requests that carry and set cookies:

Check cache-control to intuitively see the cache settings of different resources:

There is a waterfall on the right side of the request list. By default, it shows the request time, but I don’t think this is useful. I prefer to see the time taken for the request response:

So I'll change it to total duration:

In this way, the waterfall shows the time consumption:

You can intuitively see the time taken by the request and sort it. I think this data is much more useful.

Summarize

Today I shared some tips on Network:

To filter requests, you can use filters such as status-code, mime-type, resource-type, etc. You can use - to indicate any filter, but - means yes or no, so you need to remove it later. Filters can be used in combination.

The filter does not support content filtering, you can search for it yourself.

Requests for sourcemap files are not displayed in Network, which can be seen in the development resources panel of dawer.

The request list of Network can customize the columns displayed, and the waterfall can also change the displayed information. I think it is more useful to display the duration.

After learning these Network tips, I believe you will be more efficient when debugging network requests.