Retour d'expérience YSlow et Page Speed

J'ai beaucoup utilisé YSlow ces temps ci, en particulier parce pour la première fois j'ai reçu des exigences de performance incluant le grade YSlow.

Je ne reviendrai pas sur la présentation de ces deux outils. Il existe de nombreux commentaires listant la mise en oeuvre et décrivant les règles.

• Yahoo's YSlow
• Google's Page Speed
  

Je voudrais simplement faire un retour d'expérience sur YSlow et Page Speed. C'est un retour QA plus que développeur, car j'interviens sur un projet dans la phase d'optimisation juste avant les tests de performance.

Les deux sont des plugins Firebug et s'installent très facilement. Ils apparaissent ensuite comme onglets dans Firebug. Bien sûr, l'utilisation de Firebug implique que l'application tourne sur Firefox. Pour IE, il existe AOL Page Test, que je n'ai pas testé, vu qu'il a obstinément refusé de fonctionner.

Même s'ils apparaissent très similaires et sont basés en gros sur les mêmes Best Practices, les deux outils ne sont pas positionnés de la même manière.



YSlow

YSlow facilite la communication sur les performances :

• Le grade général permet d'avoir une appréciation globale du niveau de performance, et par conséquent de communiquer sur l'évolution de ce niveau
• Un rapport HTML peut être généré très facilement et diffusé
• Ces rapports peuvent aussi être stockés pour comparer les résultats dans le temps
  

YSlow a permis de déterminer rapidement le besoin de configurer les modules Apache mod_expires et mod_deflate.
Une fois cette opération faite YSlow a permis de vérifier facilement que les dates d'expiration de cache sont maintenant correctes et que les contenus sont compressés.

En revanche, YSlow est assez général sur les recommandations. La règle a appliquer est présentée de manière très claire mais elle n'est pas appliquée au cas particulier. La conséquence est qu'il faut plus d'effort pour estimer le gain que l'on peut espérer de la correction et donc motiver une correction rapide.

C'est là qu'intervient Page Speed.



Page Speed

Page Speed fourni un état très complet, des propositions de correction et une évaluation du gain. Je ne suis pas vraiment la cible car je ne développe pas les pages sur ce projet. Il m'a tout de même servi pour plusieurs choses :

• Evaluer la minification des JavaScripts : le gain de la minification des JavaScript est de 150Ko par page sur les pages testées et une action pour mettre en place Dojo's ShrinkSafe est "rentable". Or cet outil est disponible mais personne n'a jamais eu le temps d'insérer le script dans le build
• inspecter les headers facilement : Les pages sont en HTTPS et les headers ne sont pas disponibles dans Fiddler. L'onglet resources de Page Speed affiche les headers requête et réponse et le texte ou contenu de chaque resource.
  
• "Smusher" les images : YSlow fournit aussi ce service mais en passant les URLs des images au site smushit.com. Or le site en développement n'est pas accessible depuis Internet. Page Speed génère automatiquement la version "smushée" de chaque image. Cela a permis de traiter rapidement 5 images sur lesquelles il y avait un gain de plus de 1Ko.
  
• Evaluer le CSS : constater que certaines maladresses sur le CSS sont classées "très mauvais" et nécessitent une action.
  

Avant de conclure, quelques conseils tirés de mon expérience YSlow.



Les jeux de règles YSlow

YSlow permet de créer des jeux de règles spécifiques. C'est utile lorsque certaines règles ne sont pas applicables :

• Le support des navigateurs interdit la mise en oeuvre de certaines règles
• L'application n'est pas dans un environnement permettant l'évaluation de la règle. C'est le cas en particulier de la règle "Use a CDN"souvent difficile à vérifier en développement (un CDN est un Content Delivery Network, c'est à dire un service de cache tel qu'Akamaï ou Limelight)

Les jeux de règles sont accessibles via le bouton Edit à côté du nom de règle.

• Une fois définies les règles via les cases à cocher, sauvez le ruleset. Il apparaitra dans les Custom Sets sur la gauche
• Redémarrez Firefox ! : les mises à jour ne sont sauvées qu'au moment de l'arrêt de Firefox. J'ai refait le ruleset 2 ou 3 fois suite à des plantages Firefox ;-)
  

La gestion du cache

YSlow se base sur le comportement de Firefox. Il est important que tous les contenus soient rechargés pour que leur statut soit mis à jour.

C'est particulièrement visible sur les dates de cache :

• Juste après la mise en place des directives pour mod_expires, les données sont affichées à jour. La date est dans plus de 48h et satisfait la règles "Add expire headers".
  
• Le lendemain, la règle est violée car la date d'expiration n'étant pas atteinte Firefox n'a pas rechargé les contenus statiques. Et les contenus en cache sont maintenant valides pour moins de 48h.
• Forcer le rechargement marche dans une certaine mesure, mais n'agit pas sur toutes les ressources. Le plus fiable est de vider le cache pour avoir les fichiers à jour.
  

En conclusion

Les deux outils sont très utiles pour améliorer la qualité des pages Web.

• YSlow s'adresse plutôt aux personnes qui valident l'application et au suivi qualité
  
• Page Speed est plutôt destiné aux développeurs qui vont optimiser les pages.

Posts similaires :

• Velocity 2009
  

Sur Velocity 2009

Enfin des choses qui bougent sur le thème performance ...

La conférence Velocity "Web Performance and Operations Conference" s'est tenue du 22 au 24 juin à San Jose, CA.

On y trouvait des représentants des plus gros sites Web (Facebook, Google, Microsoft, Twitter, Yahoo, etc) réunis pour discuter des problématiques d'exploitation et souvent de performance de leurs sites.

Je n'y étais malheureusement pas mais fort heureusement beaucoup de présentations et même des vidéos de sessions sont en ligne.




Brooks Elliott

Qu'est ce qui ressort ?

Tout d'abord, ces sites sont tous des sites commerciaux, très fréquentés où les performances sont nécessairement un enjeu. D'ailleurs Performance n'a pas toujours le même sens selon les interventions : il peut signifier ROI, expérience de l'utilisateur ou efficacité technique.

D'une manière générale, les participants constatent que dans les applications "Web 2.0"/AJAX les problèmes de performance perçue proviennent pour une bonne part de la restitution dans le navigateur (environ 50% du temps total). La plupart des outils cités sont des outils d'analyse du comportement sur le poste client et d'optimisation du Web design.

Je ne pense pas qu'ils aient ignoré la partie serveur (on voit passer par ci par là des outils plus classiques), mais il existe déjà des outils pour la partie réseau/serveur et le sujet est peu à même de déplacer les foules. Ils sont inclus dans le mantra le mantra "mesurer, mesurer, mesurer, visualiser et analyser les données pour comprendre le problème" que l'on retrouve un peu partout. Juste pour préciser au cas où, mesurer la production.

Bien qu'Agile cela n'apparaisse pas directement, on sent que le développement de la plupart de ces application est Agile (résolutions itératives des problèmes, rythme rapide des mises à jour en particulier). On voit donc l'envers du décor, quand les projets sont livrés pour être exploités et ne marchent pas forcément aussi bien que l'on souhaiterait. Les solutions sont souvent différentes de celles qu'on rencontre dans des secteurs plus classiques. En particulier ce sont plus souvent des solutions mixant l'infrastructure et le développement de l'application (travail sur les caches et les proxies à différent niveaux de l'infrastructure par exemple).




Darren Hester

Mesurer, mesurer, mesurer et comprendre

Tout d'abord une session avec un titre interminable
The User and Business Impact of Server Delays, Additional Bytes, and HTTP Chunking in Web Search de Eric Schurman (Microsoft) et Jake Brutlag (Google) qui présentent les résultats de tests utilisateurs qu'ils ont menés sur leurs moteurs de recherche. C'est intéressant et assez abordable. Prenez le temps de regarder la vidéos car les slides seuls sont assez laconiques.

Ils ont dans les deux cas appliqués la méthodologie A/B Testing (ou Split A/B Testing) utilisée habituellement en marketing pour choisir entre différents designs. L'A/B Testing utilise dans l'arrière boutique des méthodes statistiques de tests d'hypothèses basées sur des comparaisons de séries (variante de test de Khi2 type GTest, ZTest). Il nécessite une infrastructure qui permet de servir différentes versions du site à différents utilisateurs et de collecter les mesures.

La page Wikipedia sur A/B testing est un peu jargon. Vous trouverez sur ces deux pages des explications destinées au marketing plus faciles à appréhender dans le contexte :

• Test AB (AB Testing) (en français)
• An Introduction to A/B Testing (un peu plus détaillée mais en anglais)
• et un exemple chez Google Google Website Optimizer; un service de A/B testing gratuit

En l'occurrence, ils ont soumis les utilisateurs a des versions de site plus ou moins lentes, ou dont les pages ont été refactorées selon diverses techniques pour mesurer l'impact sur l'usage et donc les revenus du site. Les constats sont que les utilisateurs commencent à percevoir l'attente à partir de 500ms mais aussi qu'ils ne sont pas impactés de la même manière selon la façon dont s'affiche la page.

On trouve un peu plus de détails l'utilisation de l'A/B Testing et d'autres moyens utilisés dans la présentation Performance-Based Design - Linking Performance to Business Metrics de Aladdin Nassar (Microsoft - Hotmail) et une moisson de sigles aussi : PBD Performance Based Design, RPI Relative Performance Index, PLT (ah non celui là c'est juste Page Load Time). C'est aussi en vidéo.

Philip Dixon (Shopzilla) dans Shopzilla's Site Redo - You Get What You Measure fait un retour d'expérience sur la refonte complète de leur site. Peu technique mais intéressant quand même pour les problématiques et le vécu. C'est aussi en vidéo.





aussiegall

Les outils

Pas de bon artisan sans de bons outils.
Plusieurs présentations ont été consacrées à des outils d'analyse dans le client :

Performance Tools par Eric Goldsmith (AOL), Simon Perkins (Simtec Limited), Stoyan Stefanov (Yahoo! Inc), Jim Pierson (Microsoft), Jan Odvarko (Freelance). Attention il y a deux présentations attachées :

• Performance Tools Presentation [ZIP] sur Page Test d'AOL
• Performance Tools Presentation 1 [PPTX] sur VRTA de Microsoft

Page Speed par Bryan McQuade (Google), Richard Rabbat (Google, Inc.) sur Google Page Speed.

Jiffy, une extension Firefox pour analyser le temps de réponse dans la partie client par Scott Ruthfield de Rooster Park Consulting.





geishaboy500

Optimiser le Web Design

Maintenant qu'on a compris d'où vient le problème, il faut lui trouver une solution.

Julien Lecomte (Yahoo!) présente dans High-performance Ajax Applications diverses techniques pour améliorer les temps de réponse du JavaScript. Attention c'est très technique et nécessite une bonne connaissance du développement JavaScript.

Si vous n'êtes pas un expert JavaScript vous préfèrerez probablement la présentation plus pédagogique de Douglas Crockford (Yahoo!) Ajax Performance.

Si vous n'en avez pas assez :

• Une autre présentation d'optimisations JavaScript Writing Efficient JavaScript de Nicholas Zakas (Yahoo!),
• ou Steve Souders (Google) présente ses 14 règles et analyse l'impact de plusieurs techniques en JavaScript et CSS dans Website Performance Analysis,
• ou Dave Artz (AOL) The Secret Weapons of the AOL Optimization Team,
• ou Frontend Performance Engineering in Facebook par David Wei (Facebook Inc.), Changhao Jiang (Facebook Inc.).

Go with the Reflow de Lindsey Simon (Google) est une présentation très spécifiquement sur le reflow en Javascript, c'est à dire le repositionnement des objects graphiques dans la page. Ce comportement du navigateur est cause d'un certain nombre de ralentissement dans le client.

Une très belle présentation sur CSS de Nicole Sullivan (Consultant) The Fast and the Fabulous: 9 ways engineering and design come together to make your site slow.

Et pour finir avec le Web design, Stoyan Stefanov (Yahoo!) présente dans Image Optimization: How Many of These 7 Mistakes Are You Making divers outils et techniques qui permettent d'améliorer le poids des images dans les pages Web.





ecstaticist

Rails

La présentation sur Twitter est particulièrement intéressante pour ceux qui s'intéressent à Rails. Fixing Twitter: Improving the Performance and Scalability of the World's Most Popular Micro-blogging Site par John Adams (Twitter) présente l'architecture, le reporting et le process de déploiement mis en place, les techniques de cache mises en oeuvre. C'est aussi en vidéo.





hounddiggity

Deployer

Passons un peu du coté de nos amis (si, si) de la production.

Une présentation très sympa sur les rapports devs/ops de John Allspaw & Paul Hammond (Yahoo!) 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr et la nécessité d'un respect mutuel pour faciliter les déploiements fréquents et rapides.

Pourquoi il ne faut pas compter sur l'administrateur Apache pour vous améliorer tout ça d'un coup de zip : Beyond Gzipping de Tony Gentilcore (Google) montre que la compression des flux n'est pas une panacée car 15% des utilisateurs ont quand même des réponses non compressées. Le problème est dû aux firewalls et proxies qui altèrent les headers HTTP.

Scalable Internet Architectures par Theo Schlossnagle (OmniTI) présente quelques slides intéressants sur les pratiques de cache et de partitionnement/sharding de base de données.

Introduction to Managed Infrastructure with Puppet présente l'outil de configuration management Puppet pour le déploiement d'application distribuées.





Chocolate Tools par JanneM

Les outils cités

J'ai regroupé ici divers outils cités dans ces présentations ou d'autres que je n'ai pas reportées.

JavaScript/DOM

• HttpWatch analyse/profilage poste client, adon IE et Firefox (commercial)
• PageTest analyse/profilage poste client, addon IE (AOL, opensource)
  
• Jiffy analyse/profilage poste client, addon Firefox
  
• Visual Round Trip Analyzer analyse/profilage poste client, add on IE (Microsoft, free)
• Page Speed analyse/profilage/suggestions sur poste client, add-on Firebug (Google, opensource)
  
• YSlow analyse de page Web - addon Firebug (Yahoo!, gratuit)
  
• Firebug analyse/debug poste client - addon Firefox (opensource)
• MSFast analyse/debug addon IE (opensource)
• JSLint.com service en ligne d'analyse de code JavaScript
  
• Cuzillion générateur de pages de test contenant diverses techniques JavaScript
  

Images

• Smush.it service en ligne d'optimisation d'image
• CSS Sprite Generator service en ligne de génération de CSS sprite à partir de plusieurs images dans le but de limiter le nombre de requêtes HTTP
• SpriteMe idem
• d'autres outils en ligne de commande sont cités dans la présentation Image Optimization
  

Réseau / HTTP

• Fiddler analyse/debug http - addon IE (Microsoft, gratuit)
• Charles HTTP proxy (commercial)
  
• nExpert simulation de connexion réseau de différentes qualités (Windows)
  
• WANSim simulation de connexion réseau de différentes qualités (Linux)
  
• HTTP Analyzer sniffer HTTP Windows
• Varnish cache HTTP
  

Surveillance

• NetMon monitoring réseau Windows (commercial)
• Ganglia surveillance de systèmes distribués Linux (opensource)
• KITE service en ligne de mesure de performance sur les postes clients Web et RIA (Keynote, commercial avec un mode gratuit)
  

Configuration Management

• Puppet configuration management (commercial)

J'en ai probablement ratés quelques uns et je n'ai pas systématiquement noté les outils connus (Squid ou Nagios par exemple) ou les outils système)

A suivre ...

Google et Yahoo! ont lancé chacun leur site pour regrouper les initiatives :

• Google Let's make the web faster
• Yahoo! Exceptional Performance