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.
With your profile loaded up, the first pane you will see is the Network pane:
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.
The Chromium F12 Profiler color-codes various network resources types.
CSS resources get colorized as this purple color:
HTML Documents, including IFrames, get colorized as this blue color:
Images, gifs, etc. get colorized as this green color:
JSON API data, Binary resources, and all other resources are colorized as grey:
When you look at requests in the Network Pane, each request has a standard shape:
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.
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:
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.
This phase of the network request indicates the time the browser is waiting for a response.
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.
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.
The most common bottlenecks here are due to:
- Large payload size
- Slow or unreliable user network speed while downloading the resource
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:
The end of the wait time is associated with a Finished Loading or Receive Data event on your web app process' main thread.
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.
You can see more information about a request by selecting it and viewing it's summary in the Summary Pane:
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!