Modules apache

La présentation débute par des liens vers quelques modules Apache pour automatiser les tâches que je recommande ici régulièrement : concaténation, minimisation, retravail des images.

Pour la concaténation des javascript et css il propose mod_concat dont j’avais brièvement parlé en mars. Il s’agit simplement d’automatiser le processus de concaténation des fichiers javascript et css via un module Apache. Les entêtes de cache utilisées sont celles du fichier le plus récent, vous n’avez rien à gérer, il suffit d’ajouter les noms de fichiers souhaités dans l’URL.

Pour la minimisation nous propose modjsmin, qui est simplement le script de minimisation de Douglas crockford transformé en filtre Apache. Côté images il y a c’est moddims qui redimensionne et découpe les images à la demande avec Image Magick. Si vous vous devez d’utiliser des solutions dynamiques alors ce sont probablement des liens à suivre, mais je continue à penser qu’il vaut mieux traiter ça hors ligne à la publication et pas sur le serveur web.

Les publicités

La seconde partie de la présentation est plus intéressante. Notamment Dave donne sa solution pour le problème persistant de tout intégrateur web : les publicités lentes et bloquantes. Il propose ici de les charger dans une iframe de façons à ce que le contenu de la page générale continue de se charger, puis récupère le DOM et les styles pour les regreffer dans le document principal (ce qui est obligatoire si votre publicité risque d’interagir avec le reste de la page). En pratique il y a quelques écueils quand j’avais essayé, tout dépend donc de ce que vous faites tourner en publicité.

Chargement à la demande

Dave a aussi mis au point un mécanisme que j’aime beaucoup. Il s’agit d’exploiter la différence entre la mesure brute de la performance et le ressenti de performance. L’utilisateur n’a pas besoin d’une page qui se charge vite, il a besoin d’une page qui charge vite ce qu’il a sous les yeux. Seuls 20 % des utilisateurs lisant jusqu’à la fin de la page, il est envisageable de ne charger les composants du bas de page qu’à la demande, quand l’utilisateur passe au dessus. Dave a donc fait un petit outil appelé Sonar pour détecter quand charger quel élément, et faire les ajouts/requêtes nécessaires.

Au delà de Gzip

La première chose à activer sur les serveurs c’est gzip. Il s’agit de compresser tous les contenus texte en provenance du serveur avant de les faire transiter par le réseau. Si vous ne l’avez pas fait, activez gzip sur votre serveur web ! Tony Gentilcore nous parle de 70% de gain en volume de téléchargement. De mon expérience ça donne un peu plus mais même à 70 % c’est indispensable.

Là où Tony amène une information nouvelle, c’est que 15 % des clients ne déclarent pas supporter gzip, hors robots. Il blâme les mauvais proxys et les outils de sécurité privés comme Norton Internet Security, Zone Alarm, McAfee Internet Security, etc. Ces outils sont généralement des plaies, et pas que côté performance, et voilà qu’ils s’autorisent à modifier les entêtes HTTP envoyées par le navigateur. Bref, c’est 15 % des visiteurs qui auront une page non compressée et il va falloir trouver une solution.

Il propose donc de tenter de détecter le support gzip réel du navigateur via une iframe. Le contenu de l’iframe est envoyé zippé, quoi que déclare le navigateur. Si le navigateur décode le contenu, on lui pose un cookie pour retenir qu’il faut lui envoyer le contenu zippé malgré l’absence de l’entête HTTP appropriée.

J’aime bien l’idée de l’autodétection mais attention à ne la mettre en oeuvre que pour ces 15 % de clients mal configurés. Hors de question d’imposer une iframe aux autres.

Ajax à Facebook

La seconde présentation dont je voulais vous parler c’est celle de Facebook. Malheureusement, après avoir tenté plusieurs angles d’approche, je me rend compte que je suis incapable de vous en faire un résumé. Le plus simple est donc de vous laisser aller voir les fichiers ou la vidéo de la présentation. Ils présentent leur démarche pour améliorer les performances, et plus spécifiquement comment ils sont passés à un modèle pur Ajax pour la navigation (le conteneur HTML reste, le contenu est chargé via Ajax).

Je fais l’impasse sur la moitié de la présentation qui fait état de leurs outils de surveillance pour passer à la fin. On y trouve quelques graphiques qui montrent le nombre de pages vues suivant les performances obtenues. Comme Steve Souders le disait dans son résumé, ceux qui ont les moins bonnes performances sont aussi ceux qui visitent le moins de pages.

Comme on me l’a signalé il y a peu (merci Rik), il est possible que leur méthodologie soit aussi en cause (moins on visite de pages, plus la première page, cache vide, aura d’influence dans le calcul et moins bon sera le temps de chargement moyen, la courbe cumule alors un biais du à la mesure en plus de l’effet qu’on cherche à mesurer) mais il est tout de même intéressant de voir que le profil de chaque site est différent. Certains semblent plus dépendants des performances que d’autres.

Un peu de CDN

C’est ensuite Mike Brittain qui nous parle de CDN. Rien de bien nouveau à première vue mais le fichier de la présentation manque cruellement d’une bande sonore ou d’une vidéo, il y a peut être eu bien plus de choses intéressantes à l’oral.

Pour ceux qui n’ont pas travaillé avec un CDN vous y retrouverez tout de même un ou deux schémas explicatifs, et en particulier sur la notion de serveur d’origine pour un CDN (si le CDN n’a pas une ressource, il va la chercher sur vos propres serveurs pour la mettre en cache de son côté par la suite).

La dernière partie aurait elle aussi fortement bénéficiée d’un enregistrement sonore. On y parle de quelque chose qui est très efficace mais difficile à mettre en oeuvre : un squelette de page générique qu’on peut mettre en cache voire servir depuis le CDN et qui reçoit toutes les personnalisations et informations temps réel via des requêtes utilisateurs en javascript. Si vous avez des pages d’accueil lourdes que vous souhaitez mettre en cache, c’est la solution à tester (mais ça demande beaucoup de boulot).

Et du reflow

On va enchaîner avec Lindsey Simon, qui parle de reflow. Nous avons abordé la chose plusieurs fois ici mais je vous recommande de jeter un oeil à la présentation qui est un bon résumé. Il identifie comme problèmes majeurs impactant lors des reflow : le nombre d’éléments, la profondeur de l’arbre DOM, le nombre de sélecteurs CSS, la complexité des sélecteurs CSS, et le type de changement opéré (display block, visibilitiy hidden, etc.)

On y retrouve aussi la recommandation de faire les manipulations DOM lourdes hors de l’arbre général (fragment dom), hors du rendu (display none), hors du flux (position absolue), ou au moins en une fois en changeant les classes HTML plutôt que les attributs de style. On limite alors l’impact et le besoin d’un recalcul de toute la page.

Encore de la pub

Une des présentations que j’attendais c’est celle sur la performance des publicités. La présentation, conjointe avec plein de gens biens, est finalement décevante. On y explique très bien les problèmes, mais il manque les solutions. Il faut avouer que c’était un peu présenté comme un panel d’expert donc l’intéressant est à l’oral. On trouve juste deux liens sur des recommandations de bonnes pratiques.  Ça peut toutefois être bien utile pour donner au moins un guide à vos agences de pub (si vous êtes en position d’imposer quelque chose, ce qui est rarement le cas). Par contre au moins ici il y a un enregistrement vidéo.

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.

Nicholas Zakas, de Yahoo!, propose un bon aperçu pour ceux que ça intéresse dans sa présentation « Writing Efficient javascript » aux conférences Velocity 2009.

Variables locales

Vous y trouverez un rappel sur l’influence de la chaîne de résolution des variables javascript avec un raccourci très significatif : local variable = fast. Le graphique à l’écran 26 est parfait pour expliquer tout ça :

Les fermetures lexicales et les try/catch augmentent d’autant la chaîne de résolution. Les with ajoutent un niveau à chaque accès à une variable et sont eux à éviter.

Globalement utilisez le mot clef var partout, ne laissez pas de variables globales. Quand vous utilisez plus d’une fois une donnée qui n’est pas globale à votre bloc de code, et particulièrement si elle est dans un tableau ou dans un objet, stockez là dans une variable locale pour un accès plus rapide.

Boucles et listes

Plus loin, dans les écrans 60+ Nicholas discute des boucles, avec quelques faits connus mais qu’il convient de rappeler, notamment que les conditions d’arrêt des boucles doivent être le plus simple possible : Si vous itérez dans un tableau, : stockez la taille du tableau dans une variable locale au lieu de tester sa valeur à chaque itération, et évitez for/in, for/each ou les équivalents each des différentes bibliothèques javascript.

C’est particulièrement vrai pour ce qui est retourné par les collections DOM, par exemple ce qui est dans document.images ou document.getElementByTagName(). Il s’agit de collections dynamiques et la recherche est relancée à chaque fois qu’on accède à une propriété de la liste, par exemple si on teste le nombre d’éléments de la liste en condition d’arrêt d’une boucle.

A propos des boucles, je vous conseille aussi ce billet de Greg Reimer de chez Sun. Il y liste différentes manière de faire des boucles en javascript sur un tableau, un tableau épart, et une collection HTML, avec des microbenchmark pour comparer le tout.

Repaint et reflow

Pour rappel le reflow c’est le recalcul de la géométrie et de l’agencement de la page en fonction du formattage de tous les objets présents. Cela arrive quand on manipule le DOM, change les styles, ou récupère des informations de style.

Les solutions à apporter ont toutes été déjà abordées ici mais les voici ensemble et confirmées par Nicholas :

• Faire les manipulations de DOM en dehors du document, par exemple dans un fragment ou en display:none
• Grouper ensemble les modifications de style, majoritairement en changeant la classe HTML au lieu du style directement, ou en utilisant cssText
• Mettre en cache les informations sur l’agencement de la page qu’on récupère via javascript, puis grouper séparément les lectures et les écritures

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.

Tous les problèmes de performance ne sont pas dus au réseau. Le navigateur lui même prend du temps pour réaliser le rendu de la page web, et optimiser cette partie n’est pas inutile. Eric Lawrence et Christian Stockwell avaient fait une présentation aux conférence Velocity 2008 à propos d’Internet Explorer 8 en publiant deux graphiques sur la performance interne au navigateur. Le premier concerne une moyenne du TOP 100 du web. On y voit deux étapes « layout » et « rendering » qui prennent plus de deux tiers du temps, alors que finalement jscript et dom ne représentent pas grand chose. Pouvoir accélérer le rendu ne semble pas inutile. Même dans le cas d’une application très orientée « web 2.0″ donc principalement constituée de javascript, css, layout, rendering et html cumulés représentent un quart du temps passé.

On reprend donc tout ça avec d’un côté Nicole Sullivan qui fait un billet « reflow & repaint« . Elle y répertorie quelques causes de reflow et quelques recommandations simples pour les éviter. On retrouve l’idée des tableaux à taille fixe, l’absence d’expressions CSS pour IE, positionner en absolu les éléments qui bougent, etc. Pour ma part je rajouterai la question des boucles javascript dont j’avais parlé en février dans les questions de rendu (regrouper toutes les lectures de type offsetHeight d’un côté, et toutes les écritures de style / classe de l’autre).

Ensuite il y a la suite des trois vidéos. Le dernier moteur Gecko offre une interface pour intercepter l’événement MozAfterPaint et faire des choses sympa. On voit un bookmarklet pour tester le nombre reflow, un autre qui visualise les « paint », une extension de Firebug pour la même chose, et un profiler XUL qui permet de voir certaines choses de ce type. Pour ne rien gâcher on a même la procédure pour produire soi même les vidéos de reflow.

Enfin, pour ceux que ça intéresse, Mozilla publie une documentation sur les reflow HTML. Opera en parle aussi dans une documentation sur le Javascript efficace.

Le besoin est commun à celui de la plupart des sites important : avoir des statistiques et des mesures réelles venant des utilisateurs. Pour les performances la question est loin d’être évidentes et la plupart des outils dégradent les performances qu’ils sont en train de mesurer.

Mesurer

Dans sa présentation Bill Scott nous propose un tout petit script js, moins de 10ko. Il offre deux fonctionnalités de base : mark() et measure(). La première fonction prend un repère dans le temps, et la seconde mesure le temps passé depuis un repère donné. On peut donc avoir plusieurs mesures par repère, et tout est stocké dans le DOM pour réutilisation plus tard.

Bien entendu on voudra faire une marque à l’exécution du script, tout en haut du <head>. On voudra faire une mesure à la fin du <body>, sur le DOMContentLoaded et sur le onLoad. Probablement, puisque la publicité est souvent le plus gros problème de performance, on voudra faire une marque avant d’insérer la publicité et faire une mesure juste après. Faire une mesure après le contenu principal pourrait aussi être intéressant, de façon à mesurer la partie « importante pour l’utilisateur » quitte à ce que je reste mette plus longtemps à charger.

La seule chose qu’on ne mesure pas c’est le premier aller-retour serveur pour aller chercher la page HTML, et le second pour aller chercher le script Jiffy. Maintenant il ne s’agit pas d’avoir des mesures absolues, qui ne veulent rien dire en soi. Il y aura un décalage par rapport à Yslow mais on pourra avoir d’autres mesures, plus précises, et surtout on pourra mesurer les variations suivant les modifications de la page. C’est finalement ça l’important : pouvoir améliorer les choses, peu importe où on se situe.

Collecter

La seconde partie de Jiffy c’est l’envoi des résultats. Le but de Netflix est en effet la collecte statistiques. Il s’agit donc d’envoyer toutes les mesures faites avec tout ce qu’on peut collecter d’intéressant (version du navigateur, adresse ip, système, identifiant des publicités affichées, page visitée, etc.).

On nous propose d’envoyer les résultats à chaque mesure ou d’envoyer une requête groupée en fin de page. Le tout étant reçu par le serveur web pour alimenter une grosse base de données. Envoyer un résultat à chaque mesure risque de dégrader les performances, d’un autre côté envoyer les résultats en fin de page implique un biais si certains de vos utilisateurs quittent la page avant. Il doit aussi y avoir moyen de stocker ça en cookie pour le recevoir à la requête suivante mais cela implique d’autres biais.

Avec toutes les mesures, des filtres par navigateur, date, url, publicité … on pourra enfin détecter la source des problèmes. Lors des évolutions du site, on aura des mesures réelles sur la réaction des différents navigateurs. Mais on pourra être alerté si la courbe de performance pour une URL, un navigateur, une source géographique ou une publicité se dégrade ou s’améliore. Une publicité ou un partenaire ne respecte pas son SLA à cause des javascript qui appellent des javascript qui appellent des javascript ? on le verra.

Afficher

Avec tout ça, nous avons même droit à une extension firefox qui se branche sur firebug et qui permet de visualiser les statistiques de la page courante.

Google propose donc un codage supplémentaire pour HTTP qui s’appelle SDCH, et qui peut s’ajouter avant gzip ou deflate. Le serveur découpe sa page en paquets, qui peuvent chacun avoir des métadonnées et une expiration explicite. Le tout est stocké dans un dictionnaire du côté du navigateur, un peu comme les cookies actuellement. Quand le navigateur demande une page il envoie les identifiants de paquet qu’il connaît déjà, le serveur peut donc se contenter de compléter ce qui manque. On a donc le même fonctionnement que les Etag du point de vue de la négociation.

Les entêtes HTTP en jeu sont Avail-Dictionnary (l’équivalent de Etag pour SDCH) et X-SDHC (pour déclarer la version et l’implémentation de SDCH utilisée) du côté du navigateur, et X-SDCH-Dictionary du côté du serveur.

Reste que cela implique que la réponse du serveur soit codée suivant une forme bien particulière, non compatible avec les anciens clients HTTP. Google a donc prévu une auto-négociation et la réutilisation de l’entête Accept-Encoding. Grâce à cela, les navigateurs qui le peuvent auront un contenu SDCH puis compressé par gzip, les autres se contenteront du gzip.

Si vous voyez passer un Accept-Encoding: sdch, gzip c’est que votre navigateur supporte ce codage. Si en plus vous voyez une réponse Content-Encoding: sdch, gzip c’est que le serveur a bien compris que vous supportiez SDCH et va utiliser ce codage.

Je n’ai vu aucun mouvement ni aucune volonté de mouvement de la part de Mozilla, en fait depuis la communication de Google l’idée n’a pas l’air d’avoir fait recette où que ce soit. Seul un groupe de discussion, quasi vide, a fait suite à la communication de juin 2008.

Chrome a un premier support de SDCH (non activé par défaut pour la version publique actuelle) mais ça ne changera pas la face du monde. Le point intéressant est toutefois que SDCH est automatiquement intégré à Microsoft Internet Explorer si la Google toolbar est installée. La page d’aide de Google indique comment désactiver tout ça.

Si l’idée peut être intéressante, je suis un peu étonné que Google tente de l’imposer de lui-même sans avoir le support d’au moins un intervenant (Mozilla, Opera, Apple, Microsoft) ou une publication normative officielle de type RFC. La seule chose qui sauve cet unilatéralisme est la présence d’une version dans l’auto-négociation (donc on pourra gérer d’éventuelles évolutions dans les spécifications si jamais tout le monde se met autour de la table pour en rediscuter).

Alors voilà, ils viennent de publier un appel à participation pour l’année prochaine en Californie, juin 2009 exactement. Si vous avez de quoi partager, tentez l’aventure. Dans le cas contraire tentez d’y assister, c’est l’événement le plus pertinent sur le sujet. Pour ma part je tenterai d’y être, tout dépendra de mon employeur.

Entre temps, vous pouvez toujours voir les présentations données en 2008, fichiers et vidéos.