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).

les fichiers flash sont une plaie pour le poids des pages, mais ça vous le saviez déjà. Ils sont lourds, difficilement modifiables, jamais remplaçables. Mais ils plaisent au marketing et aident à vendre plein de mobiles, de lecteurs mp3, des portefeuilles ou des montres sur mesure où vous gravez votre nom. Difficile de les refuser...

Le plus génant est qu'ils sont faits par des gens qui n'ont aucune considération pour le cache, et je sais de quoi je parle (vous voulez voir toutes mes réalisations en Flash?). Notamment, une méthode très utilisée pour passer des paramètres à un flash est de mettre comme url de source le nom de fichier suivi d'un point d'interrogation puis tous les paramètres. Attention danger! Ce n'est pas cachable.

C'est même à l'origine le meilleur moyen utilisé par les développeurs pour être surs de charger le flash ou une autre ressource sans cache : forcer un paramètre variant à chaque requête. Quelque chose comme compteur.swf?now=2543985.

Vous pouvez mettre une directive de cache sur le fichier swf, cela ne changera malheureusement pas le comportement du navigateur au premier chargement : il téléchargera le fichier flash plusieurs fois comme s'il était différent à chaque fois.

Il existe une solution pourtant bien documentée qui permet d'éviter ce comportement et de pousser le flash dans le cache. Quand vous passez du stade développement au stade recette ou production, pensez à utiliser les flashvars. C'est l'autre moyen de passer des paramètres au lecteur Flash, sans utiliser l'url. C'est tellement bien documenté que des objets comme swfobject, la librairie la plus utilisée pour intégrer les flash a des méthodes pour faire ce passage de paramètres.

Maintenant, si vous utilisez un énorme fichier ou que vous avez besoin d'informations toujours garanties fraiches, vous devrez utiliser d'autres méthodes pour améliorer le temps de chargement. Je vous conseille le résau de distribution de contenu.

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.

J'ai reçu et dévoré en quelques heures le livre écrit par Steve Souders du Yahoo Perfomance group. Je n'ai qu'un reproche à lui faire, celui d'être américain.

Dans ce livre, le deuxième sur le sujet et le premier en anglais, le responsable du Yahoo Perfomance Group fait le point et décrit par le menu les 14 règles à appliquer pour obtenir des pages super performantes. Concis et précis, ce livre est à mettre entre les mains de tous les ingénieurs travaillant sur des sites à fort trafic.

En effet, il va assez loin dans chacune des règles qu'il édicte, assez loin pour que chaque règle soit détaillée, que tous les exemples soient analysés jusqu"u niveau de la requête Http, que les solutions basiques, mais aussi les plus astucieuses soient expliqées. Par exemple, j'adore le coup du dynamic inlining de fichiers js et css.

La rédaction est claire, les exemples précis, les schémas explicites.

Deux regrets toutefois : la problématique du https est peu évoquée, un peu comme si cela n'existait pas. Et la question des cookies et de leur influence sur la lenteur des requêtes.

Et un gros reproche : il est américain. Cela veut dire qu'il est inaccessible aux non anglophones. Cela veut dire aussi que tous les exemples sont us.

Somme toute, une lecture indispensable, même pour moi : je n'ai presque rien découvert, mais la structuration et les efforts d'explication des cas les plus complexes étaient les bienvenus.

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.

Aux quatre coins de la performance

J'évolue dans un environnement de grosse entreprise, plein de consultants et de managers. Il faut trouver des formules choc et des raccourcis assez synthétiques, des systèmes qui permettent de comprendre des systèmes complexes (j'ai plus de 30 applications dans mon périmètre).

Je vais donc résumer la performance selon un carré, ce qui me permettra de montrer où nous sommes bons et mauvais, où nous avons mené des actions. Bien entendu chaque coin du carré peut avoir lui aussi des subdivisions , mais je n'en parlerai qu'avec les intervenants d'ingénierie.

Cela résumera la performance à quatre facteurs. A cinq, on dépasse la capacité de mémorisation.

C'et pour vous aussi une bonne manière de vous souvenir de tout ce qui impacte votre performance et de synthétiser vos problèmes et vos actions.

1. La page html

C'est La Source. Impossible de parler d'affichage d'une page web sans parler de la page web dans laquelle tout commence.

C'est aussi souvent là que se concentrent tous les problèmes. Parce que qui dit page web dit redirections pour y accéder, bases de données à interroger, serveurs surchargés.

Pas d'échappatoire : si votre page est lente, votre carré n'a qu'une petite surface.

Par contre, pour agir sur ce problème, il faudra changer profondément quelque chose : votre architecture, votre matériel ou votre développeur. Je vous conseille donc de ne pas vous engager dans cette voie.

2. Le réseau

Le web, c'est du contenu transporté dans des tuyaux. Si le contenu est important, le tuyau l'est plus encore.

C'est en effet dans le tuyau qu'est la latence la plus inéluctable : regardez le temps qu'il faut pour aller jusqu'à un serveur distant, comme celui de cnet.

Plus le tuyau est long, plus il est lent et plus cela aura un impact important sur votre perfomance générale. Et ce la sera aggravé par le quatrième cxoin de la performance.

3. Le navigateur

Il y a un peu d'intelligence et d'interactivité dans le web de 2007. Les pages se constituent en utilisant des attributs qui nécessitent une bonne dose de réflexion, et sont dynamiques coté client: css javascripts et modèle dom rendent la page plus dynamique mais aussi plus lente.

Il y a aussi malheureusement des fonctionnements qui ne sont pas dynamiques mais impliquent une charge supplémentaire sur le serveur : les requêtes https. Pour respecter la couche de transport, les requêtes doivent être encryptées au même titre que les réponses renvoyées par le serveur.

La manière dont fonctionnent les différents navigateurs est un opérande de la performance. Un navigateur comme Safari qui charge tout le contenu css en parallèle a in fine plus de performance qu'un qui les chargerait l'un après l'autre.

4. Le poids

Le coin qui ferme le carré est celui auquel tous les utilisateurs pensent en premier quand ils doivent apparaitre quelque chose sur le web en un temps donné. Je me rappelle de conversations épiques avec les responsables d'un site qui allait passer à une taille adaptée à du 1024x768 : la page serait plus grande donc forcément, ce serait plus lourd et plus lent.

Le poids est important, mais parfois plus que le poids, c'est souvent la quantité qui importe. Essayez de faire transiter un objet de 100 Ko et 100 objets de 1 Ko : vous n'obtiendrez pas le même résultat.

Mettez le nombre d'éléments et une lenteur réseau dans la même balance, et vous verrez que les deux se surchargent et font effondrer votre performance.

Avec ces 4 facteurs, et ces quatres axes de jugement de la performance, je peux tenir facilement une heure sur le sujet de la performance de notre site. Expliquer comment ces axes sont sous la responsabilité de différentes personnes (développeur, ingénieur réseau, graphiste/intégrateur html, responsable de contenu), expliquer comment deux erreurs se combinent pour rendre la performance dramatique. Essayez vous aussi de juger de vos pages avec ces éléments à l'esprit.