Avec ces statistiques la recommandation était de répartir les téléchargements sur deux domaines, quatre maximum. On arrive donc à 4 ou 8 requêtes simultanées. Plus consomme inutilement du processeur et provoque un surplus inutile de requêtes DNS.

Ces différents domaines peuvent être des sous domaines ou pas, peuvent ou pas être des sites virtuels qui mènent en réalité à au même serveur physique, voire au même contenu. L’important est que le navigateur voit des URLs au domaine différent. Par contre ne faites jamais des liens aléatoirement vers un domaine ou un autre, vous perdriez tout le bénéfice du cache entre deux visite car les URLs changeraient à chaque fois.

Une évolution des navigateurs

Depuis deux ans le parc des navigateurs a évolué. Internet Explorer 8 fait une percée non négligeable. Les utilisateurs de Firefox utilisent quasiment tous la version 3 et représentent maintenant une proportion importante du trafic. Safari et Chrome font plus parler d’eux. On passe de 2 à 4 (Safari), 6 (Firefox 3, Internet Explorer 8, Chrome) voire 9 (dernière version d’Opera). Steve Souders a un bon résumé des capacités des différents navigateurs par rapport aux performances, pour ceux que ça intéresse.

A t’on encore besoin d’utiliser plusieurs domaines ?

Clairement quatre domaines représentent alors entre 16 et 24 requêtes simultanées. C’est clairement trop ou inutile. Surtout avec l’apparition des terminaux mobiles et autres netbook avec une connexion wifi ou 3G pas excellente et une puissance processeur réduite.

L’étude nécessite d’être refaite avec un échantillon d’utilisateurs plus représentatif de la période actuelle. Si encore une moitié des utilisateurs reste avec 2 connexions simultanées, il devient contestable de leur faciliter la vie si ça pénalise la seconde moitié de la population.

Intuitivement je changerai bien la règle en « deux domaines, mais surtout pas plus« , tout en diminuant l’importance de ce critère. En fait le second domaine est nécessaire de toutes façons pour pouvoir utiliser un CDN et diminuer la latence sur les ressources statiques. Pour un site en ssl/https les domaines surnuméraires deviendront d’autant plus coûteux à cause de la poignée de main ssl et tout garder sur un seul domaine dans ce cas là ne devient pas forcément si négatif que cela.

Je vois peu de raisons de garder plus que ces deux domaines (le domaine principal avec le contenu dynamique et le CDN avec les ressources statiques). C’est d’autant plus vrai avec les publicités, qui vous feront utiliser encore un ou deux domaines différents quoi que vous fassiez.

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.

La situation de base : Firefox bloque tous les nouveaux téléchargements quand il récupère une feuille de style. Une fois n’est pas coutume c’est Internet Explorer qui est le plus efficace, car il permet de paralléliser tous ces téléchargements.

Enfin presque.C’est là qu’est la découverte pour moi : Si un javascript en ligne est situé en dessous de la feuille de style, alors Internet Explorer imite le mauvais comportement de Firefox et bloque les téléchargements le temps de récupérer la feuille de style entièrement (à tester sur Cuzillon).

Dommage non ?

La solution simple est de remettre votre javascript en ligne au dessus de la feuille de style, ou de le mettre dans un fichier externe avec une des techniques de chargement vues précédemment.

Il y a des fois où ce n’est pas idéal et c’est Steve Souders qui étudie les solutions dans sa présentation aux conférences Velocity 2008. Quelques cas en vrac :

• Le Javascript est prioritaire, il doit être téléchargé et exécuté le plus tôt possible, mais pas au prix d’un blocage de tout le reste ;
• Il n’est pas possible déplacer l’insertion de la balise à la fin du document, le système ne le permettant pas ;
• Vous ne voulez pas montrer à l’utilisateur que la page est toujours en train de se charger (logo et barre de statut) ;
• Vous ne voulez pas que l’événement onload de la page attende le téléchargement et l’exécution du javascript.

Ne pas bloquer le rendu

Pour résumer les solutions intéressantes abordées par Steve Souders :

Passer par l’API DOM

La première solution est d’insérer le javascript via la création d’un noeud DOM. Le script ne bloque alors plus les nouveaux téléchargements. Le problème principal est que certains navigateur délaient l’événement onload tandis que d’autres l’exécuteront avant la fin du script. Cette différence peut rendre la gestion de la page un peu difficile

var se = document.createElement('script');
se.src = 'http://example.org/test.js';
se.type = 'text/javascript' ;
document.getElementsByTagName('head')[0].appendChild(se);

Passer par une iframe

La seconde solution est d’insérer le javascript via une iframe. Le rendu et les nouveaux téléchargements ne sont pas bloqués, l’événement onload réagit de la même façon sur tous les navigateur. Le défaut est que l’iframe fait elle-même perdre un peu de temps au rendu et que pour réutiliser le contenu on est limité à avoir la page et le script sur le même domaine. Impossible donc d’utiliser un CDN sur un domaine tiers.

Cela demande de plus de réorganiser le script lui même. La page principale devra passer par window.frames[x] pour accéder aux fonctions du script, et le script devra lui passer par parent.document pour accéder au DOM de la page principale.

Passer par XMLHttpRequest

La solution qui peut paraitre magique c’est d’insérer le javascript via une requête XMLHttpRequest. Le script ne bloque ni les nouveaux téléchargements ni l’événement onload. Mieux le navigateur ne montre pas à l’utilisateur que la page continue à se charger. Cela peut amener l’utilisateur à avoir une meilleure impression de vitesse. Par contre on est ici aussi limité à un seul domaine pour la page HTML et le javascript, donc pas de CDN sur domaine tiers.

Je ne vous met pas de code, chacun a sa bibliothèque pour ça. Vous pouvez utiliser DOM ou eval, comme vous voulez.

Passer par un script DEFER

Enfin, vous avez l’attribut DEFER que vous pouvez ajouter à une balise de script des plus classiqes. Là non plus le script ne bloque pas les nouveaux téléchargements … mais uniquement sous Internet Explorer.

Préserver l’ordre d’exécution

Tout ça donne déjà un bon aperçu mais tout n’est pas résolu. Dès que vous avez plusieurs javascript vous avez certainement des dépendances et l’ordre de chargement est important. Là ça se gâte. Vous oubliez la technique de l’iframe qui ne vous garantit rien.  

Si vous pouvez vous permettre d’avoir le javascript sur le même domaine que la page HTML, alors il va vous falloir gérer vous même un code dans XMLHttpRequest pour assurer l’ordre d’exécution.

L’écran 26 de la présentation donne une excellente grille de lecture de tout ça. Et les autres navigateurs ? motus et bouche cousue. Dans l’ensemble les comportements ont des chances d’être similaires à ceux de Firefox, mais c’est à tester. Il y a quelques liens vers le Cuzillon donc si certains veulent tester et donner les résultats Safari et Opera…

Utiliser YUI

L’équipe Yahoo! est toujours sur la brèche côté performance. Vous avez doc un outil YUI pour charger dynamiquement scripts et des feuilles de style en tenant compte des dépendances, sans bloquer le navigateur. Visiblement tout n’est pas clair sur la situation de Safari, il faudrait que je fouille un peu pour tirer ça au clair. D’ordinaire la politique est d’avoir un comportement stable sur tous les navigateurs grade A, dont Safari fait partie, donc j’ai bon espoir que si ce n’est pas déjà le cas, une solution finisse par être trouvée.

Pour le même prix l’outil YUI permet aussi de charger aussi les feuilles de style et éviter leur aspect bloquant sur Firefox.

Stoyan Stefanov en parle lui aussi, en détail.

Et l’avenir ?

Le bon côté c’est que les équipes Webkit et IE8 ont dans leurs cartons la possibilité de charger les scripts sans bloquer le navigateur et en les exécutant dans l’ordre d’apparition dans la page.

Tout ceci est pour demain, et les navigateurs d’aujourd’hui ne sont pas amenés à disparaitre rapidement, mais au moins, à moyen terme, on pourra n’avoir de ralentissement que sur les anciens navigateurs. Reste juste à espérer que Firefox et Opera bougent aussi sur ce point, mais malheureusement je n’ai pas vu d’information dans ce sens.

Au niveau du contenu

L’utilisation de javascript ou CSS concaténées et d’images en sprites diminuera l’impact de la latence par rapport au téléchargement lui même. L’utilisation d’un CDN diminuera la distance réseau entre vos serveurs et vos utilisateurs et réduira la latence elle-même.

Malheureusement vous aurez encore besoin d’au moins un fichier CSS, un fichier javascript, et probablement une bonne dizaine d’images au minimum. Cela fait douze requêtes. Avec un ping honnête de 40 ms, voilà une demi seconde qui part en fumée [1]. Inacceptable.

[1] Et par respect pour l’intervention de Rik sur un précédent billet, je signale que cette demi seconde est théorique, en pratique certains délais sont parallélisés donc ne délaieront pas d’autant le rendu de la page. L’impact reste cependant important, d’autant que votre site professionnel contient plus de douze ressources à télécharger non ?

Au niveau du réseau

Vos navigateurs ont heureusement deux mécanismes qui peuvent compenser notre demi seconde : keep-alive et pipelining. Nous parlerons ici du keep-alive, le pipelining sera pour demain.

Le keep-alive c’est le nom des connexions persistantes en HTTP. A partir de HTTP 1.1, par défaut votre serveur laisse la connexion ouverte après avoir répondu à une requête. Le navigateur peut alors relancer une nouvelle requête sur la même connexion, sans avoir à rétablir un nouvel échange TCP. C’est tout ça de gagné, et ce n’est pas négligeable.

La problématique

Les connexions persistantes sont un des réglages avec un fort impact sur les performances, sur lesquels on n’arrive pas à dégager un consensus.

La problématique est la suivante : une connexion persistante c’est une connexion qui reste ouverte pendant un certain temps « au cas où le navigateur ait encore des requêtes à faire ». Or une connexion ouverte a un impact négatif sur les performances du serveur. C’est un lien réseau ouvert et un processus avec son occupation mémoire. Un processus Apache avec PHP c’est généralement 5 à 10 Mo de mémoire vive. On ne peut pas en bloquer des centaines juste « pour attendre au cas où ». Si on surcharge le serveur, il répond plus lentement et au final les performances du client se dégradent aussi.

Une bonne pratique peut déjà être de réduire la durée valeur du keep-alive par défaut, c’est à dire la durée pendant laquelle le serveur garde la connexion ouverte en attente d’une nouvelle requête du navigateur. Par défaut Apache la règle à 5 secondes (15 secondes sur les anciennes versions).

La difficulté est de trouver un bon équilibre entre cette fonctionnalité qui aide le client et les performances du serveur. Sachant que le gain pour le client est significatif mais pas critique, le compromis est trop souvent un refuge vers la situation la moins risquée « on désactive tout keep-alive sur le serveur ».

Une recommandation rapide

Une recommandation générique (je m’attends donc à ce que chacun me dise qu’il est dans une situation tierce) serait de désactiver le keep-alive sur les serveurs de contenu principaux, et de l’activer avec quelques secondes sur les CDN.

En considérant que vos images et fichiers tiers sont sur les CDN, vous ne devriez avoir qu’un seul téléchargement par page sur le serveur de contenu principal : la page HTML. Inutile d’activer le keep-alive et d’attendre d’autres requêtes si on sait qu’il y a des chances qu’il n’y en ait pas d’autres de si tôt. De plus ces serveurs gèrent des requêtes dynamiques, donc embarquent souvent des langages de script. Chaque processus prend beaucoup de mémoire, les connexions persistantes coûteraient cher.

Sur les CDN la problématique s’inverse. On y télécharge tous les fichiers tiers, probablement plus d’une dizaine par page quand le cache est vide. Garder la connexion ouverte est intéressant pour le client comme pour le serveur. Ce sont aussi des serveurs qui n’envoient que des fichiers statiques, l’empreinte mémoire et le coût d’un processus qui reste en attente sont probablement beaucoup plus faibles.

Deux autres options

Une autre option, plus simple, est de mettre un proxy inversé devant votre serveur web. C’est lui qui va garder les connexions persistantes avec les navigateurs, et les processus d’un proxy ne coûtent pas très chers.

Le serveur web Apache propose aussi un module expérimental : MPM Event. Il permet d’utiliser un seul processus unique avec une file de connexions pour gérer les keep-alive, au lieu de bloquer un processus entier à chaque connexion persistante.

Votre solution

J’ai entendu dire tout et son contraire. Si vous avez fait des recherches ou simplement si vous avez testé plusieurs options, je suis curieux de connaitre vos conclusions et votre situation.

Pour l’instant j’ai surtout vu les trois solutions citées, dans le même ordre de préférence :

• Le plus souvent : on désactive tout, parce que le keep-alive est parfois plus négatif que positif, donc on joue la sécurité.
• Pas de keep-alive sur les serveurs dynamiques, mais un keep-alive moyen sur les serveurs statiques.
• Dans quelques cas un keep-alive assez long, mais géré par un proxy ou un serveur intermédiaire.

Sans limite ?

On ne peut pas non plus tout télécharger en parallèle. Si chaque contenu met une seconde à se télécharger, il est plus intéressant de les voir arriver un à un chaque seconde séquentiellement. En parallèle ils pourraient mettre tous dix secondes et on les verrait tous arriver simultanément à la fin.

Ce serait consommateur de ressources, sur le poste du client et sur le serveur. Nos dix requêtes simultanées prendraient dix processus sur le serveur pendant dix secondes au lieu d’un processus qui traite séquentiellement les requêtes. C’est dix fois plus de mémoire par exemple.

Enfin, le nombre optimum de connexions simultanées dépend de la bande passante disponible. Pas la peine de lancer vingt connexions simultanées. C’est plus de charge sur le serveur, plus de charge sur le client, un peu plus de r&seau utilisé à cause de l’établissement des connexions, mais aucun gain.

Il faut une limite, tout en parallèle n’est intéressant pour personne.

Quelle limite ?

La RFC de HTTP 1.1 nous propose un maximum de deux requêtes persistantes simultanées par serveur. Les navigateurs jusqu’à récemment ont traduit ça en « deux requêtes persistantes simultanées par serveur qui répond en HTTP 1.1″.

• Firefox : 2 connexions simultanées par domaine par défaut, mais Firefox 3 prévoit d’en autoriser 6.
• Internet Explorer : 2 connexions simultanées par domaine, sauf pour Internet Explorer 8 qui planifie d’en autoriser 6 aussi.
• Opera 9 et Safari 3 autorisent chacun 4 connexions simultanées par domaine.

Ces nombres sont augmentés si le serveur refuse les connexions persistantes, s’il répond en HTTP 1.0, ou si on passe par un proxy. Inversement, Microsoft Internet Explorer 8 tente de détecter si vous utilisez une connexion par modem RTC et revient alors à 2 requêtes simultanées par domaine pour ne pas saturer la ligne.

Plusieurs domaines

Jusqu’à récemment le conseil était d’étaler les ressources sur plusieurs domaines, de préférence 2. Cela permet de parallèliser les téléchargements puisque les limites sont « par domaine ». Au delà de 4 domaines l’équipe de performance Yahoo! a remarqué qu’entre une trop grande parallélisation et la multiplication des requêtes DNS, l’effet commençait à devenir négatif.

La question mérite d’être reposée sachant que Firefox et Microsoft Internet Explorer vont tripler le nombre de requêtes. Nous retrouverons par défaut dans le cas « ressources étalées sur 3 domaines » sans rien avoir à faire, et ceux qui utilisaient déjà plusieurs domaines voient leur traffic simultané multiplié d’autant.

La voie d’AOL

AOL a lui choisit une politique particulière mais pas forcément mauvaise : son serveur répond en utilisant le protocole HTTP 1.0. Cela a des implications, comme l’impossibilités d’utiliser des Etags, mais ces derniers posent presque plus de problème qu’ils n’en résolvent.

Le HTTP 1.0 leur suffit. Ils profitent alors automatiquement de plus de connexions simultanées de la part des navigateurs sans avoir à multiplier les domaines et les requêtes DNS. Ils n’auront du coup aucun problème du au changement de configuration par défaut des navigateurs : ils étaient déjà dans une configuration avec beaucoup de requêtes simultanées.

La recommandation

En attendant des mesures de performances plus concrètes prenant en compte les configuration des nouveaux navigateurs, garder la recommandation de l’équipe de performance Yahoo! est probablement le plus sage : étaler vos ressources sur deux domaines différents.

Un seul domaine, même en HTTP 1.0 comme AOL, ne vous permet pas d’utiliser un CDN pour diminuer la latence réseau. Plus de deux domaines risque de surcharger vos utilisateurs avec plus de connexions simultanées qu’il n’est bénéfique.

Le cadeau bonus c’est qu’en séparant les ressources statiques et dynamiques sur deux domaines, vous pouvez avoir une optimisation plus simple des ressources statiques : CDN, pas de cookie (c’est ça de gagné en traffic réseau), et entêtes d’expiration configurées globalement sur tout le domaine ; et une optimisation différente pour les ressources dynamiques : pas de keep-alive et entête imposant la revalidation des contenus pour éviter le cache.

Un javascript pas sans conséquences

Le code javascript est exécuté par nos navigateurs dès qu’il est lu et téléchargé. Il peut modifier le flux de contenu courant (principalement avec document.write) et donc modifier totalement l’interprétation du reste de la page. Imaginez par exemple que votre script insère < juste devant div>.

Le résultat ne peut pas être prévu à l’avance ni vraiment effectué après coup. Si div> est déjà analysé le navigateur, l’ajout d’un chevron ouvrant ne pourrait plus transformer facilement ce texte en noeud DOM, puis changer toute la hiérarchie de noeuds DOM pour la brancher sur notre nouveau <div>. C’est trop tard.

Stoppez tout !

À cause de cela, le navigateur considère un script comme une ressource exclusive. Quand il rencontre une balise <script>, le reste de la page est mis en attente et l’analyse est stoppée le temps d’exécuter le script. L’interprétation du reste de la page reprendra quand le script sera téléchargé et que son exécution sera finie. Si le reste de votre page contient des images ou des composants externes, leur téléchargement sera retardé d’autant.

En insérant votre code javascript dans la balise <head>, ou en haut de votre document html, vous bloquez l’accès à la page. Pour un script de 50 ko, sur un débit réel de 2 mb/s et une latence de 40 ms, nous voilà à près de 250 ms auxquels il faudra encore ajouter le temps d’exécution du script. Votre navigateur vient d’arrêter tout l’analyse et le rendu de la page pendant un quart de seconde, pour un script de taille modeste. Imaginez si vous en avez plusieurs, ou qu’ils prennent un peu de temps à s’exécuter.

Quelle est votre priorité ?

Votre priorité c’est quoi ? la page elle-même et son contenu, ou vos ajouts javascript ? Si votre page est illisible sans javascript vous avez déjà définitivement un problème à la base, et il vous faut le corriger. Si votre javascript n’est qu’un ajout pour apporter un plus à l’utilisateur alors ne devrait-on pas privilégier l’affichage du contenu plutot que l’exécution du bonus javascript ?

Permettre d’insérer le code javascript à la fin du document, juste avant le </body>, c’est permettre à l’utilisateur de charger la page et d’initier tous les téléchargements nécessaires avant de bloquer le navigateur sur ce javascript. Cela prendra toujours un quart de seconde, mais pendant ce temps le visiteur voit la page chargée. 250 ms ce n’est rien mais c’est ça qui fait la différence entre une page qui apparait rapidement et une page qui met du temps à se charger.

Le cadeau bonus

Le point bonus c’est qu’à ce moment là vous savez que toute la page est analysée. Vous pouvez interagir avec tout votre DOM sans avoir à attendre le chargement complet de tous les composants ou à mettre en place des systèmes plus ou moins brillants pour détecter la fin de chargement de l’arbre DOM. Fini les ajouts d’événements et les bidouilles pour implémenter le DomContentLoaded en javascript.

Reste à savoir pourquoi vous trouvez ça « sale » de mettre le code javascript en fin du <body>. C’est tout à fait prévu et accepté dans les spécifications HTML, cela donne des résultats concrets et importants au niveau performance, et ça rend même votre code plus simple. Le seul argument objectif que je peux concevoir c’est si vous avez deux rendus différents pour la page : avec et sans javascript. Mais il y a une astuce plus que simple pour ceci, ce sera l’occasion d’un autre billet.

Safari

Il est intéressant de noter que les développeurs de Safari ont trouvé une solution partielle à ce problème dans leur dernière version de développement. Quand un script est exécuté, le reste de la page est envoyé à un second moteur d’analyse, annexe. Ce dernier se contente de repérer les ressources à télécharger par la suite et lance le téléchargement en parallèle. Leur moteur privilégie aussi les scripts quand plusieurs téléchargements sont en file d’attente.

Cela ne résout pas l’affichage qui reste bloqué en attendant le script, par contre on évite beaucoup de problème de latence réseau et on améliore la parallélisation des téléchargements. Au final, on peut s’attendre à un gain de performance significatif sur les pages avec plusieurs composants javascript. chargés en haut de page.