Il nous reste deux statistiques qui vont encore dans le même sens : Yahoo! affirment que sur leur site auto, ajouter 400ms au chargement de la page fait monter le taux d’abandon de 5 à 9%. Akamaï affirment eux qu’au delà de 4 secondes, le taux d’abandon devient vraiment important.

Encore des chiffres

C’est Artur Bergman qui nous donne encore du grain à moudre dans le dernier slide de sa présentation à l’OSCON. Il a mené une étude à l’aide de Google Analytics pour croiser le taux de rebond et le temps de chargement de la page. Les résultats sont tels que je les attendais : une courbe assez claire, presque une droite, qui confirme que les pages lentes sont de natures à faire fuir les utilisateurs.

Vous voulez faire pareil ? les quelques lignes de javascript sont données dans les commentaires du billet de Steve Souders à ce sujet.

Notez qu’il reste potentiellement un biais sur la statistique : Les utilisateurs qui arrivent sur le site pour la première fois sont ceux qui auront légitimement le plus fort taux de rebond. Or ce sont aussi ceux qui n’ont aucun composant en cache et qui du coup ont le temps de chargement le plus long. Toutefois entre 100ms et 5s il y a une grande étendue, le fait que le graphique soit assez linéaire au lieu d’avoir une explosion du taux de rebond tout à droite tend à accréditer que ce biais n’est pas si important par rapport à l’influence du temps de réponse lui même (voire que peut être, au contraire, une partie du taux de rebond lorsqu’on arrive sur un nouveau site est due justement au fait que la page se charge lentement lors de ce premier accès).

C’est le résumé de Steve Souders qui a été publié récemment. On y retrouve quatre affirmations tirées des conférences. Toutes parlent d’une corrélation importante entre les performances et le trafic ou le business du site web :

Microsoft

Microsoft a trouvé qu’un ralentissement de deux secondes implique une réduction 1,8 % du nombre de recherches par utilisateur. Cela semble peu, mais c’est accompagné aussi d’une réduction de 4,3 % du revenu par utilisateur, et là ça fait moins rire. Autrement formulé : un utilisateur clique moins sur les publicités d’un site lent que sur les publicités d’un site rapide.

Ça rejoint d’ailleurs Google qui prend en compte la performance dans son « quality score » pour adword (en gros un site lent paiera plus cher ses publicités parce que le pourcentage de clic est plus faible) et c’est finalement logique, on hésitera à partir ailleurs et à se laisser tenter si on remet pas en cause une longue et pénible session de navigation qui nous a permis d’arriver jusqu’à la page en cours. Si la navigation est rapide on hésitera moins à partir dans diverses directions pour revenir ensuite.

Avis aux sites qui se rémunèrent sur la pub, et aux agences de comm qui font des publicités ultra lentes sous prétexte d’avoir une meilleur qualité d’image.

Google

Google lui a affirmé que 400 ms diminuait de 0,59 % le nombre de recherches par utilisateur. Là je suis un peu étonné parce que finalement ce n’est pas très significatif (sauf à ralentir de plusieurs secondes, et encore) et parce que leur dernière communication à ce sujet était d’un tout autre ordre de grandeur. Ils refont d’ailleurs état de chiffres bien plus importants dans une autre conférence dans le même événement. J’attends donc de lire leur communication complètement pour juger de ce que cela implique et de comment comprendre leurs différents chiffres qui ne semblent pas dire la même chose.

Par contre Google fait état d’un fait d’importance : les utilisateurs qui ont subit ce ralentissement minime de 400 ms continuent de faire moins de recherche sur le long terme même après que ce ralentissement soit supprimé. En gros vos performances actuelles vous impactent non seulement maintenant mais aussi dans le futur. Le chiffre avancé parait faible mais il a beaucoup d’implications et le contexte de Google est très particulier, j’y reviendrai donc certainement dans un billet dédié.

AOL

Sur le réseau AOL les 10 % d’utilisateurs qui ont les meilleures performances visitent moitié plus de page par session que les 10 % avec les moins bonnes performances.

Autant dire que cela a un impact sur le trafic des sites, et donc forcément la conversion en clic publicitaires ou en achats. Le chiffre est important mais il peut revêtir plusieurs formes, je vous en dirai plus quand j’aurai là aussi lu leur présentation à tête reposée.

Shopzilla

Enfin, Shopzilla a réduit le temps de chargement de 7 secondes à 2 secondes. C’est une différence importante et ça a donc du nécessiter des efforts conséquents, mais le résultat est là : 25 % d’augmentation de trafic, 7 à 12 % d’augmentation sur les revenus, et 50 % de réduction sur les coûts matériels.

À défaut d’être une formule magique, investir dans l’amélioration de la performance *doit* être considéré après lecture de ces chiffres. Payer une étude quelques milliers d’euros et un développeur interne pendant quelques jours/semaines pour corriger ce qui a été trouvé, cela peut assez facilement se révéler un investissement payant à court terme.

Google Page Speed y fait référence mais si vous voulez être convaincus il faut aller voir la présentation de Steve Souders aux conférences Velocity 2009. À l’écran 75 on trouve un graphique qui vérifie la corrélation entre le nombre de règles CSS, le nombre de sélecteurs complexes, et le temps nécessaire au reflow.

Il y a trop de choses en jeu pour tirer des conclusions fermes, mais une corrélation est des plus probable. Bref, écrémez vos CSS et simplifiez vos sélecteurs. Si en plus vous limitez le nombre de noeuds DOM et la profondeur moyenne, vous toucherez probablement le jackpot en terme de performance de rendu.

Pour vous aider Google Page Speed permet de repérer les sélecteurs potentiellement les plus coûteux, et ceux qui ne servent à rien dans la page en cours.

Suite à plusieurs de ces publications à propos des sprites CSS, il est temps de faire ici un petit complément sur le sujet.

Sprite Me

Le premier lien c’est SpriteMe, un bookmarklet qui permet de repérer les images les plus pertinentes à grouper ensemble dans un sprite. L’outil regarde toutes les images de background dans la CSS, les groupe par alignement et taille. Plus tard il est prévu qu’il génère le sprite associé puis mette à jour la CSS.

Je reste assez septique sur ces deux dernières étapes. C’est réalisable, sans aucun doute, mais pas forcément pertinent. On risque d’associer des images qui ne sont qu’occasionnellement dans le même contexte, ou des couleurs trop différentes, des alignements difficiles à faire parce que telle ou telle image a besoin d’une grande marge, etc.

La décision et la réalisation doivent probablement rester des étapes manuelles, mais l’aide à la décision ne peut être qu’une bonne chose.

Trop c’est trop

Le second lien c’est Vladimir Vukićević de Mozilla qui rappelle les problèmes inhérents à une mauvaise réalisation des sprites.

Sur le réseau on fait transiter des images compressées, aussi seul le poids du fichier et le nombre de requêtes HTTP comptent. Les sprites sont une grande avancée. Toutefois, le navigateur utilise lui l’image décompressée en mémoire. Sur des tailles démeusurées, la mémoire se retrouve encombrée par un simple sprite. Sur un exemple réel, Vladimir parle d’un sprite de 75Mo en mémoire (1299×15000 pixels).

Donc voilà, un rappel n’est jamais mauvais et j’avais déjà abordé ici la problématique à propos des terminaux mobiles, le sprite est globalement une bonne chose mais il vaut mieux rester mesuré : gardez la taille réelle de l’image en tête.

Le plus simple pour éviter les excès c’est de grouper ensemble des images de taille similaire et d’alignement identique. Pas d’icône 16×16 liée à des bandeaux 2000×24 pour éviter de perdre 1984px de largeur. De toutes façons, rappelez-vous qu’au delà de 2000 pixels, un bug du navigateur Opera risque de vous mettre des bâtons dans les roues.

Ne pas jeter le bébé avec l’eau du bain

La solution c’est le pipelining HTTP, qui ne semble jamais venir. Le commentaire de Rob Sayre de Mozilla à ce sujet (« en théorie, ahahaha ») veut tout dire. Les autres possibilités ce sont les conteneurs jar de mozilla, ou les réponses mime/multipart, de Mozilla aussi.

Mais voilà, pour l’instant c’est la seule technique viable que nous ayons, et elle fonctionne. En restant correct sur les tailles, le gain côté réseau dépasse largement le petit effet négatif sur la mémoire. N’oubliez pas, même sur les terminaux mobiles, c’est le réseau qui reste le plus gros goulet d’étranglement.

Bref, faites juste attention aux tailles des images décompressées.

Je ne l’avais pas caché, je n’ai pas aimé l’organisation du premier livre, High Performance Web Sites. Il s’agissait plus d’un empilement de découverte qu’une documentation pour celui qui veut apprendre et comprendre.

Ce second livre est en fait comme un complément au premier. Ce sont 14 nouveaux sujets qui sont abordés qui viennent s’ajouter aux 14 sujets précédents. Chaque sujet est mieux organisé et plus orienté pratique que ceux du premier livre, mais il manque toujours cette cohérence qui lierait les chapitres ensembles et qui permettrait au lecteur de suivre un cheminement.

Au menu nous avons donc 7 chapitres sur javascript, 5 chapitres sur le réseau, et 2 sur le navigateur :

1. Understanding Ajax Performance
2. Creating Responsive Web Applications
3. Splitting the Initial Payload
4. Loading Scripts Without Blocking
5. Coupling Asynchronous Scripts
6. Positionning Inline Scripts
7. Writing Efficient Javascript
8. Scaling with Comet
9. Going Beyond Gzipping
10. Optimizing Images
11. Sharding Dominant Domains
12. Flushing the Document Early
13. Using Iframes Sparingly
14. simplifying CSS Selectors

Tous ces chapitres ne sont pas de Steve Souders. Il s’agit en fait plus d’un receuil d’interventions d’experts puisque que ce sont 8 auteurs qui participent sur 6 chapitres. On y voit entre autres Douglas Crokford, Nicole Sullivan et Stoyan Stefanov.

Au cours des prochaines semaines je tenterai un commentaire chapitre par chapitre. Vous aurez l’occasion de voir si l’achat vous intéresse. Pour ma part après une première lecture je ne sais pas si vraiment je le conseille.Il n’est pas adapté à quelqu’un qui découvre le sujet (il manque beaucoup de vue d’ensemble), ni à quelqu’un qui lit déjà tout ce qu’il trouve sur le web à propos de performance (rien à apprendre de nouveau), et non plus à celui qui cherche des solutions rapides et applicables immédiatement sans se prendre la tête (yslow ou google page speed sont bien plus intéressant).

Il intéressera par contre les curieux, ceux qui veulent toujours en savoir plus ou qui veulent tout comprendre. Pour les autres (mais pour ceux là aussi), je propose de patienter encore quelques mois, et je vous proposerai un autre livre, en français.

Voilà donc Page Speed, en gros un Gslow avec quelques règles en plus et une ergonomie différente. On y trouve les même préconisations, avec un système de vérification automatique similaire.

Les mieux

• Vérification automatique de la compression des images (un petit équivalent smushit bienvenu), avec mise à disposition des fichiers recompressés
• Pourcentage d’utilisation du contenu des CSS, avec la liste des sélecteurs non utilisés dans la page
• Une règle pour inciter à préciser les dimensions des images pour éviter d’avoir à refaire plusieurs reflow dans la page
• Identification des sélecteurs CSS inefficaces (mais ils ont l’air un peu trop radical là dessus pour moi)
• Minification des javascripts (on vous propose la version minifiée pour remplacer la votre)
• Proposition pour retarder le chargement de javascript

Clairement il y a du bon. Mais surtout il y a un nouvel outil pour tracer le graphique en cascade des téléchargements. Celui de Page Speed propose tout ce qu’à Firebug 1.4 (DNS, connexion, queue, attente, téléchargement) mais on y ajoute les ressources prises depuis le cache (cache hit), une couleur spécifique à l’envoi de la requête (différente de l’attente de la réponse) et deux couleurs pour le temps d’analyse et le temps d’exécution des javascript. On a là le graphique en cascade le plus complet parmis tous les outils que j’ai vu jusqu’à présent. Ce sera un plaisir de travailler dessus.

Et le moins bon

Au niveau du mauvais il manque certaines règles et fonctions par rapport à Yslow2 :

• L’utilisation d’un CDN
• Présence de 404
• Présence d’AlphaImageLoader
• Redimensionnement des images dans le navigateur
• Règle spécifique au favicon
• Externalisation des composants
• Des notes plus précises

Des notes plus précises ça peut paraître inutile (Page Speed n’a que les catégories : bon, mauvais, moyen et informatif) mais c’est indispensable quand on ne travaille pas seul, ou quand la direction souhaite avoir un aperçu de l’avancement. Quand bien même une note sur 100 n’est pas extraordinairement pertinente, elle montre un avancement, permet de prioritiser les efforts entre plusieurs sites. Même la note Yslow de A à F est importante pour cela. Page Speed demande de compter les points en rouge et les points en vert pour se faire une idée, sans savoir lesquels sont vraiment importants et lesquels non. Bref, c’est un manque sérieux pour une réelle exploitation en entreprise.

Ouverture et extensibilité

Mais surtout il manque l’extensibilité de Yslow2. Implémenter les quelques règles supplémentaires de Google Page Speed dans Yslow 2 doit être faisable en une semaine de travail au plus, seul le graphique en cascade représente un réel développement non reprenable.

Et du coup c’est un peu décevant. Je suis un éternel idéaliste mais un tel outil est compréhensible au début. Google Page Speed arrive en dernier, après plusieurs autres outils. Il aurait été agréable de soit étendre l’existant (mais je suppose que la rivalité Google/Yahoo! a pris le pas sur les belles paroles d’ouverture et de « on veut aider les gens ») au au moins de prévoir d’être soi-même extensible (vu que Yslow 2 l’est).

Heureusement le code lui-même est sous licence libre (ceci est un appel du pied à Stoyan Stefanov à propos de Smushit), mais c’est tout de même dommage qu’ils aient loupé le coche de l’ouverture.

Compatibilité

Seconde note : La compatibilité avec Firefox 3.5 ou Firebug 1.4 est pour l’instant assez mauvaise, je ne sais pas lequel des deux est le coupable, mais testez sur un Firefox 3.0 avec Firebug 1.3 pour pouvoir tout utiliser. C’est dommage d’ailleurs parce que vu ce que m’apportent Firefox 3.5 et Firebug 1.4 au jour le jour, quand bien même ils sont en version de développement, je n’aime pas avoir à choisir entre eux et un autre bon outil.

Oui mais, mieux ou moins bien ?

Là il va falloir attendre. Je n’ai pas pu résister à publier un premier de billet de présentation. C’est un peu d’excitation mais aussi que sinon on va m’envoyer des liens vers Page Speed jusqu’à ce que je publie quelque chose. Pour la réelle analyse, savoir si les règles mises en place sont pertinentes (est-ce que regarder la complexité des sélecteurs CSS est une bonne chose ?), si les réglages fins sont corrects (si oui, qu’est-ce qu’on considère comme un sélecteur CSS complexe ?), il va falloir un bon mois de retour d’expérience. À dans un mois donc…

La question peut-être posée autrement : n’est-on pas en train de compenser les défauts des navigateurs dans quelques millions de sites avec des résultats discutables au lieu de fixer les quelques navigateurs ?

Sus au navigateur !

Ma première réponse habituelle est de dire que si, nous sommes, pour bonne partie, en train de compenser les manques et les défauts de nos navigateurs. C’est le cas quand on parle d’agréger les contenus (au lieu d’utiliser le HTTP pipelining), quand on parle de déplacer les javascript en fin de document (au lieu de laisser le navigateur les télécharger en parallèle) ou quand on parle de séparer les contenus statiques sur plusieurs domaines (pour exploiter au mieux la configuration de nos navigateurs).

Vive le navigateur !

Heureusement il y a beaucoup d’activité actuellement chez les éditeurs logiciels. Opera, Apple/Webkit, Mozilla et même Microsoft font des efforts. La génération qui arrive va avoir des navigateurs avec beaucoup moins de goulots d’étranglement côté performances, et un ressenti de vitesse non atteint jusque là : Les javascript vont enfin pouvoir se télécharger en parallèle et ne plus bloquer le rendu, on ouvre plus de requêtes simultanées par serveur, et on tente quelques optimisations.

C’est Steve Souders qui nous propose un petit tableau récapitulatif sur les possibilités de cette nouvelle génération de navigateurs (que John Resig commente). Tout n’est pas parfait mais vous noterez intuitivement une bonne dose de vert pour Microsoft Internet Explorer 8, Minefield 3.1 (qui est la version de Firefox en développement), et WebKit 4. Les cases faisant la différence entre ces trois là sont liées aux redirections et au prechargement, ce sont certainement les colonnes les moins importantes de la grille. Opera reste de côté tant qu’il ne permet pas de paralléliser les scripts, mais il y a tout lieu de penser que cela va s’arranger.

Agissons maintenant

Tout va bien, arrêtons tout parce que ça va être corrigé sur les navigateurs ? Surtout pas ! Tout simplement parce que vos utilisateurs et votre site ne peuvent pas attendre les multiples années nécessaires à ce que le parc des navigateurs soit mis à jour.

Bref, nous n’avons pas le choix. Le visiteur se moque de savoir que c’est la faute du navigateur, qu’un plus récent est en préparation, ou même qu’un plus récent est disponible en téléchargement. Lui voit que votre site est lent, agaçant, et peut être qu’en allant chez le concurrent ça sera mieux – à navigateur égal.

En attendant que toutes les versions actuelles des navigateurs soient remplacées, vous devez agir, quitte à agir en pompier pour corriger les défaillances de ces derniers.

Surtout que c’est un peu notre faute

Mais n’oubliez pas, derrière cette grille il y a encore beaucoup de choses qui sont de la responsabilité de l’intégrateur web ou de l’administrateur web. Je parle de cache, d’agrégation de contenu, de compression http, d’images en sprites, d’optimisations javascript, ou simplement d’ordonnancement des composants.

Ne croyez pas que même avec ces superbes moteurs de navigateur qui arrivent, la performance deviendra un sujet obsolète.

Il n’y a que deux ressources assez complètes qui permettent de couvrir l’ensemble des recommandations sans faire des mois de recherche : Le site de l’équipe performance de YDN et le livre de Steve Souders. Le premier n’explique pas en détail le pourquoi et le comment des recommandations. Le second, bien qu’intéressant et pionnier sur le sujet, est incomplet et pas si bien fait que cela (on peut être excellent en technique mais moins bon en écriture et formation, cela ne retire donc rien à ce qu’on doit à Steve Souders sur le sujet). Les deux sont en anglais.

J’ai donc dans les cartons un livre sur les performances web.Quelque chose de complet, qui va en profondeur, et qui explique tout de A à Z sans préjuger de vos connaissances techniques.

C’est un boulot énorme, probablement bien plus grand que ce que vous imaginez. L’expérience de PHP 5 avancé me fait dire qu’il y a encore longtemps avant que vous puissiez l’acheter. Entre temps ce blog me permet de publier au fil de l’eau ce que je découvre et ce que je pense, pour collecter les réactions et les commentaires. C’est en fait la raison d’être de ce blog.

Mais cela ne suffira pas. Il me faudra des gens pour relire le livre au fur et à mesure de son écriture. Pour commenter, pointer les manques, corriger les fautes, parfaire l’organisation des idées. C’est là que j’ai besoin de vous. Alors voilà, si ça vous intéresse, envoyez-moi un mail avec [livre perf] dans le sujet. Dites moi quelles sont vos connaissances, le temps que vous êtes prêts à investir, et quels sont vos points forts, que ce soit au niveau technique ou au niveau rédactionnel.

Je choisirai certains d’entre vous, probablement des gens que je connais, mais pas uniquement. Il me faut des gens très compétents sur le sujet, mais aussi des débutants. Les retours sont en effet à faire autant sur le fond que sur la forme. Je ne pourrai pas retenir tout le monde ceci dit, donc ne vous vexez pas si cela n’a pas de suite, même si je vous connais bien.

Mais ne vous trompez pas : C’est aussi un travail qui prend du temps : relire, commenter, corriger, faire des allers et retours. Je ne vous demande pas une heure par jour ni même d’engagement, mais ne vous proposez que si vous êtes prêts à investir un minimum de temps. De toutes façons ceux qui suivront l’aventure sont ceux qui me feront de bons retours donc si c’est uniquement pour lire à l’oeil vous seriez déçus. Si vous n’avez pas le temps, les commentaires de ce blog vous sont toujours ouverts.

Oh, et il n’y a malheureusement rien à gagner si ce n’est un remerciement en début de livre, et un exemplaire gratuit si mon éditeur y consent. Écrire ne rend pas riche (et j’en suis le premier déçu, croyez moi). Par contre vous y gagnerez avec des échanges que nous feront sur le sujet, au gré des chapitres et des retours. Et puis il y a la satisfaction personnelle, c’est elle qui doit être votre moteur si vous souhaitez tenter l’aventure.

À vous de voir, si vous êtes tentés, ma boite mail vous est ouverte.

La bonne nouvelle c’est que le programme est en ligne et que les supports de projection sont diffusés en ligne. Les trois premiers fichiers sont déjà publiés. Certes les supports projetés ça ne fait pas l’intégralité d’un cours mais vous suivrez les problématiques abordées, les noms des outils, et les tous les points importants. Pour ceux qui ne savent pas où commencer, c’est une très bonne piste à suivre.

La situation de base : Firefox bloque tous les nouveaux téléchargements quand il récupère une feuille de style. Une fois n’est pas coutume c’est Internet Explorer qui est le plus efficace, car il permet de paralléliser tous ces téléchargements.

Enfin presque.C’est là qu’est la découverte pour moi : Si un javascript en ligne est situé en dessous de la feuille de style, alors Internet Explorer imite le mauvais comportement de Firefox et bloque les téléchargements le temps de récupérer la feuille de style entièrement (à tester sur Cuzillon).

Dommage non ?

La solution simple est de remettre votre javascript en ligne au dessus de la feuille de style, ou de le mettre dans un fichier externe avec une des techniques de chargement vues précédemment.