J’avais déjà présenté Yslow, et de toutes façons tous ceux qui lisent ce blog doivent maintenant connaître cet outil indispensable. Stoyan Stefanov, de l’équipe performande de Yahoo!, a fait en chine la première présentation sur ce qui arrive avec la version 2.0 de Yslow. Pour tout vous dire j’avais le secret espoir que l’annonce de Yslow 2.0 soit faite à Paris Web 2008 lors de l’intervention que j’ai partagée avec Nicole Sullivan, mais la finalisation a visiblement demandé du temps.
Une mise à jour attendue …
J’avais, comme tout le monde, deux principaux reproches à faire sur l’outil. Tout d’abord il ne vérifie qu’une liste très spécifiques de critères. Ce sont une partie des 14 premiers critères retenus par l’équipe performance de Yahoo! mais depuis d’autres recommandations ont pu être dégagée. Il était nécessaire que l’outil s’étoffe.
C’est donc 10 règles supplémentaires qui sont intégrées dans l’outil, pour un total de 23. Mais là où Yslow aurait pu avoir une simple mise à jour, l’équipe Yahoo! a permis l’arrivée d’un modèle communautaire, où chacun peut ajouter facilement ses propres critères. C’est l’histoire de quelques lignes de javascript dans une extension Firefox.
Le second point contestable était le système de notation. Toutes les règles ne sont pas adaptables à tout le monde, avec la même importance. Le premier exemple c’est la question des ETags qui pénalise des notations pour rien, soit parce que l’ETag n’est pas généré avec le système par défaut d’Apache, soit parce qu’il n’y a qu’un seul serveur web derrière le site. Chacun a ses spécificités et je retiens encore l’exemple qu’on m’a donné des sites chinois qui ont tendance à avoir des pages web longues de plusieurs dizaines d’écran parce les usages locaux font qu’on télécharge la page pour une lecture hors ligne, et qu’on espère donc en avoir le plus possible dedans quitte à attendre longtemps.
Bref, là aussi Yslow est personnalisable et il sera possible de définir vos propres algorithmes de notation, voire de choisir le type de notation souhaité parmi une liste. À vous de définir vos limites, vos paliers, vos pénalités et les règles qui sont pertinentes à votre site … ou plutôt à choisir un algorithme créé par quelqu’un d’autre et adapté à votre cas. L’idée est de non seulement pouvoir modifier ces préférences via une interface mais aussi de pouvoir les exporter automatiquement pour les diffuser à d’autres.
… et efficace …
Bref, c’est une très bonne nouvelle, qui va permettre de voir fleurir des personnalisations de Yslow propre à certains types de sites, aux recommandations internes de votre société, ou simplement adaptées à votre échelle. Je m’abstiens de recopier les images ou le code, vous trouverez tout ça dans la présentation de Stoyan.
Mais on trouve encore d’autres petits outils. Parmi eux des menus pour réindenter le code javascript et faire un passage par JSLint. Là encore, quelques lignes de javascript sont prévues pour rajouter vos propres outils.
Mieux, et ça c’est excellent, il est prévu de sauvegarder votre session de résultat pour une étude plus tard et d’importer de sessions crées par Fiddler ou HttpWatch.
… mais imparfaite
Mais tout n’est pas parfait. Dans les recommandations on trouve la #14 (Make Ajax cacheable). Difficile à dire pour un outil automatisé s’il est normal que tel ou tel appel Ajax soit en cache ou dynamique. Je suis dubitatif sur l’idée d’avoir automatisé cette règle là. Même chose pour la #33 (Components under 25k). La limite de 25k est celle de l’Iphone, mais on a vu que les nouveaux firmware Iphone et Ipod Touch permettent de dépasser allègrement cette limite. Bref, on l’ajoute dans Yslow quand il serait presque venu le temps de la retirer de la liste globale des recommandations.
Il y en a d’autres que j’aurai aimé voir, mais qui doivent être bien plus complexes à automatiser. Par exemple :
- trop de présentation en HTML au lieu de CSS
- code javascript lent
- présence de eval() en javascript
- sélecteurs CSS vraiment mal fait
- événements DOM mutualisables avec de la délégation
- processeur excessivement utilisé lors du rendu
- tableaux html dynamique trop gros ou imbriqués
Ah et … pas de date de sortie ni de version béta publique, pour l’instant. Reste que ces nouvelles sont bonnes.
Devoir lire jusqu’à la fin pour voir « pas de date de sortie ni de version béta »… aeeergh…
« Yslow est personnalisable et il sera possible de définir vos propres algorithmes de notation, voire de choisir le type de notation souhaité parmi une liste »
Oui bonne idée, de laisser le choix du profil, il ne reste plus qu’à attendre.
Ça a l’air alléchant sur certains points. Mais j’espère sincèrement qu’il ne perdra pas son côté outil de base pour commencer à optimiser son site. Ça me parait génial pour passer au niveau supérieur, mais il ne faudrait pas qu’il laisse de côté tous les néophytes.
Bien d’accord avec Rik, le côté « plug-in clés en main » de Yslow fait beaucoup pour sa popularité et est un levier important pour sa diffusion auprès du grand public : on commence à peine à évangéliser avec cet outil dans les webagencies ou chez les clients (où la performance front est encore trop souvent une lointaine chimère intégriste)…
J’ai pour ma part usé et abusé de Yslow pour optimiser mon nouveau site (j’obtiens une note plus que correcte d’ailleurs =), je ne m’arrêterai pas en si bon chemin !
Juste une remarque, Fiddler et HttpWatch ne sont dispo que pour windows.
Sous linux (et probablement Mac OS X), on peut utiliser http://livehttpheaders.mozdev.org/ qui permet de suivre les headers échangés (et éventuellement le contenu des post).
Je viens d’essayer la version actuelle de Yslow, la majorité des sites que j’utilise (des sites très connus comme wikipedia ou netvibes) reçoivent une note de F. Je suis par ailleurs assez surpris de certains conseils donnés, comme par exemple le fait de « gzipper » les fichiers appelés : n’est-ce pas une fonction déjà disponible par défaut dans Apache? Le temps gagné sur les données transmises ne sont-elles pas de toute façon perdues à décompresser les fichiers?…
De toute façon, les services web2 ne seront jamais très performants, si on suit ce genre de recommandations, à moins de modifier la structure du web en profondeur.
La plupart des sites sont effectivement pourris. Tu dois bien te rendre compte de la différence entre Yahoo, Google, Amazon et les autres…
Pour gzip oui, c’est une fonction disponible dans Apache, et on ne demande pas plus que de l’utiliser. Sauf qu’en pratique ça reste une activation manuelle, que beaucoup de site ne font pas.
Le temps gagné est infiniment plus important que le temps perdu à la décompression. Déjà parce que le réseau est dix fois plus « cher » côté performances que le processeur, ensuite parce que votre réseau est souvent très utilisé alors que le processeur est souvent en dessous de 10% (sur une session web), mais aussi parce que décompresser un contenu ne prend virtuellement rien comme ressources. Quand je travaillais sur pentium pro à 200Mghz sur les serveurs on considérait déjà que compression et décompression ne prenait quasiment pas de ressources, que ce soit sur le serveur ou sur le client. Avec les Core 2 Duo comme standard sur les machines de bureau …
Un service « web 2,0 » je suppose que tu veux parler d’ajax, mais alors ça ne change vraiment rien aux recommandations. Le principe est le même, les recommandations à appliquer sont globalement les même, et l’architecture à utiliser côté web est vraiment la même. Du point de vue architecture ces requêtes ajax ne sont que des requêtes http classiques, qui obéissent aux mêmes règles et se décomposent de la même façon.
On reconnait d’ailleurs une bonne architecture Ajax au fait qu’elle utilise des ressources HTTP de façon classique tel qu’on le ferait sans Ajax (seul le format et l’enrobage des données transmises peut changer)