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.

Firefox faisait déjà du préchargement, intelligemment, et ça sera probablement spécifié dans HTML 5. J’en reparlerai plus tard.

Aujourd’hui c’est de DNS que je souhaite parler. Chrome et Firefox 3.5 ont en effet tous deux la bonne idée de précharger les requêtes DNS. Pour les versions plus anciennes de Firefox il existe même une extension. Etonnamment (et malheureusement) ce n’est pas encore dans les brouillons HTML 5 par contre.

Comment ?

Trois types de préchargement sont identifiés :

Tout d’abord le navigateur identifie les liens vers toutes les ressources à charger et tente de résoudre le nom de domaine au plus tôt, en parallèle des autres téléchargements afin que cette résolution soit disponible quand il y en a besoin. Je suppose que l’effet sera ici très restreint car très fréquemment dès qu’un ressource vers un nouveau domaine est identifiée alors le téléchargement est immédiatement lancé. Les seules effets que je vois c’est si vous épuisez la totalité des fils de téléchargements du navigateur, ou si une ressource bloque les files de téléchargement (par exemple un javascript bloquant). Le premier cas ne doit quasiment jamais arriver, sur Firefox il faudrait 30 téléchargements simultanés répartis équitablement sur 5 domaines différents, sur Chrome c’est plus de 60 répartis équitablement sur plus de 10 domaines. Le second cas arrive de moins en moins (chrome 2 et Firefox 3.5 ne bloquent plus les téléchargements sur les javascript).

Le second type de préchargement c’est analyser tous les liens sur lesquels l’utilisateur peut cliquer, pour résoudre par avance le nom de domaine. Il y aura un gain réel dès que vous utilisez un lien entre deux sites distincts, c’est à dire très fréquemment quand même.. L’effet est réduit (on ne gagne que le temps de la résolution DNS) mais il vous fera effectivement gagner du temps.

Le troisième type de préchargement est déclaratif. Le navigateur repère les liens de type <link rel="dns-prefetch" href="//example.org"> et précharge la résolution DNS. Charge à l’auteur de faire les déclarations pertinentes en sachant ce qu’il précharge et pourquoi.

Chrome a en fait un quatrième type de préchargement DNS. Il retient à chaque fois les dix domaines résolus au précédent démarage, et les précharge pour vous immédiatement. Vos deux ou trois premiers clics à l’ouverture du navigateur seront donc magiquement accélérés. C’est peut être aussi ça qui donne l’impression de performance ressentis par certains. Mieux, il précharge les sites proposés dans l’autocomplétion de la barre d’adresse et de recherche. Le temps que vous preniez votre décision, l’option a déjà été préchargée et la page s’affichera d’autant plus rapidement. Là si l’effet lui même n’est pas plus important que les précédents, le ressenti utilisateur est clairement grandement amélioré, on donne une impression de continuité et de réactivité dans tout le navigateur, ce qui est exactement le ressenti exprimé par les utilisateurs de Chrome.

Pour quoi ?

Une résolution DNS c’est couramment entre 30 et 200 ms. Sur des sites américains, c’est assez souvent plus de 100 ms. Ces mécanismes de préchargement peuvent faire gagner la résolution DNS initiale, et donc la latence de la première requête, la plus importante. Pouvoir avancer dans le temps une ou deux résolutions DNS dans la page peut aussi améliorer les choses, mais je crains que là l’effet soit plus restreint. Dans l’ensemble c’est jusqu’à 150 ms qu’on peut gagner. Ce n’est pas grand chose mais ça reste quand même significatif.

Pour d’autres pays le résultat peut être encore plus important. Ainsi Google a ses propres statistiques récoltées avec Chrome où on voit que la moitié de des requêtes DNS des utilisateurs test se font en plus de 100 ms. Là où ça devient vraiment inacceptable c’est de voir que la moyenne est de 217 ms et qu’il y a encore pas loin de 10 % des requêtes qui dépassent la demi seconde. Même si ça arrive rarement, pouvoir gagner cette demi seconde est une victoire incontestable pour le confort utilisateur.

Vie privée et désactivation

Les petits malins auront remarqué qu’avec ce principe, en installant un mouchard dans son serveur DNS et en générant un nom de domaine unique différent à chaque utilisateur on peut traquer l’utilisateur. L’intérêt par rapport à une bête balise image est cependant assez faible. On peut déjà faire la même chose, mais en plus simple.

Si toutefois la chose vous gêne, vous pouvez le désactiver dans vos préférences Firefox (cherchez network.dns.disablePrefetch), ou ajouter une balise meta sur vos pages : <meta http-equiv="x-dns-prefetch-control" content="off">. Mais pourquoi voudriez-vous diminuer l’expérience utilisateur de toutes façons ?

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.

Une mise à jour attendue …

J’avais, comme tout le monde, deux principaux reproches à faire sur l’outil. Tout d’abord il ne vérifie qu’une liste très spécifiques de critères. Ce sont une partie des 14 premiers critères retenus par l’équipe performance de Yahoo! mais depuis d’autres recommandations ont pu être dégagée. Il était nécessaire que l’outil s’étoffe.

C’est donc 10 règles supplémentaires qui sont intégrées dans l’outil, pour un total de 23. Mais là où Yslow aurait pu avoir une simple mise à jour, l’équipe Yahoo! a permis l’arrivée d’un modèle communautaire, où chacun peut ajouter facilement ses propres critères. C’est l’histoire de quelques lignes de javascript dans une extension Firefox.

Le second point contestable était le système de notation. Toutes les règles ne sont pas adaptables à tout le monde, avec la même importance. Le premier exemple c’est la question des ETags qui pénalise des notations pour rien, soit parce que l’ETag n’est pas généré avec le système par défaut d’Apache, soit parce qu’il n’y a qu’un seul serveur web derrière le site. Chacun a ses spécificités et je retiens encore l’exemple qu’on m’a donné des sites chinois qui ont tendance à avoir des pages web longues de plusieurs dizaines d’écran parce les usages locaux font qu’on télécharge la page pour une lecture hors ligne, et qu’on espère donc en avoir le plus possible dedans quitte à attendre longtemps.

Bref, là aussi Yslow est personnalisable et il sera possible de définir vos propres algorithmes de notation, voire de choisir le type de notation souhaité parmi une liste. À vous de définir vos limites, vos paliers, vos pénalités et les règles qui sont pertinentes à votre site … ou plutôt à choisir un algorithme créé par quelqu’un d’autre et adapté à votre cas. L’idée est de non seulement pouvoir modifier ces préférences via une interface mais aussi de pouvoir les exporter automatiquement pour les diffuser à d’autres.

… et efficace …

Bref, c’est une très bonne nouvelle, qui va permettre de voir fleurir des personnalisations de Yslow propre à certains types de sites, aux recommandations internes de votre société, ou simplement adaptées à votre échelle. Je m’abstiens de recopier les images ou le code, vous trouverez tout ça dans la présentation de Stoyan.

Mais on trouve encore d’autres petits outils. Parmi eux des menus pour réindenter le code javascript et faire un passage par JSLint. Là encore, quelques lignes de javascript sont prévues pour rajouter vos propres outils.

Mieux, et ça c’est excellent, il est prévu de sauvegarder votre session de résultat pour une étude plus tard et d’importer de sessions crées par Fiddler ou HttpWatch.

… mais imparfaite

Mais tout n’est pas parfait. Dans les recommandations on trouve la #14 (Make Ajax cacheable). Difficile à dire pour un outil automatisé s’il est normal que tel ou tel appel Ajax soit en cache ou dynamique. Je suis dubitatif sur l’idée d’avoir automatisé cette règle là. Même chose pour la #33 (Components under 25k). La limite de 25k est celle de l’Iphone, mais on a vu que les nouveaux firmware Iphone et Ipod Touch permettent de dépasser allègrement cette limite. Bref, on l’ajoute dans Yslow quand il serait presque venu le temps de la retirer de la liste globale des recommandations.

Il y en a d’autres que j’aurai aimé voir, mais qui doivent être bien plus complexes à automatiser. Par exemple :

• trop de présentation en HTML au lieu de CSS
• code javascript lent
• présence de eval() en javascript
• sélecteurs CSS vraiment mal fait
• événements DOM mutualisables avec de la délégation
• processeur excessivement utilisé lors du rendu
• tableaux html dynamique trop gros ou imbriqués

Ah et … pas de date de sortie ni de version béta publique, pour l’instant. Reste que ces nouvelles sont bonnes.

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.

Je vous invite à relire ce second billet, qui résume assez bien. Si on remet le couvert c’est que Jon Sykes a refait un troisième test tout récemment, avec un graphique assez sympa

Plutôt que les valeurs absolues des performances ce qui est intéressant c’est l’évolution suivant le type de sélecteur utilisé. Safari et Microsoft Internet Explorer sont très dépendant du sélecteur, Firefox un peu moins. Allez voir les graphiques, ça vaut milles lignes d’explication.

Bref, si vous deviez retenir quelque chose :

• Faites attention aux sélecteurs enfant et descendant (mais pas au point de tenter de les éviter) ;
• Tentez d’utiliser des sélecteurs très simples, par exemple juste un nom de classe (mais pas la peine de reprendre vos CSS pour ça) ;
• N’ajoutez pas de hiérarchie de balises en préfixe de vos sélecteurs en pensant aider le navigateur (c’est le contraire qui se passe) ;
• L’impact de tout cela sera  nul sur des pages simples ou même moyennes, cela peut commencer à avoir du sens sur des grosses applications HTML comme on commence à en voir (c’est Dave Hyatt qui le dit, faites lui confiance) ;
• Les navigateurs ne réagissent pas tous pareil vis à vis de la complexité des sélecteur, Firefox semble optimiser ses recherches différemment.

La solution c’est l’arrivée de moteurs JSON natifs dans les navigateurs. Mozilla Firefox l’a prévu (actuellement dans les plans pour la version 3.1). Anthony Ricaud m’a comme a son habitude fait passé des liens WebKit alors voilà : Adam Barth y travaille pour WebKit.

Nul doute qu’Opera suivra les deux premiers s’ils implémentent l’API de la même façon. Il restera Microsoft Internet Explorer, mais pouvoir utiliser l’API native et basculer sur le chargement d’une bibliothèque javascript uniquement si elle n’est pas présente, c’est déjà un gros pas en avant.

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