How to Read the Chromium Profiler Network Pane<!-- --> | <!-- -->Web Performance Tips

How to Read the Chromium Profiler Network Pane

Network bottlenecks are one of the most common types of performance issues in web apps I diagnose.

The web fundamentally operates by retrieving remote resources and loading them into the client browser to drive our web applications. Therefore, it's important our web apps load network resources in the most optimal way!

The Chromium Profiler gives us insight into how and when network resources are loading.


You will need to collect a trace and load it into the Chromium Profiler.

Network Pane

With your profile loaded up, the first pane you will see is the Network pane:

A screenshot of the Chromium F12 Profiler, with the Network Pane circled

Note: This is different from the Chromium Network Tab, which is used to view, debug, and replay Network Requests (similar to Fiddler).

While both the Profiler Network Pane and the Network Tab can be used together to investigate network bottlenecks I'll only be discussing the Profiler Network Pane in this tip.

Understanding the UI


The Chromium F12 Profiler color-codes various network resources types.


JavaScript resources get colorized as this orange / yellow color:

A screenshot of orange JavaScript resources loading in the Network Pane.

CSS Styles

CSS resources get colorized as this purple color:

A screenshot of purple CSS resources loading in the Network Pane.

HTML Documents

HTML Documents, including IFrames, get colorized as this blue color:

A screenshot of blue HTML resources loading in the Network Pane.

Image resources

Images, gifs, etc. get colorized as this green color:

A screenshot of green image resources loading in the Network Pane.

JSON Data, Binary, and other resources

JSON API data, Binary resources, and all other resources are colorized as grey:

A screenshot of grey binary resources loading in the Network Pane.


When you look at requests in the Network Pane, each request has a standard shape:

A drawing of a Network Request with different phases.

Queueing Before Send

Requesting data doesn't always translate to the request being sent immediately. The browser utilizes a standalone Network process, which has its own Event Loop that can get clogged up.

The Browser Network Process can also defer some requests via internal notions of prioritization, denoted when you hover over a request.

In this request below, the Network process prioritizes the file as Highest priority, so it has almost no queueing time.

The Network Profiler Pane highlighting a request as Highest priority.

This contrasts with the request entries directly below, which are marked as Low priority, which have more queueing time, despite being requested by at the same time:

The Network Profiler Pane highlighting a request as Low priority.

In addition, if using HTTP/1.1, only 6 parallel connections can be made at a time. If you exceed that limit, you will likely see extended queueing time for some of your connections.

Sent, waiting for data

This phase of the network request indicates the time the browser is waiting for a response.

A Network Profiler request with waiting time circled.

In my experience, if this is particularly long, it's due to two common issues:

  • Slow or unreliable user network speed when trying to establish a connection to the target endpoint.
  • Slow backend, indicating that the target backend is taking a long time to process the request, before sending any data back.

Downloading Data

The most well-known phase, the downloading phase of the network request indicates the time taken to receive all bytes of the resource from the remote endpoint.

A Network Profiler request with download time circled.

The most common bottlenecks here are due to:

  • Large payload size
  • Slow or unreliable user network speed while downloading the resource

Downloaded, waiting for Main Thread

Just because a resource is downloaded doesn't mean it's been received by the process running your web application.

If a resource was able to download successfully, but the main thread of the web app process is too busy to receive it, you will see wait time for the resource to load:

A Network Profiler request with wait time circled.

The end of the wait time is associated with a Finished Loading or Receive Data event on your web app process' main thread.

The most common bottleneck here is due to CPU contention on your web app's main thread; your app is likely too busy running JavaScript or other tasks, so much so it can't process the downloaded data.

Non-blocking behavior

When engineers look at the Profiler and see the Network Pane, it's often the assumption that these network requests in the network pane are "blocking" the app from running.

Although web apps run JavaScript and most other tasks on a single thread, the design of the browser ensures asynchronous tasks are non-blocking.

Network requests are classified as asynchronous, therefore requests in-flight do not pause the UI thread and the UI thread can continue responding to user inputs and executing JavaScript.

In this example, you can see JavaScript executing while a network request is in-flight:

A Network Profiler request and CPU processing happening at the same time.

Selecting a request

You can see more information about a request by selecting it and viewing it's summary in the Summary Pane:

A Network Profiler request selected with summary metadata.


You know can read and understand the Profiler Network Pane!

In future tips, I'll cover common network bottlenecks in depth, and how you can spot them!


That's all for this tip! Thanks for reading! Discover more similar tips matching Beginner, Network, and Profiler.