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.

The main idea is to present leading innovators and their perspectives on eAccessibility from the technical, political, and economic side. Experts on seven panels will briefly describe their own work and their view of accessibility and then discuss the issues.

There’s an illustrious line-up of speakers including Deutsche Bahn, the European Commission, France Télécom, the German Federal Ministry of Labour and Social Affairs, Google, IBM, Microsoft, Mozilla, Opera, the W3C, the Web Standards Project, and Yahoo! talking about these topics:

• Accessible Web Applications
• Mobile Access — Device-independent or Accessible?
• Comparison of National Accessibility Guidelines
• Accessible Rich Internet Applications (ARIA)
• Web Standards and Accessibility in Higher Education
• Harmonising European Accessibility Guidelines
• The Business Value of Accessibility

If you have been following my posts in the last two years this will sound slightly familiar. Furthermore I’m honored to have Linda Mauperon, Member of Cabinet of the European Commissioner for Information Society and Media (Viviane Reding) as our keynote speaker. Please see the detailed description of the panels in the conference program.

We would like to take a look on accessibility from different perspectives presenting pioneering thinkers whose organizations have established accessibility in their business and communication long since — and making serious money with it. There should be something of interest for everybody among the topics: for techies, consultants, employees from universities and companies. The conference is limited to a maximum of 200 attendees. Registration opens next week.

Of course there are various gems under the hood of the website, too. Naturally it is extensively accessible (check the cool skip links), but it is also incredibly fast because Yahoo!’s best practices for frontend performance are regarded. There are separate style sheets for printing, for iPhones, and for handhelds. The CMS is WordPress µ, having the advantage of administrating both the English and the German version with the same installation.

Other conferences

The next geek meeting held in Frankfurt will be the Webmontag (Web Monday) on September 1st where I will give my presentation about canvas a short test drive.

A few days later on September 4 I have the honor of the opening talk at the Web Congress at the University of Erlangen, again about canvas, only this time a full hour.

On September 25 there’s the Best of Accessibility Symposium in Düsseldorf where I hold a workshop about hands-on ARIA (you recognize the pattern?).

On October 10-11 an internal namics conference called T-Camp is held in Basel, with my colleague Alex Stirn and me speaking about Professional Frontend Engineering.

A conference I’m looking forward to because of the many experts attending and the fair prices is the A-Tag (Accessibility Day) in Vienna, Austria, on November 21. Again I will sing praises of ARIA. This innovative technique can’t be evangelized enough! There’s no website yet for the A-Tag, but I’d recommend to book your journey well in advance to catch the inexpensive flights to Vienna. The conference itself cost only € 35 last year is free because it is sponsored by the Austrian government.

If you happen to be around, don’t hesitate to speak to me.

But if your blog or a client has a loyal readership, it would be convenient if they could just use their browser’s searchbar as a shortcut. For example currently we work on a website relaunch for a big German city, and it’s easily conceivable that citizens want to search this site more often.

Here comes a side effect of OpenSearch: the OpenSearch descriptions are machine readable XML files. Firefox and Internet Explorer 7 are two of those “machines” if you let them know the file exists:

1. <link rel="search" type="application/ opensearchdescription+xml" title="Your website’s title" href="/opensearch.xml" />

Of course that belongs in the head. Now all you need are a few more lines of code in the opensearch.xml file:

1. <?xml version="1.0" encoding="utf-8"?>
2. <OpenSearchDescription xmlns="http://a9.com/-/spec/ opensearch/1.1/">
3. <ShortName>Your website’s title</ShortName>
4. <Description>A short description of the search</Description>
5. <InputEncoding>UTF-8</InputEncoding>
6. <Image height="16" width="16" type="image/x-icon"> http://yourdomain.com/favicon.ico</Image>
7. <Url type="text/html" template="http://yourdomain.com/ search/ ?q={searchTerms}"/>
8. </OpenSearchDescription>

Just change the shortname property, the favorite icon path, the search URI and parameters. Don’t change {searchTerms}. And that’s all, it’s a five minute no-brainer…

Further Reading

• OpenSearch documentation (Mozilla Developer Center)
• JSON type-ahead suggestion functionality for OpenSearch

Update: Internet Explorer 8 now supports type ahead suggestions, too.

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.