Douglas Crockford returns to YUI Theater with another chapter in his evolving lecture series. This session, “Ajax Performance,” debunks common misconceptions about the relationship between JavaScript and performance and gives engineers a core focus for improving the performance of web apps: Reduce the value of n. Because DOM interactions are generally slow, leveraging Ajax to reduce the number of DOM operations, Douglas argues, is often the most important optmization you can make. In fact, it usually dwarfs other techniques in terms of its impact on the actual experience of using a website.

This talk joins an extensive library of Douglas’s lectures now available on YUI Theater, including his popular series on JavaScript.

• Slides (zipped PPT)
• Full text transcript of this talk

Douglas Crockford: "Ajax Performance" @ Yahoo! Video

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• Nicole Sullivan: "Design Fast Websites (Don’t Blame the Rounded Corners)" (Yahoo! Video | .m4v download)
• Todd Kloots: “Developing Accessible Widgets Using ARIA” (Yahoo! Video | .m4v download)
• Nicholas C. Zakas: "Test-Driven Development with YUI Test" (Yahoo! Video | .m4v download)
• Douglas Crockford: "Web Forward" (Yahoo! Video | .m4v download)

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

Nicole Sullivan is a website performance specialist and a former member of Yahoo’s Exceptional Performance Team. She is currently writing a book for O’Reilly with Stoyan Stefanov on performance optimization and she and Stoyan are the creators of Smushit, an engine for crushing images.

Nicole visited Yahoo last week to do an encore of her "Design Fast Websites" talk in which she outlines a set of practical guidelines for building websites that are supremely fast and visually rich. Her advice is to know your craft, to engage your designers, and to make sure that your collaboration with designers works intelligently in the service of users. She was kind enough to let us record the talk and share it with you here on YUI Theater.

• Slides (on Slideshare)

Nicole Sullivan: "Design Fast Websites" @ Yahoo! Video

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• Todd Kloots: “Developing Accessible Widgets Using ARIA” (Yahoo! Video | .m4v download)
• Nicholas C. Zakas: "Test-Driven Development with YUI Test" (Yahoo! Video | .m4v download)
• Douglas Crockford: "Web Forward" (Yahoo! Video | .m4v download)
• Eric Miraglia and Matt Sweeney: "YUI3 — A Look Ahead" (Yahoo! Video | .m4v download)

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

This is part 5 in an ongoing series. You can read the other parts here:

• Image Optimization Part 1: The Importance of Images
• Image Optimization Part 2: Selecting the Right File Format
• Image Optimization Part 3: Four Steps to File Size Reduction
• Image Optimization Part 4: Progressive JPEG…Hot or Not?

This installment of the image optimization series is about the IE-proprietary AlphaImageLoader CSS filter, which developers often use as a workaround to solve transparency issues with truecolor PNGs in IE. The problem with AlphaImageLoader is that it hurts page performance and, therefore, hurts user experience. I argue that AlphaImageLoader should be avoided when at all possible.

Quick Refresher

As mentioned in a previous article, PNGs come in several different types but can roughly be divided into:

• Indexed (palette), also referred to as PNG8 which have up to 256 colors.
• Truecolor PNG, also referred to as PNG32 or PNG24.

Both formats support alpha (variable) transparency and, while PNG8 images degrade to a GIF-like non-variable transparency in IE6 (example, source), truecolor PNGs show an uglyish background in place of the transparent pixels (source W3C).

The AlphaImageLoader fix

IE6 (and older versions of IE) provides a solution to the problem through its proprietary filter CSS property. The following code will display the proper image cross-browser:

#some-element {
    background: url(image.png);
    _background: none;
    _filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='image.png', sizingMethod='crop');
}

As you can see, the underscore CSS hack is used to target IE < 7 and

1. “undo” the background; and
2. load the same image, using Microsoft’s AlphaImageLoader filter.

The reason to target IE prior to version 7 is that IE7 supports the alpha transparency natively without the need for filters. (IE8 does too and it actually changes the filter syntax completely.)

It’s interesting to note that the filter doesn’t change the image; rather, it changes the HTML element this style is applied to. The other interesting thing is that each element is processed synchronously in a single UI thread. The process applying the filter takes some resources for each element and the more “filtered” elements you have, the worse it gets, even if you use the same image for all the elements.

The question is: How does this affect the overall performance of the page?

Freeze! Side Effect #1

Here’s a simple experiment: Create a page that has a CSS filter and then simulate (and exaggerate) network latency by delaying the image used in the filter by ten seconds. The result? Not only is nothing rendered (blank page) for ten seconds, but the browser freezes, meaning you cannot interact with it, click its icons or menus, type in the URL…you can’t even close it.

Here’s a test example.

In the example, I didn’t use the underscore hack so you can see the (d)effect in IE7 too, even in IE8 in “compatibility mode”.

While the effect is exaggerated for demo purposes, network latencies are a fact of life and this is probably the worst user experience you can deliver: Someone comes to your page and their browser freezes.

Note that parallel downloads are not blocked. The browser still downloads the other page components in the background, but there’s no progressive rendering. You can think of it this way — since IE will not render anything until the very last bit of CSS comes down the wire (more info), and your because CSS has a dependency on a filtered image, the rendering is blocked until the dependency is satisfied.

What if you have several AlphaImageLoader filters on the page? They are processed synchronously one after the other so the problem is multiplied. If you have 5 images, each delayed 2 seconds on the server, then the browser freezes for a total of 10 seconds.

Time and Memory — Side Effects #2 and #3

Another negative effect of using the AlphaImageLoader is the increase of the amount of memory required to process and apply the filters. These days we might be tempted to think our visitors’ computers have a virtually indefinite supply of memory, but for older computers (those more likely to run IE6 and under) this may not be the case.

And at the end of it, it’s the performance we’re most interested in, performance as measured by the time it takes for the page to load in the browser. Let’s do a test to measure how much time and memory is required by the filters.

First, let’s have a baseline page — one that has a hundred <div>s with the same non-filtered background image. Then let’s have a second page with a filter applied to the divs (all 100 divs use the same). A hundred elements with filtered backgrounds is unlikely to be found in a normal page, but a little exaggeration will help with the measurements.

The time is measured from the start of the page to the onload event of the page, after the images have been cached, thus eliminating the time required to download the page and the images. The memory consumption is measured with the help of the ProcessExplorer tool and given as the before/after delta of the private bytes measurement, showing the “price” of rendering the page.

Here are the median results from 10 runs in IE6 on a PC with a dual 2GHz CPU and 500M RAM. On a less powerful computer, the load times are likely to be even worse.

As you can see, the AlphaImageLoader effect is pretty bad — our test page loads 27 times slower and eats up 78 times more memory. These results are, of course, highly speculative — it’s just one image tested on just one PC (relatively powerful and underworked). With different images, applied to a different number of elements and on different machines, results may vary considerably, especially when there’s less RAM or CPU, or if you throw network latency (side effect #1) into the mix. But this example illustrates the important concepts:

• AlphaImageLoader is slow and requires more memory
• It’s applied per element, not per image

If you have a sprite image and you use it for different elements (sprites with alpha filters are trickier, but doable), you’ll pay the penalty for each element the sprite is used on.

Yahoo! Search Case Study

Using lab tests like the one above can give us some idea of the AlphaImageLoader “price,” and you might be tempted to test and calculate approximately how much you pay for each filtered element, but there’s nothing better than a real life test with millions of requests coming form different parts of the world with different browsers, computers and bandwidth.

Yahoo!’s search results page used to have a truecolor PNG sprite and employed AlphaImageLoader to achieve the transparency (an older version of the sprite is still around if you’re curious). Replacing the truecolor PNG with a gracefully degrading PNG8 (discussed previously) decreased the pageload time by 50-100ms for the users of IE 5 and 6. 100ms may not seem like much, but for a page that loads under a second, it’s at least 10%. Also, according to an Amazon study, 100ms slower means 1% fewer sales (even for their content-heavy pages). Earning 1% more by just replacing an image doesn’t look like a bad deal at all.

So Now What?

The best thing would be to avoid AlphaImageLoader completely and, like Y!Search, take the time to create PNG8 images that degrade nicely in IE6 and look good in all other browsers. How do you create a gracefully degrading PNG8? Well, create a GIF-like image first, one that has only fully transparent or fully opaque pixels. After making sure it looks acceptable (it will look like this in IE6), proceed to enhancing the image with semi-transparent pixels which will smooth any rounded corners or other parts that would benefit from transparency. Unfortunately, as far as I know, Fireworks is currently the only image processing software capable of handling alpha transparency in PNG8. You can also try command line tools such as pngnq and pngquant, although automated truecolor-to-palette PNG conversion might not always yield satisfactory results and you might need to pick the fully opaque pixels manually.

There might be cases when you won’t be able to get by with a PNG8 and absolutely need to use AlphaImageLoader — for example when most or all pixels are semi-transparent (imagine a “play” button over a video thumbnail). Dave Artz of AOL has some other cases where PNG8 will not be good enough. In such cases (but only after you try your best to persuade the designer to reconsider the use of transparency), make sure you use the underscore hack (_filter) so that you don’t penalize IE7 users.

Sometimes instead of PNG8 people use GIF for IE6 and truecolor PNG for the others, but that’s not necessary; with one PNG8 you achieve both binary and alpha transparency.

Additional benefits from using a PNG8 are:

1. PNG8 is usually smaller than truecolor PNG,
2. only one image to maintain for all browsers
3. cleaner CSS with no hacks, branches or proprietary tags
4. ability to repeat background

Transparency with VML

Using VML is yet another option in IE to make a truecolor PNG transparent, and it solves several problems: alpha transparency, performance, and background repeat. Unfortunatelly, it comes with the price of extra non-standard markup (or dependency on JavaScript to generate it if you want your initial markup clean) and more propritary CSS. Here’s an example on how to implement it.

If, for example, you have an empty div, you need to wrap it in one VML :rect (or :shape) and one :fill element, like this:

<v:rect>
  <v:fill type="tile" src="alphatest.png">
    <div>&nbsp;</div>
  </v:fill>
</v:rect>

Somewhere in the markup before that you also need to declare a VML namespace:

<xml:namespace ns="urn:schemas-microsoft-com:vml" prefix="v" />

And in your stylesheet you need:

v\:rect  {
    behavior:url(#default#VML);
    width: 100px;
    height: 100px;
    display: block;
}

v\:fill  {
    behavior:url(#default#VML);
}

A test page with 100 VML rect elements loads in 0.094 seconds (almost 10 times faster than using filters) and the memory usage is under 4Mb (10 times less than the filtered page).

As you can see this solution adds more markup and proprietary CSS, but it’s still a solution and doesn’t have the penalties of the AlphaImageLoader.

(Thanks go to this post by Drew Diller and also HTML Remix, who accidentally found this side effect while working on another problem — rounded corners with VML, via snook.ca)

P.S. …and What about Other Filters

AlphaImageLoader is not the only filter that exists. Another popular one is the opacity filter.

For example, for 50% element opacity developers use the properties:

• opacity: 0.5 (standard),
• -moz-opacity: 0.5 (early Mozilla versions, before Firefox 0.9), and
• for IE, filter: alpha(opacity=50).

A quick test in IE6 shows that the opacity filter is not nearly as slow as the AlphaImageLoader, but it’s still making the page slower and takes the same amount of memory. This test uses color background, not an image, but even with an image the results are pretty much the same.

This is part 3 in an ongoing series. You can read the other parts here:

• Image Optimization Part 1: The Importance of Images
• Image Optimization Part 2: Selecting the Right File Format
• Image Optimization Part 4: Progressive JPEG…Hot or Not?

This post is about some common tools you can use to reduce the file size of your images. The idea is to be able to just take the images your designer has created and instead of using them “as is”, go ahead and tidy them up in short time and no effort, without even looking at them.

The good news is that this process is:

• lossless – you strip bytes, hence you lose some information, but not the pixel data and the resulting image looks exactly the same as the source with no quality loss
• uses free tools – all the tools we mention here are free and open-source, and work on both Windows and Unix
• automated – since these are command line tools, they are easy to script and automate; one example of such automation is the smush.it tool

Step 1: Crush PNG

PNGs store information in so-called “chunks” and not all of those chunks are required for the display of the image. In fact most of them are not. You can safely use a tool such as pngcrush and strip all the unneeded chunks. For example:

> pngcrush -rem alla -brute -reduce src.png dest.png

Let’s take a look at the options of this command:

• src.png is the source image, dest.png is the destination (result) image
• -rem alla means remove all chunks but keeps the one for transparency
• -reduce tries to reduce the number of colors in the palette if this is possible
• -brute tries over a hundred different methods for optimization in addition to the default 10. It’s slower and most of the times doesn’t improve much. But if you’re doing this process “offline”, one or two more seconds are not important since there’s a chance if a filesize win. Remove this option in performance-sensitive scenarios.

Running this command on the PNGs found on Alexa’s top 10 sites gives us an average file size reduction of 16.05%. This means you can easily strip weight off your PNG images, save bandwidth and disk space and improve load times, without sacrificing quality and without even touching a single line of application code.

PNGcrush is only one of the available tools for this sort of optimizations. Other tools you can take a look at include:

• pngrewrite
• OptiPNG
• PNGOut

Now that we’ve got a pretty good PNG solution, let’s see if we can do the same for the other image types.

Step 2: Strip JPG Metadata

JPEGs files contain meta data such as:

• comments
• application-specific (think Photoshop) meta data
• EXIF information such as camera information, date the photo was taken and even thumbnails of the actual image or audio!

This meta data is not required for the display of the image and can safely be stripped with no pixel quality loss. As discussed previously, JPEG is a lossy format, which means you lose quality every time you save. But luckily there are some operations that are lossless. Such operations include cropping a part of the image, rotation and the personal favorite – copying metadata. One tool that allows you to do these is called jpegtran.

Here’s a command to copy the source image, optimize it and don’t carry over any metadata in the new copy:

> jpegtran -copy none -optimize src.jpg dest.jpg

Note that depending on the version you have, you might need to use the syntax ending with src.jpg > dest.jpg

The -optimize option will cause jpegtran to optimize the Huffman tables and improve compression.

Running this command on Alexa top 10 sites resulted in average savings of 11.85%.

You may be able to further improve image size by using jpegtran’s -progressive option. It produces JPEGs that load progressively in the browser, starting from a lower quality version of the image and improving as new image information arrives.

Important note on stripping meta information: do it only for images that you own, because when jpegtan strips all the meta, it also strips any copyright information contained in the image file.

Step 3: GIF to PNG

What’s the best way to improve a GIF? Convert it to a PNG. As funny as it may sound, it’s true. Most of the time you get a smaller file size from a PNG and the same quality and browser support, as we discussed in a previous article. Note that PNG will not always be smaller, but most of the time it will be, so it’s worth checking after the conversion and keeping the smaller of the two files.

In order to automatically change your GIFs, you can use ImageMagick’s convert:

> convert image.gif image.png

If you want to force PNG8 format you can use:

> convert image.gif PNG8:image.png

This is probably not necessary, since GIFs will most likely be converted to a PNG8 anyway because ImageMagick picks the appropriate format based on the number of colors.

Once you’ve converted the GIF to a PNG, don’t forget to still crush the PNG result (as shown in step 1).

If the top 10 sites switch all their GIFs for PNGs (except those that don’t yield a smaller file size), on average, this will result in 20.42% file size reduction. The only inconvenience here is that you also need to write a search/replace script to find all the references to the GIF files and change them to the new PNG versions.

Step 4: Optimize GIF animations

Now that all GIFs are PNGs, PNGs are crushed and so are the JPEGs, what do we have left? GIF animations. One tool that can help you with those guys is called GIFsicle. Since the animations consist of frames and some parts of the image don’t change from one frame to another, GIFsicle doesn’t carry over the duplicate pixel information. The way to run it is:

> gifsicle -O2 src.gif > dest.gif

Smush.it

As we said at the beginning, the beauty of those four steps is that they don’t cause quality loss, so you don’t have to open and compare the results before and after. They are also all command-line tools that can be automated easily. So you have nothing to lose by running all your images through those tools before you FTP them to your web server, you can only win.

And you can always try the smush.it tool, just to get an idea of how much you can potentially save.

This is part 2 in an ongoing series. You can read the other parts here:

• Image Optimization Part 1: The Importance of Images
• Image Optimization Part 3: Four Steps to File Size Reduction
• Image Optimization Part 4: Progressive JPEG…Hot or Not?

This second installment of the image optimization series talks about file formats and how to chose the right one for the job. We’ll briefly discuss the popular GIF and JPEG formats and then move on to highlighting the rock star, PNG, hopefully helping correct some misconceptions about it.

GIF

GIF is a palette (also called “indexed”) type of image. It contains a palette of indexed colors, up to 256, and for every pixel of the image there is a corresponding color index. The format is no longer subject to patent issues, so you can create GIFs without the risk of going to jail. (For more on the history of the GIF format, click here.)

GIF is a non-lossy format, which means that when you modify the image and save it, you don’t lose quality.

GIF also support animations, which, in the dark Web 1.0 ages, resulted in a plethora of blinking “new” images, rotating @ signs, birds dropping … an email, and other annoyances. In the much more civilized Web 2.0 era, we still have “loading…” animations while we wait for the results of the next Ajax request to update the page, but there are also things like the good old shiny sparkles that people like to put in their social network profiles. Nevertheless, animation support is here if you need it.

GIF also supports transparency, which is a sort of boolean type of transparency. A pixel in a GIF image is either fully transparent or it’s fully opaque.

JPEG

JPEG doesn’t have the 256 colors restriction associated with GIFs; it can contain millions of colors and it has great compression. This makes it suitable for photos and, in fact, most cameras store photos in JPEG format. It’s a lossy format, meaning you lose quality with every edit, so it’s best to store the intermediate results in a different format if you plan to have many edits. There are, however, some operations that can be performed losslessly, such as cropping a part of the image, rotating it or modifying meta information, such as comments stored in the image file.

JPEG doesn’t support transparency.

PNG

PNGs is a non-lossy format that comes in several kinds, but for practical purposes, we can think of PNGs as being of two kinds:

1. PNG8, and
2. truecolor PNGs.

PNG8 is a palette image format, just like GIF, and 8 stands for 8 bits, or 2⁸, or 256, the number of palette entries. The terms “PNG8″, “palette PNG” and “indexed PNG” are used interchangeably.

How does PNG8 compare to GIF?

• Pros:
  • it usually yields a smaller file size
  • it supports alpha (variable) transparency
• Cons:
  • no animation support

The second type of PNGs, truecolor PNGs, can have millions of colors, like JPEG. You can also sometimes come across the names PNG24 or PNG32.

And how does truecolor PNG compare to JPEG? On the pros side, it’s non-lossy and supports alpha transparency, but on the cons side, the file size is bigger. This makes truecolor PNG an ideal format as an intermediate between several edits of a JPEG and also in cases where every pixel matters and the file size doesn’t matter much, such as taking screeenshots for a help manual or some printed material.

Internet Explorer and PNG transparency

We said that both PNG types support alpha transparency, but there are some browser eccentricities that affect both types and about which you should be aware.

With PNG8, whenever you have semi-transparent pixels they appear as fully transparent in IE (version 6 and lower). This is not ideal but it’s still useful and is the same behavior that you get from a GIF. So by using a PNG8, in the worst case (IE < 7) you get the same user experience as with a GIF, while for other browsers (Firefox, Safari, Opera) you get a better experience. Below is an example that illustrates this, note how in IE6 the semi-transparent light around the bulb is missing (source: SitePoint):

For truecolor PNGs, the situation is a much less attractive compromise. All the semi transparent pixels appear grey in IE prior to version 7 (source: W3C).

IE7 introduces proper native support for alpha transparency in both PNG8 and truecolor PNGs. For earlier IE versions you need to fix the truecolor PNG transparency issue using CSS and an AlphaImageLoader filter, which we’ll discuss in more details in a follow-up article. (Spoiler alert: avoid AlphaImageLoader.)

“All we are saying is: Give PiNG a chance!”

Although PNG8 should be the preferred of the PNGs, because it’s smaller in filesize and degrades well in early IEs without special CSS filters, there are still some use cases for truecolor PNGs:

• When the 256 colors of the PNG8 are not enough, you may need a truecolor PNG. This is a case you should try to avoid. On one hand, if you have thousands and thousands of colors, this starts to look like a case where JPEG will be better suited and will give better compression. On the other hand, if the colors are around a thousand or so, you may try to convert this image to a PNG8 and see if it looks acceptable. Very often, the human eye is not sensitive enough to tell the difference between 200 and 1000 colors. That depends on the image, of course; often you can safely remove 1000 colors, but sometimes removing even 2 colors results in an unacceptable image. In any event, try your potential truecolor PNG candidate as PNG8 and as JPEG and see if you like the result in terms of quality and file size.
• When most of the image is semi-transparent. If only a small part of the image is semi-transparent, like around rounded corners, the GIF-like degradation of PNG8 is often OK. But if most of the image is translucent (think a PLAY button over a video thumbnail), you might not have a choice but to use the AlphaImageLoader hack.

At the end, let’s summarize what was discussed in this article highlighting that:

• JPEG is the format for photos.
• GIF is the format for animations.
• PNG8 is the format for everything else — icons, buttons, backgrounds, graphs…you name it.

This is part 1 in an ongoing series. You can read the other parts here:

• Image Optimization Part 2: Selecting the Right File Format
• Image Optimization Part 3: Four Steps to File Size Reduction
• Image Optimization Part 4: Progressive JPEG…Hot or Not?

This is the first in a series of posts about image optimization. In this series, I’ll explore how images affect web site performance and what can you do to your images in order to improve page loading times. (I won’t say how many posts in this series, so that I can claim later that I underpromised and overdelivered…).

When you think about improving page response time, one of the first obvious things to think about is the page weight. It’s obvious that, all things being equal, the heavier a page is the slower it will be. If we take this to the extreme, we can say that the fastest page you can possibly have is the blank page. Once you start adding stuff to the blank page, you’re only making it slower.

On a more serious note, it really is up to you how much content you want to put on a page, so let’s focus on what comes next. After you’ve settled on the content, it’s your job to make sure the content and components are as small as possible. Following our Yahoo! performance best practices, you should make sure that all plain text components (HTML, XML, CSS, JavaScript…) are sent compressed over the wire and that you minify CSS and JavaScript.

But what about the images, how can you speed them up without sacrificing quality and looks? But first, does it really matter?

How important are the images?

Before we start, let’s see if we should even bother with images. Lately we’ve been witnessing the rise of rich internet applications with lots of JavaScript — by “lots” meaning sometimes 300K or more worth of JavaScript code. In other cases, especially in advertising, Flash seems to be the weapon of choice. So, on average, how much of the page weight is images. It’s easy to answer this question by just looking at Alexa’s top 10 websites in the world (as of October 2008) and use YSlow to check what percent of the total page weight is images. The results are given below.

On average, 46.6% of the page weight for these popular sites consists of images, included either inline with <img> tags or via CSS stylesheets. Other studies show that this percent can be even higher, depending on the cross section of sites you examine. The exact number is not important, because every site is unique and different from the average; for example Amazon’s home page was made of 75% images at the time of the experiment.

This is a massive percentage and it tells us one thing: There’s huge potential to improve the performance of websites if we can improve the way we handle the image payload. By focusing on images you can make a difference and delight your site visitors with a faster and more pleasant experience.

To be continued…

Over the course of the following weeks, we’ll be publishing more about image optimization. The topics for discussion include:

• different image formats and how to pick the right one
• ways to put your images on a diet without compromising quality
• optimizing generated images
• the effect of using AlphaImageLoader
• favicons
• CSS sprites
• serving images faster

The series of posts will not require Photoshop or other designers’ domain-specific knowledge, so it should be pretty easy for anyone to learn and apply these techniques. More to come soon…

External JavaScript files block downloads and hurt your page performance, but there is an easy way to work around this problem: use dynamic scripts tags and load scripts in parallel, improving the page loading speed and the user experience.

The problem: scripts block downloads

Let’s first take a look at what the problem is with the script downloads. The thing is that before fully downloading and parsing a script, the browser can’t tell what’s in it. It may contain document.write() calls which modify the DOM tree or it may even contain location.href and send the user to a whole new page. If that happens, any components downloaded from the previous page may never be needed. In order to avoid potentially useless downloads, browsers first download, parse and execute each script before moving on with the queue of other components waiting to be downloaded. As a result, any script on your page blocks the download process and that has a negative impact on your page loading speed.

Here’s how the timeline looks like when downloading a slow JavaScript file (exaggerated to take 1 second). The script download (the third row in the image) blocks the two-by-two parallel downloads of the images that follow after the script:

Here’s the example to test yourself.

Problem 2: number of downloads per hostname

Another thing to note in the timeline above is how the images following the script are downloaded two-by-two. This is because of the restriction of how many components can be downloaded in parallel. In IE <= 7 and Firefox 2, it’s two components at a time (following the HTTP 1.1 specs), but both IE8 and FF3 increase the default to 6.

You can work around this limitation by using multiple domains to host your components, because the restriction is two components per hostname. For more information of this topic check the article “Maximizing Parallel Downloads in the Carpool Lane” by Tenni Theurer.

The important thing to note is that JavaScripts block downloads across all hostnames. In fact, in the example timeline above, the script is hosted on a different domain than the images, but it still blocks them.

Scripts at the bottom to improve user experience

As Yahoo!’s Performance rules advise, you should put the scripts at the bottom of the page, towards the closing </body> tag. This doesn’t really make the page load faster (the script still has to load), but helps with the progressive rendering of the page. The user perception is that the page is faster when they can see a visual feedback that there is progress.

Non-blocking scripts

It turns out that there is an easy solution to the download blocking problem: include scripts dynamically via DOM methods. How do you do that? Simply create a new <script> element and append it to the <head>:

var js = document.createElement('script');
js.src = 'myscript.js';
var head = document.getElementsByTagName('head')[0];
head.appendChild(js);

Here’s the same test from above, modified to use the script node technique. Note that the third row in the image takes just as long to download, but the other resources on the page are loading simultaneously:

Test example

As you can see the script file no longer blocks the downloads and the browser starts fetching the other components in parallel. And the overall response time is cut in half.

Dependencies

A problem with including scripts dynamically would be satisfying the dependencies. Imagine you’re downloading 3 scripts and three.js requires a function from one.js. How do you make sure this works?

Well, the simplest thing is to have only one file, this way not only avoiding the problem, but also improving performance by minimizing the number of HTTP requests (performance rule #1).

If you do need several files though, you can attach a listener to the script’s onload event (this will work in Firefox) and the onreadystatechange event (this will work in IE). Here’s a blog post that shows you how to do this. To be fully cross-browser compliant, you can do something else instead: just include a variable at the bottom of every script, as to signal “I’m ready”. This variable may very well be an array with elements for every script already included.

Using YUI Get utility

The YUI Get Utility makes it easy for you to use script includes. For example if you want to load 3 files, one.js, two.js and three.js, you can simply do:

var urls = ['one.js', 'two.js', 'three.js'];
YAHOO.util.Get.script(urls);

YUI Get also helps you with satisfying dependencies, by loading the scripts in order and also by letting you pass an onSuccess callback function which is executed when the last script is done loading. Similarly, you can pass an onFailure function to handle cases where scripts fail to load.

var myHandler = {
    onSuccess: function(){
        alert(':))');
    },
    onFailure: function(){
        alert(':((');
    }
};

var urls = ['1.js', '2.js', '3.js'];
YAHOO.util.Get.script(urls, myHandler);

Again, note that YUI Get will request the scripts in sequence, one after the other. This way you don’t download all the scripts in parallel, but still, the good part is that the scripts are not blocking the rest of the images and the other components on the page. Here’s a good example and tutorial on using YUI Get to load scripts.

YUI Get can also include stylesheets dynamically through the method
YAHOO.util.Get.css() [example].

Which brings us to the next question:

And what about stylesheets?

Stylesheets don’t block downloads in IE, but they do in Firefox. Applying the same technique of dynamic inserts solves the problem. You can create dynamic link tags like this:

var h = document.getElementsByTagName('head')[0];
var link = document.createElement('link');
link.href = 'mycss.css';
link.type = 'text/css';
link.rel = 'stylesheet';
h.appendChild(link);

This will improve the loading time in Firefox significantly, while not affecting the loading time in IE.

Another positive side effect of the dynamic stylesheets (in FF) is that it helps with the progressive rendering. Usually both browsers will wait and show blank screen until the very last piece of stylesheet information is downloaded, and only then they’ll start rendering. This behavior saves them the potential work of re-rendering when new stylesheet rules come down the wire. With dynamic <link>s this is not happening in Firefox, it will render without waiting for all the styles and then re-render once they arrive. IE will behave as usual and wait.

But before you go ahead and implement dynamic <link> tags, consider the violation of the rule of separation of concerns: your page formatting (CSS) will be dependent on behavior (JS). In addition, this problem is going to be addressed in future Firefox versions.

Other ways?

There are other ways to achieve the non-blocking scripts behavior, but they all have their drawbacks.

Future

Safari and IE8 are already changing the way scripts are getting loaded. Their idea is to download the scripts in parallel, but execute them in the sequence they’re found on the page. It’s likely that one day this blocking problem will become negligible, because only a few users will be using IE7 or lower and FF3 or lower. Until then, a dynamic script tag is an easy way around the problem.

Summary

• Scripts block downloads in FF and IE browsers and this makes your pages load slower.
• An easy solution is to use dynamic <script> tags and prevent blocking.
• YUI Get Utility makes it easier to do script and style includes and manage dependencies.
• You can use dynamic <link> tags too, but consider the separation of concerns first.

In Performance Research Part 1, we discussed how reducing the number of HTTP requests has the biggest impact on improving the response time and is often the easiest performance improvement to make. One technique without having to simplify the page design is to combine multiple scripts into a single script, and similarly combine multiple stylesheets into a single stylesheet.

Combining multiple files reduces the extra bytes from HTTP headers as well as potential transfer latency caused by TCP slow starts, packet losses, etc.

Figure 1 shows a graphical view of how time is spent loading a page with six separate scripts. Notice that for every file, the browser makes a separate HTTP request to retrieve the file. The gaps between the scripts indicate the time the browser takes to parse and render each script. Figure 2 shows the how time is spent loading a page with the same six scripts combined into a single script.

Combining JavaScript and CSS files as part of the development process can be burdensome. It usually makes sense during development to organize the code into logical modules as separate files. Typically, combining those separate files before product release is either a manual process or part of a build process. Every time one of the individual files is changed, the larger file needs to be re-combined and re-pushed. The cost of this across an organization as large as Yahoo! is significant.

Serve Files Faster using Combo Handler

Combo Handler, built in collaboration by Yahoo!’s Exceptional Performance team and the groups that support our CDN, is one solution to combine multiple files into a single, larger file.

Combo Handler provides a way to allow developers to maintain the logical organization of their code in separate files, while achieving the advantages of combining those into a single file as part of the final user experience. It alleviates the need for the time-consuming re-build and re-push processes. In addition, Combo Handler integrates seamlessly into a content delivery network, taking full advantage of the benefits of a CDN while reducing the drawbacks of dynamically combining separate files.

We’ve been using this service across many Yahoo! properties for some time now to help improve end users’ response times. Thanks to the YUI team, it is now available to all of you that are using the Yahoo!-hosted YUI JavaScript files. (Note: Combo-handling of CSS files is not supported at this time.) Head over to the YUI Configurator to generate combo-ready filepaths customized for your specific YUI implementation.

Combo Handler Best Practices

When using Combo Handler to combine files, pay special attention to the order in which the files are specified. Not only could there be file dependencies, browsers will only use the cached version of a file if the filename extracted from the URL is identical. For example, suppose the following smaller files (dom.js and event.js) are combined into a single larger file using Combo Handler:

   http://yui.yahooapis.com/combo?event.js&dom.js
   http://yui.yahooapis.com/combo?dom.js&event.js

In the example above, the browser will download and cache both files separately because the filenames are actually different.

Also, you may not always want to combine all files into one single file. Suppose you have one or more scripts that are shared across multiple pages in your site in addition to scripts that are only used on specific pages. By combining everything into one large file and using this file across your entire site, some pages will spend time downloading more than it really needs. Instead, take a look at different types of combinations. You might combine the scripts that are used in every page across your site into one script. Then for each page or group of pages, combine common scripts into another separate script.

Yahoo! HotJobs Combines and Reduces Response Time by 8%!

The Exceptional Performance team ran an experiment with Yahoo! HotJobs to determine the response time savings our users would benefit from by combining multiple files into a single file. Two real user test buckets were created for this experiment. In one bucket, users visited a page with six JavaScript files left uncombined. In the second bucket, users visited the same page with the six JavaScript files combined into one single file.

Combining six JavaScript files into one single JavaScript file improved performance by almost 8% on average for Yahoo! HotJobs’ users on broadband bandwidth speeds and 5% for users on lan. No design or feature changes required!

Keep in mind that the page we tested was already highly optimized for performance and had a YSlow “A” grade. The response time savings depend on a number of factors including number of files combined, browser caching patterns, etc. This experiment supported our previous research, which indicated that reducing HTTP requests is an effective way to improve response times for our end users.

Takeaways

Improve response times by combining multiple JavaScript and CSS files. Yahoo!’s Combo Handler Service is one solution that provides a way to make fewer HTTP requests for Yahoo!-hosted JavaScript files, and also leverages the benefits of a Content Delivery Network.

• Combine scripts and stylesheets to reduce HTTP requests.
• Look at different types of file combinations.
• Avoid users from having to download more than they really need.
• Pay special attention to the order in which files are combined.

Thanks to the hard work of the Yahoo Exceptional Performance team and the groups that support our CDN, we’re now able to offer ad-hoc file aggregation — "combo handling" — to file served from yui.yahooapis.com. So, a request for the full YUI Rich Text Editor, which previously looked like this…

<script type="text/javascript"
   src="http://yui.yahooapis.com/2.5.2/build/yahoo-dom-event/yahoo-dom-event.js"></script>
<script type="text/javascript"
   src="http://yui.yahooapis.com/2.5.2/build/container/container_core-min.js"></script>
<script type="text/javascript"
   src="http://yui.yahooapis.com/2.5.2/build/menu/menu-min.js"></script>
<script type="text/javascript"
   src="http://yui.yahooapis.com/2.5.2/build/element/element-beta-min.js"></script>
<script type="text/javascript"
   src="http://yui.yahooapis.com/2.5.2/build/button/button-min.js"></script>
<script type="text/javascript"
   src="http://yui.yahooapis.com/2.5.2/build/editor/editor-beta-min.js"></script> 

…can now be written this way:

<script type="text/javascript"
src="http://yui.yahooapis.com/combo?2.5.2/build/yahoo-dom-event/yahoo-dom-event.js&
2.5.2/build/container/container_core-min.js&2.5.2/build/menu/menu-min.js&
2.5.2/build/element/element-beta-min.js&2.5.2/build/button/button-min.js&
2.5.2/build/editor/editor-beta-min.js"></script>

In one step, this eliminates five separate HTTP requests.

A few notes regarding combo handling on yui.yahooapis.com:

• If you’re using the YUI Configurator, this option ("Combine All JS Files") is enabled by default as long as you’re using the default base path.
• Combo-handling of YUI CSS files is not supported at this time.
• In an upcoming release, we’ll provide built-in combo-handling support in YUI Loader and restructure filepaths in YUI’s CSS resources to make them combinable as well.
• YUI Configurator will always output the current version of the library, but all YUI JS files from 2.2.0 onward are present on yui.yahooapis.com and can be combined using the same combo-handling syntax.

We hope combo handling provides a easy performance win for those of you letting Yahoo serve your YUI files. Discussion of combo handling and all YUI issues takes place in our community forum — please join us there and let us know how this works for you.

Julien’s YUI Compressor is an incredibly useful tool for decreasing the size of your JavaScript files. Since it uses Rhino to parse your JavaScript code, it can perform all kinds of smart operations to save bytes in a completely safe way:

• Replacement of local variable names with shorter (one, two, or three character) variable names.
• Replacement of bracket notation with dot notation where possible (i.e. foo["bar"] becomes foo.bar).
• Replacement of quoted literal property names where possible (i.e. { "foo":"bar" } becomes { foo:"bar" } ).
• Replacement of escaped quotes in strings (i.e. 'aaa\'bbb' becomes "aaa’bbb").

Running your JavaScript code through YUI Compressor results in tremendous savings by default, but there are things you can do to increase the byte savings even further.

Use Constants for Repeated Values

In my talk, Maintainable JavaScript, I talk about using constants (really, just variables that you have no intention of changing) to store repeating values. The idea is that your code is more maintainable because you have a single place to change a value instead of multiple places. As it turns out, this technique also helps YUI Compressor to remove more bytes. Consider the following function:

function toggle(element){
    if (YAHOO.util.Dom.hasClass(element, "selected")){
        YAHOO.util.Dom.removeClass(element, "selected");
    } else {
        YAHOO.util.Dom.addClass(element, "selected");
    }
}

This simple function is designed to toggle the “selected” class on a given element. If the element has the class, then it’s removed; if the element doesn’t have the class, it’s added. As a result, the string “selected” appears three times in the function. The function takes 212 bytes (including white space). When compressed, the resulting code is as follows:

function toggle(A){if(YAHOO.util.Dom.hasClass(A,"selected")){YAHOO.util.Dom.removeClass(A,"selected")}else{YAHOO.util.Dom.addClass(A,"selected")}}

This code weighs in at 146 bytes (a savings of 30%), but you can see that the string “selected” still appears three times. Moving the repeated value into a variable makes the code more maintainable and allows YUI Compressor to remove extra space. Here’s the rewritten function:

function toggle(element){
    var className = "selected";
    if (YAHOO.util.Dom.hasClass(element, className)){
        YAHOO.util.Dom.removeClass(element, className);
    } else {
        YAHOO.util.Dom.addClass(element, className);
    }
}

This code is slightly larger than the original (241 bytes versus 212 bytes), but compresses down to the following:

function toggle(A){var B="selected";if(YAHOO.util.Dom.hasClass(A,B)){YAHOO.util.Dom.removeClass(A,B)}else{YAHOO.util.Dom.addClass(A,B)}}

Note that this compressed code only has one instance of “selected”, resulting in a final byte size of 136 bytes, 10 bytes fewer than the previous version. The savings grow as the instances of the string increase, so if you have 20 places where “selected” was being used, you’d see even greater savings.

Replacing repeated values in your code can lead to greater incremental savings as the number of repeated values increases, as well. It is worthwhile to consider this approach not just for strings, but also for numbers (even Boolean values, if you so desire).

Store Local References to Objects/Values

The YUI Compressor can’t perform variable replacement for either global variables or multi-level object references, so it’s better to store these in local variables. The previous example has three instances of YAHOO.util.Dom in the source code, and so the compressed version also has three instances. By storing YAHOO.util.Dom in a local variable, you can reduce the number of times that it appears in the compressed code. For example:

function toggle(element){
    var className = "selected";
    var YUD = YAHOO.util.Dom;
    if (YUD.hasClass(element, className)){
        YUD.removeClass(element, className);
    } else {
        YUD.addClass(element, className);
    }
}

This version of the function is 238 bytes, and when compressed, shows even greater savings than the previous versions of the function:

function toggle(A){var B="selected";var C=YAHOO.util.Dom;if(C.hasClass(A,B)){C.removeClass(A,B)}else{C.addClass(A,B)}}

The final weight for this version is 118 bytes, a savings of 28 bytes over the original compressed function and 120 bytes smaller from the uncompressed version. And this is just one function, imagine if you got the same savings for all functions in your script.

Keep in mind that this technique also applies to object properties, so if className were a member of an object, its value should be stored locally as well. For instance:

function toggle(element){
    var YUD = YAHOO.util.Dom;
    if (YUD.hasClass(element, Constants.className)){
        YUD.removeClass(element, Constants.className);
    } else {
        YUD.addClass(element, Constants.className);
    }
}

In this function, Constants.className contains the class to use. The variable Constants is global, so its name cannot be replaced. You could set up a reference to Constants, but that is inefficient because you’re only using one property of that object in the function, so set up a reference to Constants.className to save even more bytes:

function toggle(element){
    var className = Constants.className
    var YUD = YAHOO.util.Dom;
    if (YUD.hasClass(element, className)){
        YUD.removeClass(element, className);
    } else {
        YUD.addClass(element, className);
    }
}

Avoid eval()

By this point, you’ve been told that eval() is evil multiple times and by multiple people. YUI Compressor agrees. The nature of eval() is such that the code executed has access to the variables that are present in the scope in which eval() was called. Because of that, YUI Compressor can’t safely do variable name changing when eval() is present. For example:

function doSomething(code){
    var msg = "hi";
    eval(code);
}

doSomething("alert(msg)");   //”hi”

Even though the string that is being passed to eval() exists outside of the function in which eval() is called, it still has access to the local variables in that function. Since YUI Compressor can’t possibly know that the variable code contains a reference to a variable in the function, it doesn’t change the variable names in the doSomething() function, resulting in a less-than-optimal compression. Remember this: any time you use eval() in a function, that function’s variables cannot be renamed. The best approach is, as often said, to avoid eval() at all costs. If you absolutely must use eval() for some reason, try to isolate it away from other code so that the amount of variable renaming issues are minimal. For example:

function myEval(code){
    return eval(code);
}

function doSomething(code){
    var msg = “hi”;
    var count= 10;

    myEval(code);
}

In this code, the call to eval() is isolated away from the main body of the doSomething() function. Now, YUI Compressor is free to replace variables in doSomething().

Avoid with

The with statement is another that is often recommended to avoid in JavaScript. For YUI Compressor, the reason is the same for eval(): just the presence of with in a function causes variable renaming to be skipped for the entire function. There is just no way to keep track of variables versus object properties in the context of a with statement, so YUI Compressor rightly leaves the code as-is to avoid breaking the functionality. The best advice here is to avoid using with altogether. If you follow the advice of storing local copies of objects/properties, you should have no use for with.

Use the Verbose Option

YUI Compressor has a “verbose” option (activated by the –v command line switch) that can help in the identification of some of these issues as well as a few others. The verbose option prints out warnings to the console indicating things that are preventing the YUI Compressor from fully doing its job. It will, for instance, tell you that a function contains eval() or the with statement, and therefore cannot be properly compressed. It also does analysis of variables, telling you if a variable was never defined (in which case it becomes global and cannot have its name replaced), if a variable was defined and never used (which just wastes space), and if a variable has been declared multiple times (also a waste of space).

Conclusion

When used alone, the YUI Compressor achieves an excellent compression rate of your JavaScript code. The greatest byte savings are achieved by taking full advantage of variable replacement. The hints presented here have the primary goal of ensuring the YUI Compressor can do variable replacement whenever possible. Using constants to represent repeated values not only aids in compression, but also aids in the maintainability of your code by limited the number of areas that must be updated to accommodate a change in the value. Using local variables for multi-level object references allows for greater compression through variable replacement as well as providing faster runtime performance (local variable access is faster than global variable access and object property lookup). Perhaps most important is to ensure that you don’t use eval() or with when they’re not necessary, as each causes variable replacement to be turned off in the containing function. The YUI Compressor does a lot for you, but it can’t do everything. You can help it out greatly by following these tips.