Yahoo! User Interface Blog

Screencast: Ross Harmes’s YUI Bundle for Textmate

Continue reading Screencast: Ross Harmes’s YUI Bundle for Textmate…

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests

It’s no secret that users prefer faster web sites. I work in a dedicated team focused on quantifying and improving the performance of Yahoo! products worldwide. As part of our work, we conduct experiments related to web page performance. We are sharing our findings so that other front-end engineers join us in accelerating the user experience on the web.

The 80/20 Performance Rule

Vilfredo Pareto, an economist in the early 1900s, made a famous observation where 80% of the nation’s wealth belonged to 20% of the population. This was later generalized into what’s commonly referred to as the Pareto principle (also known as the 80-20 rule), which states for any phenomenon, 80% of the consequences come from 20% of the causes. We see this phenomenon in software engineering where 80% of the time is spent in only 20% of the code. When we optimize our applications, we know to focus on that 20% of the code. This same technique should also be applied when optimizing web pages. Most performance optimization today are made on the parts that generate the HTML document (apache, C++, databases, etc.), but those parts only contribute to about 20% of the user’s response time. It’s better to focus on optimizing the parts that contribute to the other 80%.

Using a packet sniffer, we discover what takes place in that other 80%. Figure 1 is a graphical view of where the time is spent loading http://www.yahoo.com with an empty cache. Each bar represents a specific component and is shown in the order started by the browser. The first bar is the time spent for the browser to retrieve just the HTML document. Notice only 10% of the time is spent here for the browser to request the HTML page, and for apache to stitch together the HTML and return the response back to the browser. The other 90% of the time is spent fetching other components in the page including images, scripts and stylesheets.

Table 1 shows popular web sites spending between 5% and 38% of the time downloading the HTML document. The other 62% to 95% of the time is spent making HTTP requests to fetch all the components in that HTML document (i.e. images, scripts, and stylesheets). The impact of having many components in the page is exacerbated by the fact that browsers download only two or four components in parallel per hostname, depending on the HTTP version of the response and the user’s browser. Our experience shows that reducing the number of HTTP requests has the biggest impact on reducing response time and is often the easiest performance improvement to make.

Shouldn’t everything be saved in the browser’s cache anyway?

The conclusion is the same: Reducing the number of HTTP requests has the biggest impact on reducing response time and is often the easiest performance improvement to make. In the next article we’ll look at the impact of caching, and some surprising real-world findings.

Disclaimer: Design imperatives dictating visual richness need to be weighed against this request-reduction goal. When you need visual richness, additional steps can be taken — aggregating JS files, using CSS sprites, etc. — but visual richness does tend to run counter to a slender HTTP request pipeline.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Video: Douglas Crockford, “Advanced JavaScript”

Last month, I posted some video taken from one of Douglas Crockford’s presentations on frontend engineering (Video: Douglas Crockford, “An Inconvenient API: The Theory of the Dom”). Those who enjoyed Douglas’s deep-dive into the DOM may be interested also in his “Advanced JavaScript” presentation, now publicly available on Yahoo! Video. In this presentation — the third of a three-part series he has been teaching at Yahoo! — Douglas looks closely at code patterns from which JavaScript programmers can choose in authoring their applications. He compares familiar constructs like the Pseudoclassical Pattern with more unique patterns like the Parasitic Pattern that (he argues) run more “with the grain” of JavaScript. When Brendan Eich spoke at Yahoo this summer he described Douglas as “Yoda of lambda programming and JavaScript”; after watching “Advanced JavaScript,” you may have a clear sense of where that sentiment comes from.

It bears repeating that Douglas’s ideas and perspectives are his own and that the many flaws in videographic craftsmanship are mine.

• Part 1: 31 minutes
• Part 2: 25 minutes
• Part 3: 11 minutes
• Download slides (zipped PowerPoint file)
• Note: This video is also available in a downloadable, iPod-compatible format from the YUI Theater.

You can check out Part One below:

More Video

The YUI Theater section of the YUI Website contains links to videos from Firebug author Joe Hewitt, Oddpost cofounder Iain Lamb, YUI engineer Matt Sweeney, and much more.

A Note About Video Formats

This video is also available in a downloadable, iPod-compatible format from the YUI Theater.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Graded Browser Support: Q4 Update

Approximately every three months we update the chart detailing which browsers receive A-grade support according to Graded Browser Support. In conjunction with yesterday’s YUI update release, here is our browser support update for Q4 2006.

In summary: A-grade support begins for Firefox 2.0, and is reiterated for IE7. A-grade support is discontinued for IE 5.5 and Firefox 1.0. Seldom-used Gecko derivatives (e.g., Netscape and Mozilla Application Suite) now receive X-grade instead of A-grade support. Opera 9 now receives A-grade support on additional platforms.

In bullet form, here are all the changes in this update:

1. Reiteration of A-grade support, IE 7, Win(XP)
2. Termination of A-grade Support, IE5.5, Win
3. Initiation of A-grade Support, Firefox 2.x, Win/Mac.
4. Termination of A-grade Support, Firefox 1.0.x, Win/Mac.
5. Expansion of A-grade support, Opera 9.x, Win/Mac
6. Termination of A-grade support, Mozilla App Suite, Win/Mac
7. Termination of A-grade support, Netscape, Win/Mac

Though you should always reference the official GBS chart hosted on the Yahoo! Developer Network, I’ve included a snapshot of this quarter’s chart for posterity’s sake:

Looking ahead to next quarter (2007Q1), we will reflect incremental releases of supported browsers but no major changes are anticipated.

Thanks,
Nate

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI version 0.12.0: TabView Control, Improved API Documentation, and More

Today we released version 0.12 of the YUI Library. Here are the highlights:

• The TabView Control: Written by YUI Animation and Dom author Matt Sweeney, this dynamic tab solution is the newest YUI addition and features robust support both for progressive enhancement and for high-gloss richness. Check out Matt’s roster of TabView examples for an idea of what the new control can do; view source on the examples to see how they’re implemented.
• Improved Documentation: YUI developer Adam Moore (Event, Drag & Drop, Slider, TreeView) has created a new tool for generating API documentation, allowing us to generate unified, crosslinked API docs with an integral AutoComplete-powered search control. The new API documents provide developers with a clearer picture of class structures and provide separate categorization for properties and configuration options. You may never go back to Cheat Sheets again…
• …But in Case You Still Like Cheat Sheets: Cheat Sheets are updated for version 0.12 and include new sheets for TabView and for Nate Koechley’s CSS Reset, Fonts and Grids foundation. You can download all the YUI Cheat Sheets from the YUI Library website.
• Speaking of CSS Grids: Nate has rev’d the Grids package with baked-in support for 750px, 950px, and full-viewport ("liquid") layouts. Grids 0.12 triples the number of supported layouts and still weights in under 3KB before gzipping. We’ve built the YUI website on the Reset/Fonts/Grids foundation now and we’re making use use of the new full-viewport support.
• Improvements Throughout the Library: There are enhancements to be found throughout the library, from Event’s new onContentReady method to a significantly improved Calendar Control with a simplified interface for creating multi-month calendar displays (if you’re upgrading from a previous version of Calendar, check out the step-by-step upgrade guide). For a full list of changes, see the release notes documentation that accompanies the distribution.

We’ll follow up with more information on some of these topics later in the week. For now, please make your way to SourceForge to download the latest YUI distribution; see the release notes in the distribution for a full manifest of changes throughout the library. As always, the YUI site on the Yahoo! Developer Network has all the latest documentation.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

JavaScript, We Hardly new Ya

JavaScript is a prototypal language, but it has a new operator that tries to make it look sort of like a classical language. That tends to confuse programmers, leading to some problematic programming patterns.

You never need to use new Object() in JavaScript. Use the object literal {} instead. Similarly, don’t use new Array(), use the array literal [] instead. Arrays in JavaScript work nothing like the arrays in Java, and use of the Java-like syntax will confuse you.

Do not use new Number, new String, or new Boolean. These forms produce unnecessary object wrappers. Just use simple literals instead.

Do not use new Function to create function values. Use function expressions instead. For example,

frames[0].onfocus = new Function("document.bgColor='antiquewhite'")

is better written as

frames[0].onfocus = function () {document.bgColor = 'antiquewhite';};

The second form allows the compiler to see the function body sooner, so any errors in it will be detected sooner. Sometimes new Function is used by people who do not understand how inner functions work.

selObj.onchange = new Function("dynamicOptionListObjects["+
        dol.index+"].change(this)"); 

If we keep function bodies in strings, the compiler can’t see them. If we keep function bodies as string expressions, we can’t see them either. It is better to not program in ignorance. By making a function that returns a function, we can explicitly pass in the values we want to bind. This allows us to initialize a set of selObj in a loop.

selObj.onchange = function (i) {
    return function () {
        dynamicOptionListObjects[i].change(this);

    };
}(dol.index);

It is never a good idea to put new directly in front of function. For example, new function provides no advantage in constructing new objects.

myObj = new function () {
    this.type = 'core';
};

It is better to use an object literal. It is smaller, faster.

myObj = {
    type: 'core'
};

If we are making an object containing methods that are bound to private variables and functions, it is still better to leave off the new prefix.

var foo = new function() {
    function processMessages(message) {
        alert("Message: " + message.content);
    }
    this.init = function() {
        subscribe("/mytopic", this, processMessages);
    }
}

By using new to invoke the function, the object holds onto a worthless prototype object. That wastes memory with no offsetting advantage. If we do not use the new, we don’t keep the wasted prototype object in the chain. So instead we will invoke the factory function the right way, using ().

var foo = function () {
    function processMessages(message) {
        alert("Message: " + message.content);
    }
    return {
        init: function () {
            subscribe("/mytopic", this, processMessages);
        }
    };
}();

So the rule is simple: The only time we should use the new operator is to invoke a pseudoclassical Constructor function. When calling a Constructor function, the use of new is mandatory.

There is a time to new, and a time to not.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!