The goal of web performance optimization is to become faster and smaller: research at Yahoo! and Google found that just 10-20% of the perceived loading time is caused by the server. A few years ago we thought performance was exclusively connected to the server. However, 80-90% of the loading time incurs in the frontend. Thus WPO is more efficient targeting the frontend.

Two important weak points are JavaScript files and the sheer number of files: JavaScript loads sequentially and blocks subsequent code until each file is loaded. Hence it shouldn’t be located in the head, but in the foot of a page. Secondly older browsers, in particular Internet Explorer, will only load 2-4 files in parallel. Files queue up and get processed when it’s their turn. Therefore aggregation of files is used for reducing the number of HTTP requests.

Several international companies have conducted research or just tracked the effects of optimization.

Effects of slowness

• Amazon: 100 ms delay caused a 1% drop in revenue.
• Google: 400 ms delay caused a 0.59% decrease in search requests per user (earlier tests list larger numbers).
• Yahoo!: 400 ms delay caused a 5-9% decrease in traffic.
• Bing: 2 seconds delay caused a 4.3% drop in revenue per user.

Effects of speed

• Mozilla made their download page 2.2 seconds faster and was rewarded with an increase of 15.4% in downloads.
• Google Maps reduced the file volume by 30% and observed a 30% increase in map requests.
• Netflix enabled gzip on the server; simply by this single action pages became 13-25% faster and saved 50% of traffic volume!
• Shopzilla succeeded in reducing the loading time from 7 down to 2 seconds, whereby the conversion rate increased by 7-12%, they observed a 25% increase in page requests, they were able to retire 50% of their servers, thus saving energy costs.
• AOL observed the number of page views on several websites. While the fastest users requested 7-8 pages, the slowest only viewed 3-4.

As a cream topping Google recently announced to factor in the site speed as a parameter in web search ranking.

Eventually pages become faster, clients are happy, generate more revenue and page views, while power consumption and CO₂ emissions decrease. Saved the world, again! And if you’d like to contribute, start by checking the rules at Yahoo! A few tricks beyond that can be found in the presentation which will be translated soon.

I started my conference program with a case study by the BBC. They did a redesign and managed to squeeze formerly 60 images into 3 sliding doors and sprites. Their home page is now under 300K and 30 HTTP requests. Nice to see Yahoo’s Exceptional Performance guidelines go mainstream. About 5% of their users access the site without JavaScript. They don’t get identical features, but they get identical care. For them accessibility isn’t a buzzword, it’s become a natural part of their daily work. So they were able to find out that blur() is not a friend with JAWS. Also the BBC plays well with the other kids: they joined the OpenID foundation, and with BBC backstage they open their content through an API. Another charming idea is their public beta where people can testdrive new features. About 60% have personalized their home page, although one of the speakers described the personalization features with “my mom’s head exploded.” They used agile development with 2 week sprints, run the website in 12 languages, but don’t have a CDN yet because of the license fees.

Another case study about the LOHAS community Edenbee wasn’t that exiting, mostly because I knew the platform since beta and didn’t get quite why I should speak with other people about changing their lightbulbs. But it’s nice to keep track of your carbon footprint, a feature that uses the AMEE open API.

I was curious about HTML 5, so I went to the presentation of Lachlan Hunt and James Graham. Still I don’t see any advantage of having a bunch of new elements that are incompatible with older browsers when I can achieve the same with ARIA attributes. But I understand the rationale behind some of their decisions, although that doesn’t mean I come to the same conclusions.

For example people use a lot of “nav” and “menu” classes. To make their live easier, the WHATWG came up with the idea to create a nav element. A block level element, so you wouldn’t have to use those <div class="nav"> any more. But every time I use something like class="navigation" it will be an unordered list! I don’t need another div, I’m perfectly happy with my ul and role="navigation". It’s truly backward compatible, it’s semantic, I can use it today, and there isn’t a steep learning curve.

Then I went to two design talks by Andy Clarke and Dan Rubin, and though their designs were beautiful, the code examples were not. Imagine the flexibility of a newspaper article and compare that with the inflexibility of absolutely positioned paragraphs with fixed heights. Exactly. Apart from that Andy’s main inspiration came from comic books. It never hurts to throw in some colorful images.

Like in comic books, usability is not about getting from A to B, it’s about the experience of getting from A to B. In comic books the size of a panel and the amount of text strongly influences the reading speed. So you can emphasize content and add dynamics in your web design. That doesn’t mean necessarily that everything has to be in boxes. Emphasis can also be added by removing the boxes.

Dan Rubin used a lot of effects on his designs, like a noise filter to add texture on monochrome surfaces. Nice idea, though that implies the designer explaining the rationale of such a feature to the front-end engineers. They would either ignore it because they overlooked the subtle texture or because they assumed it would be just noise. Some less intrusive hint I will readily adopt was using a letter-spacing of −1 on headlines to prevent tiny rivers between letters.

What slightly worries me is that Dan talked about re-using patterns for some effects in Photoshop. Re-using patterns is the same in CSS, but re-usable effects in Photoshop can mean an unusable amount of work in CSS and lots of pictures making the website slow. What I miss so far is a common understanding of effects and patterns that are both easy to work with in Photoshop and in frontend programming.

The next day started with Nate Koechley’s keynote about professional frontend engineering. He chose the topic because he thinks this is critical to the advancement of the Internet, and I couldn’t agree more. As Frontend Engineers we write software with XHTML, CSS, JavaScript, and quite some amount of PHP. Douglas Crockford calls this “the most hostile software development environment imaginable,” and if you take a look at this graphic from Nate’s slides you will understand why. There are a number of knowledge areas that can be applied in a number of ways on three operating systems and half a dozen browsers in two rendering modes. If you ever wondered why you sometimes see little clouds of smoke coming out of your frontend engineering heads, that’s why.

There are four guiding principles:

1. Availability and accessibility for all users worldwide
2. Openness: share, learn, support, advocate
3. Richness: provide, but not too much
4. Stability

Then there are three core techniques: Graded Browser Support, Progressive Enhancement, and Unobtrusive JavaScript.If you haven’t heard about those concepts, please read about them now.

At that point the presentation turned into giving advice for quite a number of best practices and tips, like using JSLint, YUI Unit Testing, or YUI Profiler to enhance the quality of your code. Or serving cacheable assets from cookie-free domains. Or anticipated preloads: sneak in your new JavaScript and CSS files a week before the relaunch. Or did you know that the iPhone 2G can keep only 19 assets in cache, and that it doesn’t cache anything larger than 25K? Uncompressed 25K? Needless to say, Nate’s presentation was one of the conference highlights.

Later I heard a few things about building applications with existing frameworks and APIs, a timely comparison between JavaScript libraries held by no other than jQuery’s John Resig, some tips on internationalization by Richard Ishida, and a panel about accessibility. The one sentence that stuck most in that panel was: “Don’t be the guy with the problems, be the guy with the solutions.” In fact it’s very hard to be passionate about your job while being pragmatic and providing solutions instead of just saying “no.” Something Richard Schwerdtfeger wrote about in a different context:

Working in the accessibility field is extremely difficult. It requires very specialized skills — including incredible persistence. Accessibility is often viewed as additional work that is not always planned for. It requires a person who is tough, committed, patient, and caring to deliver an accessible solution that is usable to our customers. To do this you must have tremendous passion for your job as there is always someone or something to trip you up.

Combining passion and diplomacy is a goal many web evangelists still have to work on… In the meantime remember that accessibility is most likely to have a sustainable impact when it is supported by senior management, when there is an accessibility policy for a company, and when smart companies realize that there is money to be made by maximizing the target audience.

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.

Parsing JavaScript freezes the browser. Therefore put CSS in the head and JavaScript near to the </body> so that it is parsed when the page has been rendered.

The arch enemy of performance are HTTP requests. Many browsers still can’t handle more than two or four requests at a time. Keep the number of files down, your website will be faster.

There are several techniques with the aim to reduce the number of files:

1. “A single large file is fastest.” (Nate Koechley) That’s why Yahoo! apparently has such an amount of inline CSS. They found out browser caching is not as effective as they thought, in particular not on a user’s start page. So they deliver “inline” CSS. Actually writing inline CSS is a maintenance nightmare, but delivering CSS content inline doesn’t mean the files can’t have separate lives on the server: concatenate the files with a server side technique of your choice.

   Update: A couple of months later Nate explained that further: when your page is likely to be a user’s start page, caching plays a minor role, thus “inline” CSS is faster. Otherwise use external files, aggregate them, and make sure they are cached (see below).

2. Enforce caching. Another IE bug prevents image caching. Add the following to your .htaccess, httpd.conf or vhost.conf settings:

   1. <IfModule mod_expires.c>
   2. ExpiresActive On
   3. ExpiresByType image/jpg "access plus 1 day"
   4. ExpiresByType image/jpeg "access plus 1 day"
   5. ExpiresByType image/gif "access plus 1 day"
   6. ExpiresByType image/png "access plus 1 day"
   7. </IfModule>

3. Reduce the number of background images with techniques like CSS Sprites or Sliding Doors. Instead of four images of rounded corners you only need one and get the mouseover state for free! The green download button on mozilla.com is based on that technique. And Yahoo! uses CSS Sprites to combine a huge number of icons.

   

   Please note this approach is only for decorational background images that degrade gracefully. It’s not for img elements. Be careful when you use it for foreground images. And if text comes as a graphical representation, it can become inaccessible for screen reader users, zoom readers, or people with stylesheets switched off. Use real text instead.

   Also note changing the background-position causes IE6 to flicker, related to the caching bug above. To avoid it, simply add the following:

   1. <script type="text/javascript">
   2. try { document.execCommand( "BackgroundImageCache", false, true); } catch(e) {};
   3. </script>

4. Aggregate files. Ed Eliot wrote a nice script to merge JavaScript or CSS files, bonus respect for the advanced versioning and caching features.

   But remember the cases when it doesn’t make sense to merge CSS files: your IE bugfixes still belong in conditional comments. If you use the @import rule to filter antique browsers from getting advanced styles, you can’t drop it. And if you want to merge stylesheets for different media (e.g. print), make sure the code is enclosed in something like

   1. @media print {
   2. /* style sheet for print goes here */
   3. }

   In an updated version Ed added JSMin to strip comments and excess whitespace. JSMin works like a charm for JavaScript files. But it cuts a few space characters too much so that the syntax of CSS selectors changes therefore for now I have abandoned the idea to compress them too. See Jens Meiert’s comment below for a recommendation to minimize CSS.

   His original code requires the C version of JSMin with PHP safe_mode turned off. If you prefer a pure PHP version, get the PHP version of JSMin and my adapted version of the script.

I’m still in awe how fast one of my own websites became! Thanks to the guys at Yahoo! for the inspiration and for most of the research this article is based upon. Even JSMin was written by an employee of Yahoo! Speaking about Yahoo! employees: Chris, I hope there are still enough topics for your Vitamin article. I wanted to write about performance anyway, and to my surprise I read yesterday that you have similar plans. See ya in Paris.