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

HTTP Archive: 1M URLs, Internet Archive, Sponsors

June 15, 2011 10:28 am | 4 Comments

The HTTP Archive provides a permanent record of web performance information. It started in October 2010 crawling 1K URLs. This was possible thanks to Pat Meenan’s help providing access to WebPagetest. A month later we increased coverage to the world’s top ~18K URLs. That was good, but the next step is 1M URLs. Today at Velocity I made two announcements that pave the way for achieving this goal.

Starting today the HTTP Archive is part of the Internet Archive. I met Brewster Kahle several years ago and have always admired the work the Internet Archive has done building a “digital library of Internet sites.” When I approached him about this merger we both saw it as an obvious fit. In addition to preserving a record of the content of these sites (via the Wayback Machine) we agreed it’s important to record how that content is built and served. It makes sense that researchers, historians, and scholars be able to find both sets of information under one roof. I’ll continue to run the HTTP Archive project.

The following companies have agreed to sponsor the work of the HTTP Archive: Google, Mozilla, New Relic, O’Reilly Media, Etsy, Strangeloop, and dynaTrace Software. In order to grow to 1M URLs we need data center space, servers, licenses, etc. Thanks to these sponsors we’ve started to build out this infrastructure and will be increasing our coverage soon.

I look forward to working with the Internet Archive on our mission of preserving a record of the Web for generations to come. If you would like to join the effort, I invite you to make a donation to the Internet Archive and contribute your coding skills to the open source project.

4 Comments

Site redesign

February 6, 2011 4:30 pm | 11 Comments

The list of things I’m good at does not include web design. As a result, this was how my website looked for the past few years:

Over the holidays I was lucky enough to get connected with Emily Matthews from NOLA Marketing who came up with a new design for stevesouders.com:

Around the same time I met Jennifer Stuart who develops, among other things, WordPress themes. She took the design and developed a custom theme for my blog from which I lifted parts to integrate back into the main site.

Shout outs to Emily and Jennifer – thanks for making my site look so much better!

11 Comments

Twitter vs blogging

September 15, 2010 2:21 pm | 8 Comments

My rate of blogging has dropped dramatically since I saw how @dalmaer was able to get so much news out via Twitter. I was slow to adopt Twitter, but now I love it. If you follow my blog but aren’t following me on Twitter, you should start following me: @souders. Here are some of the important tweets I’ve made in the last few days:

• IE 9 Beta is now available in http://WebPagetest.org – let’s hear it for @patmeenan!
• IE blog about need realistic benchmarks http://bit.ly/a3WR1c; Mozilla announces “Kraken focuses on realistic workloads” http://bit.ly/9wMGYn
• VCs tend to back companies with fast web sites (via @joshuabixby) – http://bit.ly/aLXaIf
• Do you use <meta name=”viewport” content=”width=device-width”> in your mobile web app? You should (via @ppk). http://bit.ly/9IuhzT
• Browserscope shows IE9 beta’s network behavior is improved. I’m surprised scripts & images can’t download in parallel. http://bit.ly/dpileW
• IE6 is now available on http://WebPagetest.org for Dulles, VA. Awesome work by Pat Meenan.
• Great survey of how YSlow score relates to page load time from Yottaa: http://blog.yottaa.com/2010/09/how-important-is-my-yslow-score/
• be careful using Web Inspector for performance analysis; JS execution can cause network events to be mistimed; Speed Tracer has same problem
• Had to file a FF bug and forgot the URL. Then remembered this Browser Resources page from Browserscope: http://www.browserscope.org/browsers
• About to start the first meeting of the W3C Web Performance Working Group: http://www.w3.org/2010/webperf/

You get the idea. I won’t do this blog-retweeting again, but if you care about web performance I hope you’ll follow me on Twitter.

@souders

8 Comments

WebPagetest.org and Page Speed

September 7, 2010 9:36 am | 2 Comments

Pat Meenan just blogged about Page Speed results now available in Webpagetest. This is a great step toward greater consistency in the world of web performance, something that benefits developers and ultimately benefits web users.

I’ve been spreading the meme about WPO – the industry emerging around web performance optimization. I contend that in the early evolution of a new technology industry it’s better to strive for standardization and worry about differentiation later once the technology movement is well established.

One area where WPO needs more standardization is performance analysis. There are numerous performance analysis tools available, including Page Speed, YSlow, AOL Pagetest, MSFast, VRTA, and neXpert. There’s some commonality across these tools, but the differences are what’s noticeable. To get a thorough performance scrubbing, web developers have no choice but to run multiple tools and sift through the different results trying to find the most important recommendations. It would be better for developers to have a more standard way of analyzing performance across environments.

The Page Speed SDK provides a path to achieve this. When it was released, I easily stood up a web page that produces a Page Speed performance analysis from HAR files. Today, Pat has integrated the same SDK into WebPagetest.org. With wider adoption of the Page Speed SDK, we’re moving to having a more consistent performance analysis regardless of what browser and development environment you work in.

2 Comments

cross-browser Greasemonkey scripts

May 18, 2010 1:37 am | 4 Comments

I love customizing web apps and browser behavior. I want my web my way! So bookmarklets, Greasemonkey scripts, and browser add-ons are some of my favorite things to work on. When searching for the right implementation I approach the problem in that same order:

• bookmarklets - If I can accomplish my goals with a bookmarklet, I stop there. This means it works cross-browser without installing a plugin.
• Greasemonkey scripts – If I want my custom behavior to happen automatically, I step up to Greasemonkey. Besides automatically launching my script, there are some other extras that come with Greasemonkey such as cross-site XHR and menu manipulation. Checkout the Greasemonkey API for a full list of functions. But API support, and support for Greasemonkey itself, varies by browser (we’ll get to that in a minute).
• Browser add-ons – Browser add-ons have the most power, access, and UI control. But they only work on a single browser. (At least until someone ports Jetpack to more browsers.) The implementation stack varies by browser (lowers likelihood of reusing code). Installation can be cumbersome for users, and hosting is harder for developers. Updates are more automated, which is nice.

Greasemonkey covers a nice middle ground. Easy to develop and more features. Up until recently, though, I thought of Greasemonkey scripts as being only for Firefox. That’s no longer the case.

Greasemonkey was created by Aaron Boodman for Firefox back in 2005. He works on Chrome now, so it was awesome when Aaron announced that Greasemonkey scripts are supported in Chrome. When I started researching it this week, I was surprised to find out that Opera supports Greasemonkey scripts (aka, “user scripts” and “user JavaScript”) starting back with Opera 8. So Firefox supports Greasemonkey scripts through the original Greasemonkey add-on. Chrome and Opera have built-in support for Greasemonkey scripts.

Safari and Internet Explorer don’t have built-in support for Greasemonkey scripts. And they also don’t have (what I would call) solid add-on support for Greasemonkey scripts. I read that in Safari you can use SIMBL and Greasekit to make Greasemonkey scripts work. In IE, Trixie is suggested. In this post I’m going to focus on Firefox, Chrome, and Opera, but I’d appreciate comments about people’s experiences in Safari and IE with these or other plugins that give Greasemonkey support.

my example: TwitterHistory.user.js

I mostly read Twitter in Firefox on my laptop. One feature I’ve wanted forever is an indicator of the last tweet I’ve read, so I can quickly see how much new stuff there is. Ditto for mentions. So I wrote a Greasemonkey script that implemented these features: twitterhistory.user.js. Now my Twitter looks like this:

Tweets that I’ve already read are grayed out, and there’s a thick gray bar dividing the read from the unread. The key features needed are:

• remember the newest-viewed-tweet - All tweets have an ascending number in their id, so all I need to do is save the id of the first tweet in the list.
• gray out the tweets – The next time the user comes to the page, since I know the number of the newest-viewed-tweet I can iterate over all the visible tweets and gray out the ones with a lower number.
• add a handler to various navigation links – A tricky part is figuring out when to remember the newest-viewed-tweet, and when to gray out the visible tweets. Doing this at page transition is obvious – gray out the already read tweets when the page loads, and save the newest-viewed-tweet when the page unloads. But Twitter is very Ajaxified. For example, clicking the “more” link at the bottom adds more tweets that might need to be grayed out. And clicking the “Home” and “@souders” navigation links causes the list of tweets to change, which means saving the newest tweet number and graying out the new list needs to happen. To achieve this I add an onclick handler to those links.

Getting the Code to Work

Let’s look at how these features get implemented as a Greasemonkey script that works across Firefox, Chrome, and Opera.

Firefox

The Greasemonkey add-on for Firefox provides an API that includes GM_setValue and GM_getValue. These work great to save and retrieve the ID of the newest-viewed-tweet. Graying out tweets was a simple matter of iterating over the items in a list and comparing each id to the newest-viewed-tweet value. Adding the handlers was tricky. In order for these callbacks to persist from the Greasemonkey script to the main page’s event loop, I had to use the unsafeWindow variable from Greasemonkey. Without this, the handlers don’t work, as demonstrated in my Greasemonkey Test Page. This took less than an hour to code up.

Chrome

I had never built a Greasemonkey script for Chrome before, so I had some learning to do. First off, there’s no Greasemonkey API in Chrome. Therefore, unsafeWindow doesn’t exist, but it turns out using window works just fine (as shown in the Greasemonkey Test Page). So I defined a proxy variable that refers to unsafeWindow if it exists, otherwise window. One stumble I had here was trying to detect programmatically if GM_setValue and GM_getValue are defined. It turns out they are defined in Chrome! But they don’t do anything:

function() {
    console.log("%s is not supported.", api);
}

Since GM_setValue and GM_getValue don’t work, I fallback on localStorage (see Greasemonkey API emulation for Chrome). If localStorage doesn’t exist, I use cookies (a la PPK). Two browsers down. One to go.

Opera

The main trick with Opera was figuring out how to install the scripts. I talk about that more under Installation. Once I figured that out, there was only one issue to resolve and it had nothing to do with Greasemonkey. In the case of Opera, I need to use onunload instead of onbeforeunload.

Installation

Installing Greasemonkey scripts is easiest in Chrome. You just enter the script’s URL (for example, http://stevesouders.com/twitterhistory.user.js) and it works the next time you visit the page. The UI for managing scripts is available under wrench | Extensions or chrome://extensions/.

Firefox is second easiest. You first install the Greasemonkey add-on, then just navigate to the script’s URL. Managing scripts is done via Tools | Greasemonkey | Manage User Scripts.

Opera was slightly harder to figure out. You go to Opera menu | Settings | Preferences | Advanced | Content | JavaScript options and enter the directory where you want the scripts to be saved. Then you manually download the scripts and save them there. It’s straightforward, but kinda clunky and buried. But it works!

Development

I learned some time saving lessons while developing my Greasemonkey script across these browsers.

Create a landing page for your script - The URL of Greasemonkey scripts aren’t kept in location history for Firefox and Chrome, so you’re constantly typing or pasting it. It’s much easier to have a landing page that’s always open where you just click a link to re-install the script, for example my TwitterHistory landing page. This works best if your script isn’t cacheable…

Make your Greasemonkey script UNcacheable – As I make changes to the script I want to re-install it as easily as possible. Having to clear my cache each time is a pain. I can skip that step by adding a “Cache-Control: no-cache, must-revalidate” response header. Now when I click on the link in my landing page to re-install my Greasemonkey script, I get all the updates in Firefox. For Chrome, I still need one more step…

Uninstall in Chrome – Even with a landing page and a Greasemonkey script that’s not cacheable, re-installing doesn’t pick up the changes in Chrome. First you have to go to chrome://extensions/ or Tools | Extensions and click the Uninstall link for your script. So I have two tabs open all the time in Chrome – my landing page and chrome://extensions/. After I save my script changes on my server, I uninstall the script, and then re-install it from my landing page.

JavaScript errors show up in Chrome, but not Firebug – I’m a big Firebug fan, but was disappointed to see that errors in my Greasemonkey script didn’t show up in Firebug’s Console. You do see JavaScript errors in Chrome’s console (accessed via page | Developer | JavaScript console).

Now you can tryout my TwitterHistory Greasemonkey script in Firefox, Chrome, and Opera. Visit Greasespot to read more about Greasemonkey. Add comments below for other tips that you’ve found to make Greasemonkey scripts work across browsers.

4 Comments

HAR to Page Speed

May 1, 2010 9:48 pm | 11 Comments

Here’s the story behind this nifty tool I cranked out this weekend: HAR to Page Speed

HTTP Archive Specification

About a year ago I was on the weekly Firebug Working Group call when Jan (“Honza”) Odvarko said he was going to work on an export feature for Net Panel. I love HttpWatch and had used its export feature many times, but always wished there was an industry standard for saving HTTP waterfall chart information. In the hope of achieving this goal, I introduced Honza and Simon Perkins (creator of HttpWatch) and suggested that if they developed an open format it would likely evolve into an industry standard.

A few months later they published the HTTP Archive specification and had integrated it into their products. My contribution? In addition to planting the idea with Honza and Simon, I chose the three character file extension: .HAR. Support for HAR is growing. In addition to being part of Firebug (via Honza’s NetExport add-on) and HttpWatch, it’s also in ShowSlow, DebugBar, Http Archive Rule Runner, and a few other tools and sites out there. (I hear it’s coming to Fiddler soon.)

The importance of an industry standard HTTP archive format is huge. Adoption of HAR allows companies and data gathering institutions (such as the Internet Archive) to record the web page experience and pull it up later for further review. It provides a way to exchange information across tools. And it provides an open standard for sharing web loading information between individuals – developer to developer as well as customer to customer support.

Page Speed SDK

In their last few releases the Page Speed team has mentioned porting their performance analysis logic from JavaScript to C++. The resulting library is called “native library” – not too jazzy. But last week they released the Page Speed SDK. The documentation is slim, but I noticed a commandline tool called har_to_pagespeed.

Hmmm, that sounds interesting.

I downloaded the SDK. It built fine on my Dreamhost shared server. Then I wrapped it with a file upload PHP page and created HAR to Page Speed.

You start by uploading a HAR file. If you don’t have any or simply want a quick test drive, you can use one of the examples. But it’s easy to create your own HAR files using Firebug and NetExport. The latter adds the “Export” item to Firebug’s Net Panel.

Now comes the fun part. After uploading a HAR file you get the output from Page Speed. (Note that this is a subset of rules. Some rules still need to be ported.)

I also threw in a rendering of the waterfall chart based on Honza’s HarViewer:

Compellingness

My HAR to Page Speed page is handy. If you’re generating HAR files in something other than Firefox, you now have a way to get a Page Speed analysis. If you’ve got an archive of HAR files, you can analyze them with Page Speed at any time in the future.

But the big excitement I get from this page is to see these pieces coming together, especially in the area of performance analysis. Another industry initiative I’ve been advocating is a common performance analysis standard. Right now we have multiple performance analysis tools: Page Speed, YSlow, AOL Pagetest, MSFast, VRTA, and neXpert to name a few. There’s some commonality across these tools, but the differences are what’s noticeable. Web developers really need to run multiple tools if they want their web site to be evaluated against the most important performance best practices.

With the adoption of HAR and Page Speed SDK, we’re moving to having a record of the page load experience that can be saved and shared, and performance analysis that is consistent regardless of what browser and development environment you work in. We’re not quite there. We need more tools to adopt HAR import/export. And we need more rules to be added to the Page Speed SDK. But I can see the handwriting on the wall – and it’s spelling F-A-S-T.

I’ll be talking about these and other movements in the performance industry this Wednesday at Web 2.0 Expo SF.

11 Comments