What do the whiskers represent in the Chrome DevTools network performance analysis?

Question

I am analyzing the timings of network requests, and I found that the performance tab gives additional information about timing compared to the Network tab.

In the screenshot below, requests are shown with long whiskers and I would like to understand what they are and the common ways to reduce them if that is possible.

Answer 1

Google calls it a "line-bar representation" rather than "box and whisker plot", but here's what you're looking for:

• The left whisker is everything before Request Sent, not including Request Sent itself.
• The right whisker is time spent waiting in the main thread, as @wOxxOm commented above, it's time where the response came back across the network, but the browser is so busy doing other things that your code hasn't received it yet.

The box itself is divided into a light and dark portion as well, detailed below.

Per the developer reference, this is the relevant bit:

Figure 24. The line-bar representation of the www.google.com request

In Figure 24, the request for www.google.com is represented by a line on the left, a bar in the middle with a dark portion and a light portion, and a line on the right. Figure 25 shows the corresponding representation of the same request in the Timing tab of the Network panel. Here's how these two representations map to each other:

• The left line is everything up to the Connection Start group of events, inclusive. In other words, it's everything before Request Sent, exclusive.
• The light portion of the bar is Request Sent and Waiting (TTFB).
• The dark portion of the bar is Content Download.
• The right line is essentially time spent waiting for the main thread. This is not represented in the Timing tab.

TTFB is "Time-to-First-Byte", in case that wasn't contextually obvious, the time until the browser receives the very first response packet.

Edit - Some additional commentary on the image in the original question: Left Whiskers: The implication is that the browser understands your first two requests at roughly 1681ms and 1682ms, respectively. The browser is busy and takes ~18ms to actually put the first request on the wire, but the second request only takes a ms to put on the wire.

Box (Light and Dark Portions) The first request takes about 6ms to send and wait for server processing before receiving the first response packet, and receiving the whole response only takes ~1ms. The second request takes only ~1ms to be sent and processed and another ~1ms to pull down all of it.

Right Whisker Here's where it gets weirder. The browser is so busy in the Scripting phase (the yellow hump in the top section of the stacked area chart in the relevant filtered time block) that it doesn't appear to acknowledge the network responses until 1748ms and 1752ms, respectively, on the overall timeline. This implies that whatever is supposed to happen with those two results could happen ~43ms and ~68ms sooner, respectively, if the main thread had yielded sooner.

If you have long running synchronous code, you might consider setTimeout(fn, 0) or setImmediate(fn) for yielding the thread and letting I/O stuff finish up. setImmediate is not actually browser supported, but oft polyfilled, so you might have it available.