Identifying Common Network Bottlenecks<!-- --> | <!-- -->Web Performance Tips

Identifying Common Network Bottlenecks

In this tip, we'll look at common network bottlenecks, how they manifest in Chromium Profiler, Network Tab, and how you can quantify them in your own web application!

Prerequisites

You should be familiar with:

Network Request Lifecycle

Each network request, whether it's the initial HTML document navigation request or a JavaScript subresource is subjected to the same phases of loading over the network:

Each phase of a network request loading pictured in a diagram

These phases have corresponding timestamps, also pictured in the diagram by the arrows.

I specifically will not be talking about Redirects or the deprecated App Cache phase in this tip, so we'll examine our requests' lifecycle phases of DNS, TCP, Request and Response:

The phases we'll be discussing: DNS, TCP, Request, and Response

In the diagram above, the labeled arrows (i.e. connectStart, connectEnd, etc.) represent timestamps that mark the start or end of the request lifecycle phase. The rectangular blocks represent the duration attributed to each phase (i.e. TCP).

Resource Timings

The browser conveniently logs the timestamps (in milliseconds) for each phase of our network requests. These timestamps are known as Resource Timings, and you can access each timestamp by using the following APIs:

// Quantify the timing of the initial navigation request (initial document)
const navigationTiming = window.performance.getEntriesByType('navigation')[0];

// Quantify the timing of each subresource (JS, CSS, Image, etc.)
const subresourceTimings = window.performance.getEntriesByType('resource');

The shape of the object returned will resemble the following (I've hidden some properties for simplicity):

{
    // DNS
    domainLookupStart: 2,
    domainLookupEnd: 4,

    // TCP
    connectStart: 4,
    connectEnd: 8,

    // Request + Response Transfer
    requestStart: 8,
    responseStart: 900,
    responseEnd: 1000,

    // Request Type
    entryType: "navigation",
    name: "https://www.wikipedia.org",

    // Navigation Requests always start at 0
    // Subresources (JS, Images, etc.) will not
    startTime: 0
}

These timings are quite handy for us to connect into telemetry systems and to create user-representative performance dashboards.

If we look at the above request entry we can attribute the following time to each phase:

  • DNS: domainLookupEnd - domainLookupEnd = 4 - 2 = 2 milliseconds
  • TCP: connectEnd - connectStart = 8 - 4 = 4 milliseconds
  • Request Sent, Waiting for Response: responseStart - requestStart = 900 - 8 = 892 milliseconds
  • Response Transferring: responseEnd - responseStart = 1000 - 900 = 100 milliseconds

From computing time for each phase, we can clearly see the bottleneck here is the Request Sent, Waiting for Response phase.

The Chromium DevTools utilize these timings to help us visually identify bottlenecks.

Box Diagrams

If we mapped these quantities to scale in a simple box diagram, it would look like this:

The quantified network request mapped to size in a box diagram

By plotting the timestamps visually, it becomes even more apparent that there's a bottleneck in the Request Sent, Waiting for Response phase.

In the Chromium F12 Profiler's network pane, the tool will combine the DNS, TCP, and other request-preparation phases, and group that into Request Preparation time. The Profiler also will colorize the Waiting for Response time in a lighter color, indicating no bytes are transferring during that time:

An example box diagram, similar to what's produced in the Chromium Profiler

An example of this, captured in our profiler trace would look like this:

A box diagram produced by the Chromium Profiler

Waterfall Diagrams

Another way to visualize the lifecycle of a request is to use a waterfall diagram. If we represented our above resourcing timing as a a waterfall, it would look like this:

An example waterfall diagram for our sample request

We can view the waterfall for each request by selecting the Request in the Network tab, and then the Timing tab:

A waterfall diagram produced by the Chromium Network Pane

Common Bottleneck 1: Long Waiting Time

One of the most common bottlenecks I see follows the theme we've been describing so far in this tip -- a request dispatched is often waiting for the backend to reply with the payload for an extended amount of time.

This will manifest as a long Request Sent, Waiting for Response time. Visually, it'll look like this in the profiler:

A long waiting time example request

Its waterfall diagram will look like this (similar to what we've seen so far):

An example waterfall diagram for our sample request

In your Resource Timings, you would see a sizeable time gap between requestStart and responseStart.

This will manifest most often in cases of:

  • A slow backend -- it's taking an extended period of time to produce a response back to the client
  • A distant backend -- it's taking a long time to reach the backend and/or be notified of the backend's response

Common Bottleneck 2: Long Download Time

Another common network request shape I see is an inverse of the one we've described. In some cases, the target backend is fast at returning a response, but the payload is large, and takes considerable time to download.

This will manifest commonly as a short or moderate Request Sent, Waiting for Download time, and a long Response Download time:

A long waiting time example request

Its waterfall diagram will resemble this:

A long waiting time example waterfall

In your Resource Timings, you will see a sizeable time gap between responseStart and responseEnd.

This will manifest often in the case of a CDN, which are fast at responding to client requests, but often transfer large payloads (i.e. large images or JavaScript files).

Response Download time is directly impacted by a resource's Transfer Size, so you should ensure it's optimized for delivery.

Conclusion

Using the browser's Resource Timings and DevTools visualizations can help us identify Networking inefficiencies in user and local sessions.

Make sure to use these tools to make informed decisions about optimizing your web application's network dependencies!

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