Il est temps pour moi de faire une pause. Je l’espère courte, elle sera peut être longue, vous verrez, et moi aussi.

Je reste focalisé sur le sujet, n’hésitez pas à m’envoyer des liens, je peux toujours vous proposer audits, formations ou accompagnements professionnels sur ces sujets, avec une expertise de pointe, mais l’écriture sur mon temps personnel n’est plus d’actualité à très court terme.

Bonne continuation et merci à tous ceux qui m’ont suivi ici. J’espère vous revoir quand je déciderai de reprendre, que ce soit dans deux semaines ou dans plusieurs mois.

Il reste toutefois à passer une phase d’industrialisation. Lancer Yslow tous les mois à la main n’est pas toujours idéal. Cela implique de reporter des résultats manuellement et du coup de ne le faire que pour un nombre limité de pages. On se retrouve aussi à devoir trier les métriques pour y associer une priorité et ne pas se retrouver à devoir tout faire immédiatement.

Une approche pragmatique voudrait qu’on puisse automatiser Yslow et s’occuper régulièrement des points et des pages les plus prioritaires. C’est ce que vous propose Yslow :

Importer et centraliser les résultats

Tout ce que vous avez à faire c’est modifier deux valeurs de configuration dans votre about:config : extensions.firebug.yslow.beaconUrl et extensions.firebug.yslow.optinBeacon. La première est l’adresse d’un script, et le second est un booléen pour activer la fonctionnalité. Tout ce qui sera mesuré sera alors simplement envoyé à votre script. La suite c’est éventuellement de régler extensions.yslow.autorun pour que yslow soit lancé automatiquement sur toutes les pages qu’il rencontre.

Automatiser la procédure

Il reste que même si les résultats sont collectés automatiquement et centralisés par la suite, on demande encore à un utilisateur de parcourir le site. La prochaine étape c’est de faire tourner un Firefox automatiquement. Firefox accepte quelques paramètres en ligne de commande, le reste peut être fait via greasmonkey ou mozrepl. Il devient tout à fait acceptable de lancer un site à distance, réaliser quelques actions, et obtenir le résultat yslow dans la base de données.

Fonctionner sans fenêtre

On commence à s’approcher de ce que pourrait faire un serveur de test ou de mesure. Pour aller encore plus loin il faudrait se passer des fenêtres Firefox et faire tourner le logiciel hors de tout contexte graphique. Si vous êtes avec un système linux, rien de plus simple avec un petit coup de xvfb.

Au final

Résultats collectés en base, yslow automatique, pilotage à distance, automatisation, fonctionnement sans fenêtre, au final ça a déjà été fait par d’autres, mais ça reste encore artisanal. Pour ceux qui veulent tester, jetez un oeil à Cesium. Il s’agit d’un projet pour faire justement ça, avec un back-office en python. (retours bienvenus, je n’ai pas testé Cesium moi même)

Alors voilà, Charles-Christian Croix nous parle un peu de ce qui a été réalisé sur Voici.fr. La première étape se fait via une configuration des entêtes HTTP de cache de ezPublish puis une configuration de mod_gzip sur Apache, et enfin par une configuration de mod_expires, toujours sur Apache. Il fait de même plus tard sur une installation Dotclear.

On peut regretter l’expiration très courte (une journée) accompagniée d’un must-revalidate, mais je me permet d’insister avec intérêt sur le Cache-Control: public très important dans le cas d’une application PHP. EzPublish utilise très probablement les sessions PHP, qui ajoutent par défaut un Cache-Control: private. il faut donc le corriger.

Dans un autre billet on voit le résultat sur le squid de la gestion du cache des images et de la compression HTTP :

Dans une seconde partie il nous parle de compression d’images. Là aussi les solutions sont connues mais c’est appréciable de voir quelqu’un le mettre en œuvre et en parler ensuite. Sur les PNG il identifie un gain moyen d’un tiers pour le poids des images. C’est plus que conséquent, et ça aura un effet visible et sur le client et sur votre infrastructure. Je me permet juste d’apporter un bémol sur l’utilisation du paramètre -brute de pngcrush, qui est loin d’être le meilleur compromis gain/temps.

Il y a une dizaine de jours j’ai vu l’annonce d’une fonctionnalité qui me semble couler de source. J’avais longtemps pensé que c’était le cas sur tous les navigateurs, et mêmes sur tous les systèmes d’exploitation : donner plus de ressources à l’onglet ou à l’application en cours d’utilisation. Cela semble logique mais ce n’était pas encore le cas.

Jusqu’alors le navigateur gère ses files de téléchargement, premier entré premier sorti, ou presque. Ceux qui ont comme moi l’habitude d’ouvrir des dizaines d’onglets en parallèle connaissent bien le problème. Assez vite le navigateur devient inutilisable car trop de pages sont en chargement. La navigation principale s’en ressent, quand elle n’est pas totalement bloquée.

La solution ? Paul O’Shannessy nous propose une priorisation des onglets et des requêtes réseaux qui en découlent. C’est génial. Ça ne coute rien, ça ne demande pas une amélioration des performances du navigateur réseau, ça n’a quasiment aucun effet négatif, mais c’est une avancée réelle pour l’utilisateur, comme je les aime.

Il est tout à fait possible qu’on voit ça arriver dès Firefox 3.6, rapidement donc. Ça me rappelle leurs précédents travaux sur la performance ressentie. C’est comme ça qu’on fait avancer le web, merci Mozilla.

Paul nous donne quelques détails dans un précédent article. Il s’agit de prioriser l’onglet en cours, puis les onglets en tâche de fond sur la fenêtre en cours ou les onglets en cours sur les fenêtres en tâche de fond, le reste (onglets en tâche de fond sur une fenêtre en tâche de fond) et enfin toutes les fenêtres minimisées.

Pour ceux que ça intéresse une extension est disponible pour tester ça sans attendre l’intégration dans le tronc commun de Firefox.

Un des outils que je regarde c’est pngrewrite. La rumeur voudrait qu’il ne gagne pas grand chose mais qu’il est capable de le faire même après un passage par optipng ou pngcrush. Bref, un petit ajout rapide, juste pour grappiller un peu plus.

Je vais vérifier tout ça là aussi, mais en attendant le code proposé sur le site officiel ne compile pas sur mon linux récent. Pour ceux qui ont le même problème, la distribution gentoo a un patch disponible. Il suffit de le télécharger là où vous aurez décompacté le code source de pngrewrite et de lancer patch -p0 < pngrewrite-1.3.0-gcc44.patch puis de taper l’habituel make.

Voilà, maintenant vous savez.

J’aurai bien fait des paquets Ubuntu pour pngrewrite et pngout mais je ne trouve pas la licence du premier et le second interdit explicitement de reditribuer l’exécutable résultat. Si j’ai le courage je tenterai peut être des paquets « tricheur » qui téléchargent sur Internet lors de leur installation mais ça perd un des intérêts.

Toutefois, une fois dépassé ce stade il faudrait se détacher un peu des chiffres pour parler de performance ressentie et pas toujours de performance mesurée. Parfois peu importe la durée de l’attente si on voit que nous progressons régulièrement et que l’attente n’est pas frustrante en elle même. C’est vrai aux caisses d’un supermarché comme sur une page web.

Les éditeurs de navigateurs l’ont bien compris. Ils jouent sur les indicateurs de chargement et sur l’interface pour donner une impression de vitesse à l’utilisateur. L’impression de vitesse est l’unique chose qui compte pour ce dernier, même si au final ça veut dire que les temps mesurés sont objectivement plus lents.

C’est avec cette idée en tête que je vous propose de lire le document de Mozilla à propos de la performance perçue. On y retrouve certaines techniques à mettre en oeuvre sur les versions actuelles ou futures de Firefox. Le document mériterait une traduction tellement il fourmille d’idées, dont certaines sont lumineuses.  Je vous en retransmet certaines, avec mes commentaires.

Dans les « on reste très classique »

Préchargement de Firefox au démarage de windows : On va _encore_ ralentir l’ouverture de session pour pouvoir avoir une ouverture quasi instantanée de Firefox lors du clic sur l’icone. Le résultat sur le ressenti de performance est évident mais je suis assez mitigé. J’en ai ma claque des sessions qui prennent 5 minutes à s’ouvrir à cause de tout ce qui est chargé dans le systray. Là on déshabille Paul pour habiller Pierre et on donne l’impression à l’utilisateur que c’est la faute de Paul. Je comprend l’effet mais je n’aime pas le principe.

Garder le logiciel ouvert un bref moment après sa fermeture, au cas où l’utilisateur le réouvre juste après : Ca me fait penser à la fermeture de session de mon poste Linux. Il prend en compte mais n’éteint le poste que 60 secondes après la demande (sauf si je confirme ma demande), me laissant la possibilité de changer d’avis. J’aime bien le principe mais normalement l’OS fait une partie du travail en mettant en cache toutes les bibliothèques logicielles. Normalement un second démarage est déjà plus rapide. Si ce n’est pas le cas je préfèrerai qu’ils trouvent pourquoi plutôt que de chercher des astuces (oui, je sais, c’est facile à dire).

Installer un intersticiel (splash screen) : C’est assez dangereux. D’un côté on donne immédiatement un feedback à l’utilisateur, ce qui est très bien pour donner une impression de réactivité et éviter qu’il lance deux fois le navigateur en pensant que ça n’a pas fonctionner (je compatis, ça m’arrive régulièrement), de l’autre on va renforcer l’idée de l’utilisateur qu’il s’agit d’un logiciel long à charger alors que d’autres sont instantanés sans intersticiel.

Dans les « c’est astucieux »

Accélérer l’indicateur de chargement : Ils disent qu’ils le font à chaque version. Un indicateur qui tourne plus rapidement c’est pour l’utilisateur un logiciel qui fonctionne plus rapidement. C’est idiot mais on a tous le même ressenti inconscient. Par contre on va vite arriver à une limite pour ce genre d’astuces.

Avoir une progression non linéaire pour l’indicateur de progression : Faire qu’il avance plus lentement au début (quand l’utilisateur accepte l’attente) et plus rapidement vers la fin (quand il en a marre et a besoin de voir que « ça avance bien »). Dans le même ordre d’idée la suggestion précédente propose de faire accélérer l’indicateur de chargement (celui qui tourne) avec le temps.

Dans la catégorie « ça c’est génial »

Utiliser les composants en cache en attendant de vérifier qu’ils sont toujours frais : J’adore l’idée. Il s’agit d’utiliser les feuilles de styles, les images en cache en parallèle aux requêtes HTTP de revalidation. S’il s’avère que le contenu a changé, alors on mettra la page à jour. On tient là une réelle avancée. Il faudrait peut être toutefois montrer à l’utilisateur que l’image en question est potentiellement temporaire (par exemple la griser légèrement, ou monter le gamma : l’image reste visible mais on voit qu’elle est « en cours »).

Dans le même ordre d’idée on propose, à défaut de réutiliser les images elles-mêmes, de réserver la place dans le rendu en fonction de la taille de l’image qui est en cache. On évite de trop triturer la page, ce qui est une bonne chose, mais là je suis moins enthousiaste. Sur une page ou une connexion lente, ça peut inciter à réserver des places vides pendant longtemps, et déteriorer le ressenti utilisateur au lieu de l’améliorer. Je préfère nettement l’idée d’utiliser l’image elle-même, car l’utilisateur a au moins un contenu utile.

Mieux, on propose même de lancer immédiatement des requêtes vers les scripts et feuilles de styles référencées dans la page en cache en attendant de recevoir la nouvelle page. C’est quelque chose qui peut réduire le chargement de la page de plusieurs centaines de milli-secondes, plus sur les pages HTML vraiment lentes. Je ne sais cependant pas si le rapport bénéfice sur complexité est assez intéressant pour que ce soit implémenté. Il faudrait en effet que ces requêtes aient une basse priorité par rapport aux autres requêtes (histoire qu’on ne précharge pas en priorité des choses qui sont potentiellement inutiles) et que ces requêtes soient annulées dès qu’on sait que la page HTML a changée.

Plus intéressant encore : charger la page à partir du cache en attendant que la nouvelle page soit chargée. L’idée est intéressante mais la réalisation risque d’être difficile. La page en cache fait probablement référence à des composants qui eux ne sont pas en cache (les pubs) ou peut faire des requêtes Ajax. Est-ce pertinent d’occuper le réseau avec cette ancienne page ? Pire, on va aussi occuper le cpu puisque beaucoup de sites ont des pages qui mettent un temps significatif à effectuer le rendu même quand tout est en cache. On risque de ralentir inutilement la machine.

Pourquoi dis-je que c’est encore plus intéressant alors que je détruis l’idée ? parce que j’avais ça sur Safari (si je choisis une des pages proposées au démarage c’est d’abord une image de la page en cache qui se charge le temps que la page réelle arrive) et j’ai ça depuis peu sur gmail (le temps que gmail se charge j’ai une version HTML non clicable des titres des quelques derniers mails de ma boite). Ca a l’air inutile mais ça améliore vraiment l’expérience. On peut se concentrer immédiatement sur la tâche prévue au lieu d’attendre que la page se charge. La performance ressentie c’est finalement surtout ça.

Alors ?

Je laisse les histoire d’indicateurs plus ou moins rapides à d’autres mais je verrai bien les effets suivants (cumulatifs) :

• S’il s’agit d’une page fréquemment visitée (en bookmark ?) charger une image de la page telle qu’elle était la dernière fois en attendant que la page se charge effectivement. Point bonus si les liens restent clicables (mais je n’ai pas besoin des autres interactions avec la page comme le javascript).
• Quand la page arrive, on utilise par défaut immédiatement les précédentes versions des images et feuilles de style en attendant les nouvelles. Les images sont toutefois grisées/blanchies pour bien symboliser l’état « en chargement ».

Notez que cela demande d’augmenter l’espace dédié au cache, et pour les pages ciblées de mettre en cache même ce qu’habituellement on n’y met pas (quitte à identifier que c’est un cache déjà expiré).

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

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.

J’ai annoncé il y a quelques temps que je comptais développer un outil similaire avec un code source ouvert et au moins une version en ligne de commande pour être intégré dans des mécanismes automatisés de publication (plutôt que d’attendre publication pour ensuite corriger image par image). Ca viendra, mais ça prend du temps parce que je veux faire les choses bien. Je compare donc tous les outils que j’ai pu voir pour comparer leurs résultats, avec différentes options. Il faut tenter de prendre un échantillon d’images représentatif, repérer les avantages et les défauts de chaque outil suivant le format mais aussi le type d’image (taille, transparence, nombre de couleurs, etc.) puis faire un choix en fonction du temps de traitement (prendre le plus efficace sur la taille finale n’est pas forcément la meilleure idée). Bref, ça viendra mais ce n’est pas pour demain.

Par contre vous avez désormais punypng. Je n’ai pas vu de code source, il n’y a pas de version en ligne de commande, ça n’accepte pas une URL de page HTML pour en extraire toutes les images (quoi qu’il doit être assez simple d’adapter l’ancienne extension smushit pour cela) mais ils innovent. Ils ont repris l’idée d’optimiser les images contenant des pixels avec une information RGB mais totalement transparents, ils font plus de travail sur les jpeg, et ils tentent d’avoir une interface plus efficace que smushit. C’est déjà ça et c’est bien.