The traditional focus of performance optimization has been on the backend, i.e. system efficiency. But comparing a number of high profile websites, the Yahoo! team found that frontend performance is responsible for 80-98% of the perceived response time. Therefore doubling the frontend performance gains more than doubling the backend performance. In case studies Yahoo! Search became 40-50% faster, the Yahoo! Mail web application gained 70-100%. Of course there are ways to increase backend performance without throwing in more hardware, but better frontend performance reduces traffic and saves resources.

Saving resources on the client side, particularly CPU usage, also pays off in speed. Event delegation is faster than a large number of event handlers. Likewise we know that reducing the number of HTTP requests through techniques like CSS sprites, sliding doors, or file aggregation increases speed. The reason is the limit of two parallel requests per host imposed by HTTP 1.1. That results in a download queue of two requests at a time, increasing the perceived response time of a page. By configuring additional host aliases for your server you can increase the number of parallel requests — but more than 2-4 also increase DNS lookups resulting in higher CPU usage and slower response times.

I wonder when Yahoo! will present us another impressive calculation how many gigawatts have been preserved by reducing CPU usage in client PCs and in their data centers, as one participant asked in the Q&A part. Energy efficient servers are the next big thing, but are there any concrete suggestions for greener programming? Is AJAX destroying the ozone layer?

Environmental issues aside, here’s the list of rules. I’ll keep it short where I have written about it in my previous article. See the examples and testcases by Steve Souders.

1. Make fewer HTTP requests: This also affects cookies. Eliminate unnecessary cookies, keep them small, set them at granular domain levels (e.g. finance.yahoo.com instead of .yahoo.com), and set an appropriate Expires date.
2. Use a content distribution network (CDN) like Akamai where your (static) content is served from distributed data centers located nearer to your client. Even if your website is not as big as Google you can profit from faster response times by using the YUI library’s own CDN.
3. Add an Expires header not just for images, but also for JavaScript and stylesheet files.
4. Enable gzip: 90%+ of browsers support compression, and gzip is better supported and compresses more than deflate. Gzip HTML files, CSS, scripts, XML, JSON — no images or PDFs.
5. Put CSS at the top, avoid @import as it loads last, even after the images!
6. Move scripts to the bottom as they block parallel downloads even across hostnames and block rendering of any code below them.
7. Avoid CSS expressions as they execute many times and cost CPU.

8. Use external JavaScript and CSS files. Inline CSS is apparently faster for a user’s start page, but not on subsequent pages. After the page has finished loading, use the time to preload scripts to speed up secondary pages.

   1. window.onload = downloadComponents;
   2. function downloadComponents() {
   3. var elem = document.createElement("script");
   4. elem.src = "http://.../file1.js";
   5. document.body.appendChild(elem);
   6. }
9. Reduce DNS lookups for the reasons stated above. Use 1-4 hosts and the keep alive setting.
10. Minify JavaScript with JSMin — inline scripts, too.
11. Avoid redirects as they are the worst form of blocking. Set Expires headers for redirects to enable caching.
12. Remove duplicate files: this is self-explanatory, but it can happen in large teams with many scripts and stylesheets.

13. Mind the ETag: Now this was something I never paid attention to. ETags are unique identifiers to distinguish files that share a URI. They are transmitted in the HTTP header. The default server setting uses the INode, the bytesize and the modification date of a file to calculate a unique ID. Unless servers in a cluster are identical, ETags differ, therefore the files are not cached. Fortunately ETags can be configured in Apache, so it should be possible to match them across different servers.

    1. FileETag MTime Size

    Note that the ETag is also relevant for RSS feeds. For example, currently the W3C talks feed is more or less unusable: some feed readers and services apparently regard the ETag, the feed is mirrored on many servers, so the same news entry from a different server is shown as new and unread multiple times every day…

14. Make AJAX cacheable and small. Some data like a user’s address book or buddy list change infrequently and should be requested via GET, cached, and set with a Last-modified timestamp and gzipped.

These are a lot of rules, and they will be published in a O’Reilly book by Steve Souders and Tenni Theurer in September 2007. Anyway, don’t be overwhelmed by their mass, instead you can start with the easy things: “harvest the low hanging fruit.” Enable caching with the Expire date setting and reduce the number of HTTP requests. You can deal with the rest later.

Finally Nate Koechley announced a Yahoo! performance tool called YSlow as a plugin for the indespensible Firebug extension. He also recommended the commercial IBM Page Detailer, and LiveHTTPHeaders to visualize what’s happening in your browser.

In this post

• Jesse James Garrett
• Molly Holzschlag
• Mark Boulton
• Jon Hicks
• Hannah Donovan
• Shawn Lawton Henry
• Richard Ishida
• Andy Clarke

First off was Jesse James Garrett, the creator of the term AJAX, who held a keynote presentation with all the usual quotes, big stock photos, historical references to technical pioneers (this time the inventor of the Kodak film roll) and such (podcast). I’m afraid I can’t bear victorian black and white photos of technical pioneers in the context of web development any longer. OK, so this guy changed the way photos were made in 1885. Also web applications are a little more convenient now than server roundtrips. But where’s the common element? One made photography easier for the mainstream, the other is a much hyped technique with the potential to make things easier, but quite often people just blow it.

Don’t believe the hype. Most web applications still don’t innovate, they just copy desktop behavior. And who is really comfortable with the restrictions of desktop software anyway? If it’s only a matter of response rates, learn from Yahoo! how to minimize the amount of data being sent on server requests. If I can update a whole page in 1-2 seconds using smart caching and other techniques, there’s no need for an AJAX request except for immediate form feedback helping users to avoid errors. Film rolls have faded from the face of Earth, it really would be more interesting what’s next, after AJAX. Jesse talked about user-centered design, cited Tim O’Reilly with the paradigm to “design from the outside in.” But that only means: after having taken one usability step back, eventually we will move forward. Where to? Jesse failed to deliver that.

A key factor to understand why browsers are such a pain is to remind yourself that they are just a piece of software, said Molly Holzschlag, now working for Microsoft (podcast). In fact very complex software. She compared the pros and cons of different browsers and what we can learn from them: short iteration circles and automated updates from Firefox, a strong brand and user identification from Opera. Otherwise she recommended that if you really need a feature in IE, make yourself heard. Put pressure on Microsoft to get priority. Just telling them you “want” something like multiple background images or WAI ARIA support won’t be enough. Your voice and your friends’ might weight more than that of the W3C, because you are their customers, their userbase.

Mark Boulton’s presentation about typography gained more momentum after a while (podcast). He explained why Verdana is lighter than Arial, and that you should blur your design to identify the optical gray gradient of a page. Then he continued to talk on grids and how to design to a vertical rhythm, a topic well known from print but rather unrecognized in web design until last year. Quite fashionable are headlines in a serif font for a better structure, and paying attention to small details like using the correct quotation marks or dashes can make a difference.

Jon Hicks showed us how to be a creative leech sponge (podcast). Get your inspiration everywhere — with two exceptions. Do sketches, keep those you draw during phone calls, take photos of typefaces, keep photos gone bad just for the color effects, collect labels from clothes, get leaflets (the “all you can eat buffet for designers”; get even the bad as you might need to mimic bad design some day). Get inspiration from book covers, graphic novels, books for children, magazines, patterns, prints, or packaging design. Blogs and flickr groups also help you to get inspiration, delivered right to your desktop through their RSS feed. The two exceptions? Other websites and logos, because there’s a high risk you will come up with a copy instead of an original idea. They are too close to the desired product so there’s no room for creative transformation.

Once you have collected inspirational material, it needs to be cataloged. That can be done in a sketchbook, but iPhoto, Yojimbo, or flickr will do the job.

Catalysts against a creative block (the dreaded blank page) can be deadlines, changing your environment and going for a walk or drive, going to bed, some peace and quietness (in the bathroom, where you keep the magazines for inspiration), taking a shower, or traditional techniques like brainstorming, mindmapping, criticizing and learning from bad examples, or moodboards. If your clients are adventurous enough, they can even do their own.

Some people are angry about Last FM’s sell-out to CBS, but Hannah Donovan didn’t make the impression that a petty-minded corporate spirit has taken over (yet). She talked about lessons you learn in a startup, like getting started, getting out the product very quickly (before others do it), taking small iteration steps with the rapid development technique Scrum, and using broad brushstrokes as a designer. Perfectionism is no priority for startups. Also she recommended that designers and developers work on a team (really) and hold 5 minute stand-up meetings every morning, “that makes a world of difference.” That actually means sharing a room, you know.

Shawn Lawton Henry works for the W3C WAI and the MIT, naturally she talked about accessibility (podcast). That’s something most people take as “what you can get away with,” but it’s really about people. So it’s important to understand how people with disabilities use the web. Technical standards like the Web Content Accessibility Guidelines 2.0 (WCAG) only supply a shared definition of requirements. Because they are not going to change for a while you better take the time to review the current version. However, the WCAG Techniques document will be adaptable and more flexible. There will be subversions, and although there’s no issue tracker at the moment, you will be able to submit additional techniques to meet the WCAG requirements as they are intended to grow with time.

I didn’t take notes on Richard Ishida’s presentation about I18N because I was familiar with the slides already, but I was deeply impressed by this man (podcast). Richard lives and breathes internationalization. He speaks about a dozen languages and doesn’t let a chance pass to practice them. He is the perfect personification as head of W3C I18N activity. I only wish he had said a few things about the I18N tag set because it’s a mighty tool for translations and fairly new.

On a related subject Andy Clarke asked designers worldwide if they thought their country or region got a distinctive design style, and he compared international websites of global players (podcast). While most of them just work, they could do better by adapting to the local customs and style. Culturalization is the key, anything else is modern imperialism. Check his presentation (PDF, 18 MB).

Somehow it was different than last year. Of course I came home full of inspiration, but this time it was more like deepening knowledge, while last year for example the concepts of microformats or browser performance were totally new for me. I met more people than in 2006, and I feel some of them can become my friends. That’s a new experience at a conference. I even found some parallels with Joe Clark. No, I’m not a “sarcastic gay vegan,” but we both don’t drink, prefer tea, and can be quite pedantic… I even linked to his website without rel=nofollow now, what an improvement! Anyway, I’m looking forward to meet some of my new friends in Brighton at d.construct.

• Andy Clarke: Royale With Cheese (PDF, 18 MB); Podcast
• Dan Cederholm: Interface Design Juggling (PDF, 22 MB); Podcast
• Dan Webb: The Mysteries Of JavaScript-Fu; Podcast
• Drew McLellan and Simon Collison: High-Noon Shoot-Out: Design vs. Implementation
• Håkon Wium Lie: One Web, Acid2 and CSS3 (PDF, 3.7 MB); Podcast
• Hannah Donovan and Simon Willison: For Example… Last FM (PDF, 1.8 MB) and Doing Local Right
• Hot Topics Panel: Podcast
• Jason Santa Maria: Diabolical Design: The Devil is in the Details (PDF, 22 MB); Podcast
• Jeremy Keith: Bulletproof Ajax (PDF, 2.1 MB); Podcast
• Jesse James Garrett: Beyond Ajax; Podcast
• Joe Clark: When Web Accessibility Is Not Your Problem; Podcast
• Jon Hicks: How to be a Creative Sponge; Podcast
• Mark Boulton: Five Simple Steps to Better Typography; Podcast
• Molly Holzschlag: The Broken World: Solving the Browser Problem Once and For All; Podcast
• Nate Koechley: High Performance Web Pages; Podcast
• Richard Ishida: Designing for International Users: Practical Tips; Podcast
• Shawn Lawton Henry: Advancing Web Accessibility; Podcast
• Tantek Çelik: Microformats, Building Blocks, and You; Podcast

Update

Thanks for the reminder, of course Joe Clark wrote detailed protocols about some sessions. Also I would like to point you to Chantal Slagmolen’s original notes — I wish all designers were so creative!

First he was giving an update on his workover of WCAG 1.0 under the label of “the WCAG samurai,” something he announced a year ago in his article at A List Apart, To Hell with WCAG 2.0. A few anonymous people he will not disclose finished their collective update, also there were two peer reviews of the final paper without the reviewers knowing about each other. Clark said he hasn’t read the reviews either, so this was kind of a premiere.

Then he talked almost an hour about a couple of things that shouldn’t be your concern (in his opinion) as a web developer:

• Pixel units: per definition, pixels are relative units as required by the specifications. Blind people do not care anyway if text is resizable, zoom readers have their screen magnification software. But he misses the point when he concludes that therefore resizable text is not an accessibility issue because disabled users don’t have trouble with it. Accessibility doesn’t only affect severely disabled persons, it begins with elderly people who need to adjust the font size. And as long as IE6 is around on a considerable number of desktops, it is our problem to enable text resizing. We cannot just shrug our shoulders and put the blame on a certain browser vendor. Although we can get rid of those resize buttons on web pages. That is really a matter of browser vendors and user education. Patrick Lauke proposed to put such an explanation on the default page of newly installed browsers.
• Link text being used out of context: Clark showed an example of a fictitious car sales page with recurring links to the car’s features. Of course the features link of one car is different than the features link of another, but you can clarify that ambiguity through a link title. A list of links on a page is a well known and appreciated feature of screen reader software, why should we cease to support that? But one thing I agree on is using an anchors type attribute to clarify that a linked document is a PDF. Though to my knowledge screen readers don’t make use of that attribute.
• Abbreviations, acronyms, initialisms: We cannot cover all cases, and there are cases like “DVD” or e. coli where there is no written out meaning of an acronym, or an abbreviation that is so common that it is neither needed nor any help to give the full meaning. But I strongly disagree of dropping the whole concept of contextual help for abbreviations with the argument that cognitive disabled users won’t get it anyway.

Clark’s disputable (unfortunately not at the session because of a lack of time) arguments will certainly be addressed on the Royal National Institute of the Blind’s blog, so watch their space for a controversial debate. I will also try to get I got also a shot of a hilarious illustration of Joe Clark that Kristiaan Thivessen drew next to me.