Waterfall UI Conventions

August 26, 2011 5:18 pm | 9 Comments

I spend a lot of time looking at HTTP waterfall charts. Each browser has its own waterfall chart tool which makes sense since the way to track network events differs across browsers. There are some tools that span multiple browsers, like HttpWatch. Since I work across all browsers I’m impacted by the lack of UI consistency across these tools. This blog post summarizes the current state and proposes the adoption of waterfall UI conventions.

It’s easy to see the inconsistencies looking at these waterfall charts from the tools I use most frequently.* Each screenshot shows the waterfall for Wikipedia. The main areas I’m going to discuss are the colors and names for connection states, Content-Types, and loading events. There are many other areas where consistency would be nice – such as overall layout and default columns – but those are more subjective and the tool owner might feel their choices make their tool more preferred. The consistency changes I’m suggesting don’t effect the information shown, just how it looks.

One big difference is the information shown in the horizontal bar. Chrome Developer Tools uses the horizontal bar to reflect the Content-Type: blue for HTML, green for CSS, purple for images, etc. All the other tools use the bar to show the length of each connection state: DNS lookup, sending the request, downloading the response, etc. I find the Content-Type more useful, but rather than debate one over the other I most like HttpWatch’s approach where they show both: the connection states in the bar and the Content-Type in a tiny icon (see the “Type” column). Even if the other tools didn’t want to show icons, they could use font colors to reflect Content-Type. Let’s explore the connection states and Content-Type choices across the tools.

Connection States

The names and colors used for the different network connection states vary across the tools. In some cases, the granularity of connection states varies as well. The colors and names used by each tool are shown in this table:

Let’s look at the names first. Chrome Dev Tools and Firebug use the same names for every connection state: Blocking, DNS Lookup, Connecting, Sending, Waiting, and Receiving. All of these names are progressive verb forms except “DNS Lookup” – saying “looking up DNS” would be painful. I’d prefer simple verb forms which would also give us consistent tense across all names: Block, Lookup DNS, Connect, Send, Wait, and Receive. It’s also important to get similar connection states across all tools: IE9 Dev Tools and WebPagetest don’t show blocking and combine send & wait into a single state.

The colors are much more inconsistent. Chrome Dev Tools uses the same color for all states. The rest of the tools have almost no overlap. Here’s my proposal:

• Block (gray) – because nothing is really happening
• Lookup DNS (yellow) – like the Yellow Pages
• Connect (red) – because this is the tricky negotiation part (red is caution)
• Send (blue) – it’s a good color that contrasts well with red
• Wait (light purple) – a mellow color while we wait
• Receive (green) – because this is the payment that’s been received (green like money – sorry for the U.S. bias)

These are subjective choices and I’m open to other proposals. I most care about gray for Block and yellow for Lookup DNS. I also defer to someone who understands the color wheel. (I painted for years but never learned.)

Content-Type

Chrome Dev Tools is the only tool that reflects the Content-Type in the waterfall’s horizontal bars. The choice of whether to use the horizontal bar to show Content-Type or connection states is up to the tool developer. My preference would be to follow Chrome Dev Tools and use the bar to show Content-Type. A pop-up or detail view could be used to see the connection state information. Chrome Dev Tools, Firebug, HttpWatch, and IE9 Dev Tools already display a detailed view of connection states when you select a bar.

Regardless of the information shown in the horizontal bars, users would benefit in other ways from consistent colors mapped to Content-Type. This color mapping could be used as the text color in the waterfall chart and in charts of total requests and download size broken out by Content-Type.

The color map from Chrome Dev Tools is:

• HTML (blue)
• JavaScript (orange)
• CSS (green)
• images (purple)
• text/plain (yellow)
• redirect (gray)

I’m fine with these colors. If it was up to me I’d make JavaScript red because I have so many errors in my JavaScript. I’d make CSS purple because that’s “fancier” (CSS is used to make pages look more stylish). I’d make images blue because they’re the most common resource type and my world is mostly blue (it’s a denim thing, not emotions). That leaves green for HTML. But again, purely subjective.

Load Events

Many of the tools draw a vertical line to mark the DOMContentLoaded and window load events. Again, the names and colors vary across the tools:

I like DOMContentLoaded and Load because I understand exactly what’s being measured. I’m less concerned about the colors; I’d pick blue and green if it was up to me.

Now what?

I’m working with Brian Pane and Jan Odvarko on some UI changes to Jan’s (Honza’s) HAR Viewer. I hope we’ll add Content-Type icons, in which case other tools could adopt those. If you’d be willing to create those icons please contact me.

As for the names and colors, I’m not sure how to proceed. Mark Nottingham suggested starting an “ether pad or wiki page”. I’d appreciate comments on these ideas and ways to move forward. Greater consistency across these tools will make it easier for developers to get on the web performance bandwagon, which is something I hope we all want.

9 Comments

HTTP Archive: nine months

August 17, 2011 8:02 pm | 6 Comments

Although the HTTP Archive was announced in March, I actually started gathering data back in November of 2010. This week’s run marks nine months from that initial crawl. The trends show that performance indicators are mixed, with some critical metrics like size and redirects on the rise.

[As a reminder, the HTTP Archive currently crawls approximately 17,000 of the world's top websites. All of the comparisons shown here are based on choosing the "intersection" of sites across all of those runs. There are ~13K sites in the intersection.]

The transfer size of pages has increased 15% (95 kB) over nine months. The average size is now up to 735 kB. Note that this is the transfer size. Many text resources (including HTML documents, scripts, and stylesheets) are compressed so the actual size is larger. The bulk of this growth has been in images – up 18% (66 kB). Scripts have had the greatest percentage increase growing 23% (25 kB).

Nov 15 2010:

Aug 15 2011:

Note that these sizes are the total size of all images in the page and all scripts in the page, respectively. The average size of individual resources has stayed about the same over this nine month period. If individual resource size is the same, how is it that the total page size has increased? The increase in total transfer size is the result of a 10% increase in HTTP requests per page – that’s seven more resources per page.

Redirects are known to cause page delays, and yet the percentage of sites containing at least one redirect increased from 58% to 64%. Requests that fail are wasteful using connections that could have been used more productively, but sites with errors grew from 14% to 25%.

All the news isn’t gloomy. The use of Google Libraries API has increased from 10% to 14%. This is good for performance because it increases the likelihood that as a user navigates across sites the most common resources will be in their cache. In addition, serving those from the Google Libraries servers might be faster and more geographically distributed for smaller sites.

The use of Flash has dropped 2% from 47% to 45% of websites. Flash resources average 58 kB which is much larger than other resources, and there are fewer tools and best practices for optimizing Flash performance.

There are still many resources that do not have the necessary HTTP response headers to make them cacheable. Luckily the trend is moving toward more caching: the 61% of resources that did not have headers to make them cacheable has dropped to 58%. Stating the inverse, the number of resources with caching headers grew from 39% to 42% (+3%).

Here’s a recap of the performance indicators from Nov 15 2010 to Aug 15 2011 for the top ~13K websites:

• total transfer size grew from 640 kB to 735 kB
• requests per page increased from 69 to 76
• sites with redirects went up from 58% to 64%
• sites with errors is up from 14% to 25%
• the use of Google Libraries API increased from 10% to 14%
• Flash usage dropped from 47% to 45%
• resources that are cached grew from 39% to 42%

My kids started school this week. I’m hoping their first report card looks a lot better than this one.

6 Comments