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

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.

Rendu fixe ou dynamique

Les tableaux HTML ont deux modes de rendu. Le premier mode utilise un calcul simple pour déterminer la taille horizontale des différentes cellules. On regarde la taille appliquée à la colonne, ou éventuellement à la première cellule de la colonne. Les cellules fusionnées ou sans taille explicite se répartissent à égalité la place restante. On parle d’un cadre fixe.

Le second mode rendu utilise un algorithme bien plus complexe. Il utilise le contenu de chaque cellule pour décider quelle taille elle prendra. On prend en compte la quantité de contenu, la taille souhaitable pour la cellule, et la taille minimum. L’algorithme est complexe, il nécessite de travailler sur des parties complexes du rendu de chaque cellule, il nécessite de recalculer le rendu complet du tableau dès qu’un contenu change dans une cellule ou au fur et à mesure que le HTML est téléchargé. On parle là d’un cadre automatique, ou dynamique.

Les performances

Vous vous doutez bien que le navigateur ne fait pas le même travail dans les deux cas, et pas avec les mêmes performances. Malheureusement c’est ce second mode de rendu, le dynamique, qui est utilisé par défaut. Utilisez la directive CSS table-layout:fixed et d’un coup votre navigateur sera soulagé.

Vous ne verrez pas la différence pour un petit tableau de chiffres mais si vous utilisez les tableaux pour déterminer l’agencement général de la page, si vous imbriquez des tableaux les uns dans les autres, si vous utilisez de très grands tableaux de données avec des centaines de lignes et colonnes, ou si vous utilisez du contenu complexe dynamique dans vos cellules, vous sentirez peut être la différence de performance.

Je vous détaille le premier ici, les deux autres bénéficieront d’un billet dédié afin de mieux organiser les commentaires.

La syntaxe HTML

On vous dira par endroits que faire du code valide, suivant la norme HTML strictement, permettra d’améliorer les performances, d’améliorer votre référencement, et de faire le café. Ce n’est pas tout à fait vrai, mais un peu quand même (sauf pour le café).

Si vous avez des erreurs de syntaxe à répétition dans votre code, le navigateur va tenter de vous corriger. Suivant les cas il est possible qu’il arrête son rendu progressif et attende la fin du document pour savoir quelle correction appliquer et calculer l’ensemble de la page. Il est aussi possible qu’il tente une correction puis change d’avis quand il reçoit le reste du HTML, provoquant un recalcul du rendu. Dans les deux cas vous avez des problèmes de performance.

C’est d’ailleurs vrai même entre deux pages HTML bien formées : bien que facultatif, fermer toutes vos balises explicitement peut aider le navigateur à faire son travail plus facilement. C’est au point que Microsoft met ça en septième position dans son article Building High Performance HTML Pages (réaliser des pages HTML hautes performances).

Dans la réalité la plupart des serveurs web tournent avec un dérivé d’Unix où la casse est importante. Nous aurons un lien cassé et rien de plus. Par contre la recommandation, elle, est plus que pertinente :

Hésitez entre http://example.org/ et http://example.org/index.html, votre navigateur utilisera deux ressources et deux entrées de cache séparées. Au revoir les requêtes conditionnelles HTTP pour économiser le transit réseau.

Insérez des paramètres inutiles ou changeant dans vos liens avec ?exemple=1 et vous voilà avec encore une ressource différente pour le navigateur alors que ça pointe au même endroit.

Hésitez entre http://example.org/rep/ et http://example.org/rep et c’est encore pire. Non seulement ce sont deux ressources différentes pour le client, mais pour le serveur aussi. Ce dernier va opérer une redirection HTTP complète, et vous allez faire deux requêtes HTTP là où une seule aurait suffit (c’est géré par la directive DirectorySlash pour Apache par exemple). Si vous pointez vers un répertoire ou à la racine d’un site, votre adresse doit toujours se terminer par /.

Pour une même ressource, assurez vous que vous utilisez toujours exactement la même adresse, sans variations.