What do the colors within the horizontal bars in Web Performance HTTP Waterfall Charts indicate?

A HTTP Waterfall chart can provide a quick visualization of what is wrong with a slow loading website.

Chapter 3 of Stoyan Stefanov's Book of Speed has a nice explanation of what the colors in the a bar of Waterfall view (of twitter.com) generated by WebPageTest, mean:

Dark green represents the time taken to perform a DNS lookup. DNS (Domain Name Service) lookup is the process of matching the friendly domain name twitter.com to an IP address (such as 128.242.240.20), which the browser needs in order to know how to get in touch with the server. Think of the DNS lookup as being like a phone book: your browser knows the name (twitter.com) but needs the number (the IP address).

You can see on the waterfall chart on Figure 3.2. that a separate DNS lookup needs to be done for every domain (twitter.com, a1.twimg.com, a3.twimg.com, s.twimg.com) because sub-domains may live on a different server with a different IP address. 

Orange is the time to establish a connection between the server and the browser. 

Light green is the time-to-first byte (TTFB) when the browser waits for the very first piece of information to be sent by the server. In the case of dynamic HTML pages this is the time spent to assemble the whole page on the server. If you're busy optimizing databases and server-side code, you'll actually be optimizing the TTFB of the page. As you can see, in the grand scheme of things, this is not where you should be focusing because it has relatively low impact (unless, of course, there's something seriously wrong on the server-side)

Blue is the time spent actually downloading the component 

More interpretation tips from Patrick Meenan's Web Performance Waterfalls from 10,000 Feet

The light green part of the bar is the amount of time from when the browser sent the request until the server response started to come in. Optimally this would be the same size as the orange bar that immediately precedes it which is the time to establish the connection to the server (and a good proxy for the round trip time). If the green bar is noticeably longer than the orange bar then there is a back-end problem that should be looked at.

Yellow-highlighted rows in the waterfall indicate server HTTP responses in the 300 range.

Red-highlighted rows in the waterfall indicate server HTTP responses in the 400+ range with 404 (not found) responses being the most common. 

The vertical pink bar in a waterfall is the amount of time it took the browser to execute script attached to the DOMContentLoaded event (which includes JQuery $(document).ready() code).

If you see a long bar in the waterfall without many other requests happening at the same time and then a bunch of requests appear to start after it finishes loading you are looking at a blocking resource dependency.

When you see large blue bars it usually indicates really large resources that are being downloaded (particularly if the green bandwidth graph at the bottom of the waterfall is pegged). 

The vertical green line in the waterfall is the point where the browser displays the first non-white part of a page to the user. You want that to be as far to the left as possible..

With reference to the WebPagetest Waterfall Chart, Tammy Everts lists 5 goals for every waterfall chart:
1. The vertical “start render” and “document complete” lines should occur as early as possible, and these lines should be as close to each other as possible.
2. As few rows as possible.
3. As few orange bars as possible.
4. Bright green bars that are as few and as short as possible.

5. As little blue as possible.

As Steve Souders has rightly pointed out, different Web Performance tools & the Dev Tools within browsers use different colors in the horizontal bars in Waterfall Charts and that makes it a little difficult for web developers to interpret a waterfall chart which is different from what they typically use.

Table from Steve Souder's blog showing inconsistency in colors used in horizontal bar within HTTP Waterfall chart

Zoompf found that websites with the top search rankings had TTFB as low as 350 ms. They recommend that ideal targets for your initial HTML page load should be:

• Time to First Byte of 500 ms or less
• Roundtrip network latency of 100 ms or less
• Back-end processing of 400 ms or less

TTFB has 3 components: the time it takes for your request to propagate to the web server; the time it takes for the web server to process the request and generate the response; and the time it takes for the response to propagate back to your browser. Latency captures the first and third components of TTFB, and can be measured effectively through tools like WebPageTest and ping. Server processing time is simply the overall TTFB time minus the latency.