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.

Le navigateur le plus rapide au monde !

On apprend ainsi que Firefox 3 est le navigateur le plus rapide au monde ! En France c’est bien sûr Tristan Nitot qui relaie l’annonce en prenant pour base un billet du blog ZDNet qui compare javascript.  

Il s’agit en fait des résultats d’un test de performance Javascript. Le test lui même, SunSpider, est publié par Apple via le projet webkit. Firefox 3.0rc1 y arrive effectivement en premier, à peu près à même niveau que Safari 3.1. Globalement les autres navigateurs en développement ou récents sont deux à trois fois plus lents (IE 8, Opera 9.2 & 9.5b, Safari 3.0). Firefox 2 est même quatre à cinq fois plus lent, Internet Explorer 7 est presque dix fois plus lent.

Versions de développements

On fait valoir que le gain de Firefox 2 à Firefox 3 est très important pour les utilisations de tous les jours, mais dans la communication de nombreux sites ce qui transparaît que c’est parce que Firefox 3 est le plus rapide au monde. On oublie qu’en fait c’est Firefox 2 qui est étonnamment lent par rapport à tous les autres (Internet Explorer 7 mis à part).

Pire, de mon point de vue : on met en valeur Firefox 3 en … faisant la comparaison avec Internet Explorer 7. Firefox 3 est en version de développement, pourquoi ne pas alors être honnête et comparer avec la version de développement d’Internet Explorer ? la beta 1 est dans le graphique, et si la différence de performance reste importante en valeur absolue, elle n’a plus du tout le même impact pour l’utilisateur final. Internet Explorer 8b1 étant tout de même deux fois plus rapide sur ce test que Firefox 2 (et plus rapide que Firefox 3.0b1 si on veut prendre le même niveau d’évolution)

Du coup je ne peux de plus que m’étonner de l’absence des versions de développement Safari. Les versions de développement des autres navigateurs y sont et l’équipe webkit nous parle en permanence de grandes avancées à propos de Javascript et Squirrelfish. Ah, visiblement sur le même test les versions de développement de Safari avec le nouveau moteur javascript SquirrelFish est quatre fois plus efficace que le Safari 3.0, soit presque 2 fois plus rapide que Safari 3.1 et encore 50%  rapide que le navigateur le plus rapide au monde (je parle de Firefox 3.0rc1 si vous me suivez bien).

Des chiffres triés

Alors en remettant dans le bon contexte :

• Dans les navigateurs en version de développement c’est Safari qui mène la danse, Firefox est derrière (50% plus lent), puis Opera 9.50b2 (3x plus lent) et enfin Internet Explorer 8b1 (4x plus lent).
• Dans les navigateurs en version stable, c’est encore Safari 3.1 qui mène la danse, puis Opera 9.26 (2x plus lent), Firefox 2.0 (4x plus lent) et enfin Internet Explorer 7 (8x plus lent).

Firefox navigateur le plus rapide au monde peut laisser le trophée à Safari, en tout cas sur ce test javascript. Le futur Firefox est même à peine plus performant que l’actuel Safari. On peut aussi voir que tous les navigateurs ont bien amélioré leurs performance, environ d’un rapport 4. Firefox ne fait donc pas exception. Seul Opera a fait moins d’avancées, mais à sa décharge il n’était pas mal placé et reste à des performances honorables.

La seule chose que je remarque dans le graphique ce n’est pas la performance de Firefox 3, s’est les extraordinaires contre-performances de Firefox 2 et Internet Explorer 7 (même si ça fait mal de voir les deux associés quand on parle de performance). Et la chose qui me manque dans le graphique c’est le futur Safari, qui fait une différence extraordinaire avec tous les autres.

Vendeurs de lessive

Je ne peux m’empêcher de regretter ces arguments de vendeurs de lessives. Mon futur navigateur en développement est le plus rapide au monde, à condition de ne pas compter ceux des autres. Ces avancées de performances sont un vrai bonus pour l’utilisateur, il ne s’agit pas de ça. Mais la communication est tronquée et de toutes façons peu aidante pour l’utilisateur.

Certes, Firefox 3 est proche d’une version finale donc il sera effectivement pendant quelques temps le navigateur le plus rapide au monde, mais je doute que ce soit ça l’important aux yeux de l’utilisateur, surtout sachant que les version de développement de Safari font déjà tourner le même code 50% plus vite.

Il fut un temps où le projet Mozilla était présenté comme une démo ou un prototype technologique. Je ne me rappelle plus exactement les termes mais l’esprit est bien celui là. Depuis l’arrivée de Firefox on a une communication qui devient « marketing produit » et qui ressemble à celle d’un vendeur de lessive (celle qui lave plus blanc que blanc). C’est dommage, surtout quand on voit que Safari/webkit, eux, arrive à concilier l’impératif d’avoir une communication promotionnelle par Apple/Safari et continue à avoir des publication relativement objectives et honnêtes sur les sujets techniques via webkit.

Le fond

Je n’ai pu m’empêcher de pousser un petit coup de gueule contre cette dérive marketing mais le fond n’est pas là. Le fond, l’important, il se retrouve aussi dans le billet de Tristan Nitot : Ces gains, quel que soit le navigateur, sont des gains très importants pour l’utilisateur. Là où vous attendiez un résultat, vous ne ferez que percevoir qu’il y a un délai. Là où vous perceviez un délai non gênant, vous aurez l’impression d’instantané. Un facteur 4 ou 5 c’est la différence entre lent et rapide, entre une application frustrante et une application agréable.

Préparez-vous à de grands changements de ce point de vue. Je regrette juste que les développeurs web et les éditeurs de sites web ne se soient pas encore rendus compte de l’importance des performances. Il y a en effet encore du boulot à faire du côté des sites eux-même, et pas qu’un peu.

Pour l’utilisateur ça peut être une révolution, et les éditeurs de navigateurs, eux, ne s’y trompent pas. Les performances sont devenus un argument promotionnel important. Malheureusement pour nous ça veut dire qu’il va falloir vérifier et douter de toutes les communications sur le sujet, qui seront encore moins objectives, honnêtes et exhaustives.

Concrêtement

Si on considère que nos douze ressources sont téléchargées par un seul fil d’exécution (ou que vous avez 24 ressources, donc deux fils à 12), vous épargnez 11 aller-retour. Dans notre exemple c’est 440 ms qui sont gagnées avec tout ça.

Le seul défaut du pipelining est qu’il faut bien le régler dans le navigateur. Il peut devenir contre-performant dans un seul cas : si le navigateur enchaîne ses requêtes sur une seule connexion alors qu’il aurait pu les balancer sur plusieurs connexions simultanées. Il faut juste s’assurer que le navigateur préfère utiliser au maximum ses connexions multiples avant d’enchaîner les requêtes.

Le support

Le pipelining une fonctionnalité prévue par HTTP 1.1 (protocole que maintenant quasiment tous les serveurs web et proxys affirment implémenter). L’activer est un gain important pour le client, avec très peu de contre-coups pour le serveur. 

Le problème ne vient alors pas vraiment d’un équilibre entre les performances clients et les performances serveurs, mais simplement de la capacité du serveur à enchaîner les requêtes. Il semblerait que certains serveurs supportent mal ou pas du tout cette possibilité, et entraînent des résultats incohérents : IIS par exemple.

C’est en tout cas pour cette raison que Firefox désactive le pipelining par défaut (mais documente la fonctionnalité). Le fait est que Opera utilise le pipelining depuis longtemps, et que cela n’a pas l’air de déranger ses utilisateurs ou de « casser le web ». IIS peut être détecté assez facilement et le reste du Web n’a pas l’air de poser un problème tel à Opera que cela justifie la désactivation pour Firefox.

Jouer avec firefox

Si vous voulez jouer avec Firefox, vous pouvez tout de même activer le pipelining via network.http.pipelining, network.http.proxy.pipelining, et network.http.pipelining.maxrequests. Les deux premiers sont des booléens, pour activer le pipelining. Le second est un nombre maximum de requêtes à mettre dans la pile, 4 est un bon défaut (Firefox n’accepte pas une valeur plus grande que 8, et de toutes façons elle n’aurai aucune utilité). 

Bien entendu, le pipelining n’est disponible que sur HTTP 1.1, et si les connexions persitantes sont activées (dans le navigateur comme sur le serveur).