le lab

You just love them : these flash files are heavy, uncontrolable, resist any attempt to replace it with something lighter, and they seem to pop out on every single godamn page. Well, maybe you don't like them so much but Bill and Brenda at marketing do : it increases their sales, spices up their pages and makes them all the more important.

What you have to love is how most flash files don't seem to go into the cache of browsers. It gives you an occasion to think about things are done and apply all the advice you read here.

I have recently come across such an occasion. A web page contained an incredible amount of mobile phones (88), and even several flash animations for events that had occured over the weekend. The same, 46 KB flash animation, downloaded different 12 times, thus accounting for more than 600K.

Why so much hate? Well that's because the flash developer had parameters to give to the flash file. And to do so, he used the scr url. When you want to give parameters to Flash files, you can put them as cgi get parameters, thus using urls such as flash.swf?id=12345&cache=absolutely never.

What the http 1.1 mechanism of your web browser does is recognize that the url of the resource is different, thus requesting a different representation of the same resource.

Of course you should use cache directives to ask the browse to cache. A cache-control: max-age=3600 is a sound directive to add in the headers of the files as you send them. Check your local web server to see how things are nice. Unfortunately, this won't be of much use in the case we describe. As all requests are different, you'd have to come back to the same page to see this in action.

What you definitely need to do is get your flash developer straight. Using urls is old school. Since Flash 6, you can use flashvars to do such a thing as passing parameters. It means that you can pass different parameters for each flash file, and give the exact same url for the source flash file. Flashvars are easy to use, available on both the active X and the plugin. Even swfobject enforces flashvars.

So next time you decide to add Flash files in production, make sure during your tests that no parameters are passed.

if you're the Flash video kind of guy, I advise you to go check what limelight or akamai can do rather than try to serve 50 simultaneous users (50 at 150 kb/s is 7.5Mb/s).

When you want to have pages that perform, it is essential for you to be able to measure that performance, and to jump into the reasons of non performance. These are the tools I use and recomend each day :

Firebug

Firebug is an extension to Firefox hich goes deep inside the DOM, the javascripts but also the network behaviour of your page. Using the 'net' tab of that plug-in, you can see how your page downloads. Clicking on a downloaded item, you can see its headers, including cookies, etags etc.

Safari web inspector

Available with the latest developer versions of Safari 3 for Windows and Mac is the web inspector. It reproduces most of the features of Firebug for Webkit, the open source framework that powers Safari.

Still a bit young and lacking features such as precise time for each resource or full url display, it provides a nice summary that quickly helps you to break apart in categories the time and size of your pages.

HttpWatch

If the world was full of firefoxes doing their safari, it probably would be much easier to roll out new standards. The browser world is still dominated by Internet Explorer though.

To know how you page behaves for 70% of you visitors, you need to use HttpWatch, available both in a free and a costly version : it traces sessions of recording, not just pages, is better at showing out redirects. You can record and keep and transmit to other users of HttpWatch the full http traffic of your session. A great tool.

YSlow

This tool is the one I'd recommend to first time users and people with least know how in the performance field. It's a plugin to Firebug (you need firefox and firebug to install it) that analyzes the result of your page. You get recomendations and marks on the 14 rules of Steve Souders. I should do something similar for my ten rules.

With all these tools in your basket, each page should tell you its story and explain pretty quickly why it's slow : redirects, too many requests, too heavy, no cache etc. Now it's up to you to discover the remedy.

Steve Souders and the guys at the Yahoo performance group have done a wonderful job at summarizing and explaining where the performance lies for a web page. Of course, summarizing in 13 rules doesn't fit everyone's web site.

Both as a developer, a cto and a project manager, I have come across slow web sites. Some of my worst memories are france2 home page or aol classifieds. But my worst memory of all is the 25th october 2006, when the home of Sfr changed. Since that day, with the help of wonderful people and despite real shmucks, I have learned the hard way 10 rules for performance.

1. Redirections are evil
2. You don't need more than one css or one javascript
3. Trust the cache, and give it as much as you can
4. Compress text content
5. Watch cookies
6. Don't destroy a good first impression with slow https
7. Use several sub domains
8. Watch your doctype and your syntax
9. Reduce the number of http requests
10. Make web applications faster

These rules (except number 10) are based on the fact that 80 or 90% of the time to display a page is on the client side. I have learned this during my days as an Html developer (I've done them all), and it's taken me a lot of time to explain it to those wap weenies you find at telcos.

I have written an ebook in french detailing those rules and describing how you can help your pages. I might translate it in english.