Performance perçue et chargement de la page

Bien entendu, la performance qui compte pour vos visiteurs est celle qu’ils perçoivent, qu’ils ressentent, c’est à dire le confort de leur visite sur votre site. Nous mettons de côté ici ce qui relève de la bonne conception générale, de l’ergonomie ou des qualités esthétiques, pour nous focaliser sur la rapidité.

Un grand nombre d’études ont montré que la vitesse d’affichage des pages est un des premiers critères de confort, donc d’appréciation des sites et donc de fidélisation. Le temps total d’affichage peut se décomposer de la manière suivante :

1. Temps de parcours de la requête jusqu’au serveur
2. Temps de traitement de la requête par le serveur
3. Temps de parcours de la réponse jusqu’au navigateur
4. Temps de traitement de l’affichage dans le navigateur

Pour être précis, ce n’est pas si simple. Le serveur envoie une page Html, qui porte des références à de nombreux autres composants : feuilles de styles css, fichiers javascript, fichiers images, objets Flash, autres fichiers Html inclus en iFrame, etc. Et tout ces morceaux, nécessaires à l’affichage, ne parviennent pas tous en même temps. Ce n’est qu’après avoir analysé le premier fichier Html que le navigateur peut adresser d’autres requêtes pour obtenir quelques autres composants. Et ce n’est qu’après avoir chargé et exécuté le code javascript qu’il pourra demander d’autres composants le cas échéant.

Il y a donc tout un enchaînement de dépendances entre les composants constituant la page, ce qui conduit à une chronologie de chargement pour l’ensemble de la page.

La figure précédente représente la chronologie de chargement de page du site lemonde.fr. On l’a tronqué volontairement car il y a plus de 100 éléments pour un temps de chargement de 5,5 secondes.

La plupart des professionnels du web savent cela, et pourtant beaucoup en oublient l’importance et les implications. Il n’est pas rare qu’une page inclue plus de 100 composants, petits et grands. La page d’accueil de lemonde.fr en compte 150, et celle de libération plus de 200. Le temps total de chargement d’une page, jusqu’au dernier morceau, est couramment plus de 10 fois le temps de chargement de la première partie Html. Ou autrement dit, le Html ne représente que 10 à 20% du temps total de chargement de la page.

Le figure précédente représente la répartition du nombre de composants sur les principaux sites français, calculée par www.woozweb.com à partir d’un échantillon de 6000 sites. On voit qu’un nombre important de sites, de l’ordre de 20%, ont plus de 50 éléments à charger pour afficher leur page d’accueil.

Cette figure-ci représente de manière semblable, le nombre d’images sur ces pages.

Les autres composants de la page

Il est donc essentiel de s’intéresser au reste, à tous ces petits composants oubliés, qui mettent du temps à arriver.

Parmi eux, une grande partie sont relativement statiques, c’est à dire qu’ils changent peu et n’ont pas été produits par une application ou un outil de gestion de contenus. C’est le cas en général des fichiers javascript, des feuilles CSS, des images et des objets Flash. Ces composants ont le plus souvent une « durée de vie » importante, et peuvent donc être mis en cache avec un grand bénéfice de performance.

Il faut une mention particulière pour les composants javascript, des programmes qui s’exécutent sur le navigateur. Dans certains cas, l’exécution de ces programmes va générer d’autres requêtes, pour charger d’autres composants. Et ils peuvent être complexes, et prendre plusieurs secondes à s’exécuter. Ainsi l’exécution de ces programmes pendant le chargement va peser sur le temps total de chargement de la page. Evidemment, ces programmes doivent être réduits au maximum. Mais la tendance est plutôt contraire : avec l’intégration de fonctionnalités Ajax dans les pages, on a de plus en plus de lourdes librairies javascript à charger.

Enfin, parmi les nombreux composants intégrés dans une page web, certains proviennent d’autres serveurs. C’est le cas en particulier des images ou objets flash de publicités, qui sont souvent servies directement par les régies. C’est le cas aussi des objets inclus pour la mesure d’audience. Et ce peut être le cas aussi, de quelques autres composants inclus : vidéos de Youtube, météo, etc. Dans tous ces cas, les performances de votre site, dans l’affichage des pages, seront dépendantes de serveurs que vous ne maîtrisez pas.

Un monde tout petit ?

On dit parfois que l’Internet supprime les distances, mais ce n’est pas encore tout à fait exact. La distance physique, géographique, séparant un serveur web et l’internaute a une réelle influence sur les performances perçues, même si elle n’a aucune influence sur les performances du serveur lui-même. Il arrive couramment que des sites qui s’ouvrent à un public international se plaignent de la lenteur perçue par des internautes chinois, australiens ou bien brésiliens, alors que tout allait bien lorsqu’ils ne s’adressaient qu’aux européens.

En fait, ce n’est pas tout à fait la distance géographique qui compte, mais plutôt la distance par rapport à la topologie du réseau.

En matière de télécommunication, deux grandeurs essentielles sont à distinguer : le débit et le temps de latence. Le débit, c’est le nombre de bits ou d’octets par seconde que l’on peut transporter. Le temps de latence c’est le temps que met le premier octet à arriver. Ou bien on parle parfois de temps d’aller-retour (« RTT ou Round Trip Time »), le temps que met un octet à faire un aller-retour, plus facile à mesurer par un simple « ping » que le seul temps aller.

Or on s’intéresse le plus souvent au débit, en supposant le temps de latence négligeable. Mais à l’échelle de la planète, ce n’est pas le cas.

La limite inférieure au temps de latence est liée à la vitesse de la lumière. La vitesse de la lumière dans les fibres optiques est environ 2/3 de la vitesse de la lumière dans le vide, c’est à dire 0,66 x 300 x 10 ⁶ m.s ^-1, soit 200 x 10 ⁶ m.s ^-1 (200 000 km par seconde). C’est rapide, mais la terre est grande. Il y a 9000 km entre Paris et la Californie, ce qui représente un temps de latence minimal de 45 ms. 17 000 km entre Paris et Sidney, soit 85 ms au minimum. Mais les fibres ne vont pas à vol d'oiseau et chaque routeur traversé ajoute aussi un petit temps de latence, de sorte que le temps de latence réel peut être facilement double ou triple de la valeur théorique. Aujourd'hui, on peut mesurer un RTT (ping) d'environ 400 ms sur Paris-Sydney. Et par ailleurs, ce temps de latence croissant avec les distances tend à faire baisser les débits également.

L’image précédente, issue de www.woozweb.com, fait apparaître le temps de réponse d’une page html de 380 ko, tel qu’il est perçu depuis la France (courbe noire en bas) et depuis les Etats-Unis (courbe rouge en haut). L’axe des x représente le temps en heures, avec une mesure tous les ¼ d’heures. On constate que le temps de réponse perçu pour ce seul fichier est environ double depuis les Etats-Unis, avec aussi une moindre stabilité c’est à dire des pics plus importants.

En synthèse donc : la distance n’est pas négligeable sur Internet.

Les chinois devront-ils se résigner ?

La seule solution pour obtenir d’excellentes performances en tous points du globe est de servir les contenus depuis différents serveurs, en choisissant le serveur le plus proche de l’internaute. Lorsque le service est lui-même localisé, par nature, c’est à dire lorsque les chinois et les européens n’accèdent pas aux mêmes pages, n’achètent pas les mêmes produits, alors le plus simple est de prendre un hébergement dans différentes zones géographiques, au minimum Amérique, Europe, Asie, avec des plateformes totalement distinctes, n’échangeant que quelques flux de synthèse (états des ventes, tables de référence…).

Dans certains cas toutefois, cette approche ne convient pas. Soit le service est intrinsèquement global et ne peut pas être découpé en sous-domaines indépendants. Ce peut être le cas d’un FaceBook par exemple. Soit au contraire le service n’est pas assez global pour pouvoir se permettre un hébergement multiple.

Content Delivery Network

On appelle CDN, Content Delivery Network, un dispositif qui permet de servir les mêmes contenus depuis différents serveurs, en sélectionnant le serveur le plus proche de l’internaute. Les plus grands acteurs de l’Internet ont construit leur propre CDN.

Un CDN maison pour pas cher

Prenons un cas très simple. Vous avez une plateforme web hébergée en France, qui adresse des clients dans le monde entier. Vos pages, comme celles d’un site typique, se chargent en 5 secondes, dont 4 pour les différents composants statiques, images et autres. Depuis l’Asie, ces 4 secondes deviennent 8 ou 10.

Peut-on y remédier simplement ? Oui. Il suffit de louer un petit serveur pas cher dans un bon datacenter local, par exemple en Corée du Sud, et d’y pousser tous vos fichiers statiques. Pour cela, on mettra en place une réplication automatique, de type RSync, entre votre serveur français et votre serveur coréen. Ensuite, il faut encore que, pour vos internautes asiatiques, les images soient servies depuis le serveur coréen. Vous pouvez gérer cet aiguillage par vous-même, en détectant l’origine de l’internaute et en insérant des images <img src="http://www-asia.smile.fr"> au lieu des références d’images précédentes. Ca demande un peu de code, mais en termes d’architecture, c’est en fait très simple. Vous aurez alors construit votre propre CDN et amélioré sensiblement les performances perçues par vos internautes chinois, pour un coût très raisonnable.

Akamai, et les autres

On peut distinguer deux niveaux dans la mise en œuvre d’un CDN. Soit le CDN ne distribue que certains types de composants, typiquement les images, vidéos, css, etc. Soit le CDN va plus loin et joue un rôle de cache sur des fragments de Html, produits par des applications. Sur ce dernier aspect, on se reportera à un billet d'hier, sur la mise en place d'un cache par fragment avec l'edge-side include (ESI).

La mise en œuvre du CDN pour servir localement les composants statiques seulement peut être transparente et très rapidement mise en œuvre. Outre l’option « maison » évoquée ci-dessus, il existe quelques prestataires proposant un CDN prêt à l’emploi. Dans une approche un peu plus « pro », on ne bricolera pas les tags <img>, on comptera plutôt sur le DNS pour aller chercher les images sur le serveur le plus proche. Outre la quasi-transparence de la mise en œuvre, les CDN dédiés ont bien sûr une couverture mondiale difficilement égalable.

Ces dernières années, le marché avait été écrasé par l’acteur dominant Akamai, qui avait de plus racheté quelques-uns de ses concurrents et dont l’action a été multipliée par 4 en 2006. Mais l’arrivée massive des vidéos a donné un nouvel élan à ce secteur, et fait apparaître de nombreux concurrents, qui ont ouvert une guerre des prix sévère, en particulier Limelight Networks, Level 3, Internap, CDNetworks, ou encore Panther Express.

Approche globale multi-centres

Qu’on ne se trompe pas : l’approche CDN conserve une logique fondamentale centralisée. Il y a une plateforme centrale, mais un réseau global de distribution des contenus, qui peut fonctionner soit en mode cache passif, en pull, soit en mode actif, en push. Mais pour les applications de la plateforme centrale, l’existence du CDN doit être pratiquement transparente.

On peut aller plus loin, et construire une infrastructure réellement distribuée sur différents datacenters. Il est vrai qu’on parle le plus souvent d’extensibilité au sein d’un même datacenter, mais il peut y avoir différentes bonnes raisons pour considérer l’extensibilité d’une manière plus globale, sur plusieurs datacenters :

• La tolérance aux pannes : un datacenter peut se trouver globalement indisponible, pour différentes raisons, et toutes les mesures internes à la plateforme seront alors inopérantes.
• La proximité physique des internautes, dans une approche de type « Content Delivery Network », telle que décrite ci-dessus.
• La recherche d’un point d’équilibre entre mesures de haute-disponibilité interne à une plateforme, et haute-disponibilité globale multi-plateformes, pour viser une haute-disponibilité globale au moindre coût.

On sait que la construction d’une plateforme haute-disponiblité avec une forte capacité d’accueil peut être coûteuse. Un boîtier de répartition de charge haut-débit est déjà un équipement coûteux. Et bien sûr, un boîtier unique présente un point de fragilité : il en faut deux, comme il faut deux routeurs, deux firewalls, deux raccordements électriques, deux raccordements Internet, etc. Et pourtant, l’expérience nous montre que parfois, le datacenter dans sa globalité est indisponible. Construire une architecture distribuée globale est le moyen d’aller un ordre de grandeur plus loin dans la haute disponibilité, et peut-être pour un coût inférieur.

La répartition de charge globale

Pour répartir la charge entre des datacenters différents, les techniques ne sont pas du tout les mêmes que pour répartir la charge entre différents frontaux d’un même centre. En général, on ne recherche pas ici un équilibrage de la charge, c’est à dire qu’on ne cherche pas à diriger l’internaute vers le datacenter le moins chargé. Le but est plutôt de le diriger vers le datacenter le plus proche, au sens du réseau.

On présentera trois types de solutions : DNS round-robin, GeoDNS et Anycast. Toutes les trois interviennent au niveau du DNS, c’est à dire de la résolution du nom de domaine. Lorsque le navigateur doit accéder à un serveur www.smile.fr, il commence par rechercher l’adresse IP correspondant à ce serveur www sur le domaine smile.fr, en adressant sa requête à un serveurs DNS, ou bien de manière récursive à différents serveurs DNS. Une fois qu’il a obtenu l’adresse IP, il la conserve en cache selon différentes règles, généralement au moins une demi-heure.

Ces différentes techniques à base de DNS, offrent donc une relative stabilité dans l’adressage. Mais elle n’est pas suffisante pour qu’on puisse y compter de manière fiable. En d’autres termes : les requêtes d’une session d’un même internaute parviendront au même datacenter le plus souvent mais pas toujours. Et lorsqu’il change de datacenter, il faut que cela reste transparent pour lui. Ce qui implique soit un fonctionnement totalement sans session, soit un fonctionnement dans lequel toutes les informations de session sont conservées dans un cookie. Autrement dit, aucune information de session côté serveur.

DNS-RR

La technique la plus couramment utilisée est celle du DNS round-robin.

Pour l’expliquer, il faut commencer par rappeler quelques principes de fonctionnement du DNS. Lorsqu’un ordinateur veut ouvrir une connexion IP avec un serveur dont il connaît le nom, par exemple www.smile.fr, il lui faut d’abord obtenir l’adresse IP correspondant à ce nom. Il s’adresse pour cela à un serveur de noms de domaines, DNS. Le serveur DNS lui répond en lui fournissant une liste d’adresses IP, dans un certain ordre. La première est celle qu’il faut utiliser en premier lieu, les autres sont des adresses de secours. Si l’on dispose de trois serveurs S1, S2, S3 capables de traiter les requêtes, alors le serveur DNS pourra répondre { S1, S2, S3 }, dans cet ordre. Le principe du DNS-RR consiste à répondre en indiquant les serveurs dans un ordre aléatoire, ou bien en permutation : {S1, S2, S3 }, puis {S2, S3, S1 }, puis {S3, S1, S2 } et ainsi de suite. Le premier client, s’adressera donc à S1, le second à S2, le troisième à S3. Et si S1 ne répond pas, alors le premier s’adressera à S2 en secours.

Cette technique a le mérite d’être très simple à mettre en œuvre, et ne requiert pas un DNS spécifique. Elle peut convenir lorsqu’on dispose de 2 ou 3 datacenters d’une même région géographique, d’un même continent. Elle convient beaucoup moins bien au niveau global, avec des datacenters sur différents continents, car elle peut amener l’internaute européen sur un datacenter asiatique, l’internaute américain sur un datacenter européen, et ainsi dégrader la qualité de service de tout le monde. On a vu déjà qu’à l’échelle de la planète la proximité géographique a un impact important sur la qualité de service.

GeoDNS

Au lieu de répondre dans un ordre aléatoire, ou en permutation, le serveur DNS peut essayer de répondre intelligemment, en fournissant en premier le serveur le plus proche de l’internaute. C’est l’objet de l’extension GeoDNS, qui ajoute cette fonctionnalité au serveur DNS BIND, le plus utilisé sur l’Internet.

Bien entendu, cela suppose de gérer son propre DNS sur son domaine.

L’extension GeoDNS permet de définir, pays par pays, la réponse spécifique du DNS à une demande de l’internaute, et donc de répondre { S _FR, S _US , S _KR } a un internaute européen, et { S _KR, S _US , S _FR} à un internaute chinois, où S _FR, S _US et S _KR sont des serveurs hébergés respectivement en France, Etats-Unis et Corée du Sud.

C’est donc une solution qui convient bien au niveau global.

Anycast

La dernière solution, utilisée par les plus grands sites globaux, s’appelle « Anycast ». Elle consiste à utiliser la même adresse IP pour différents serveurs DNS en charge du domaine, chaque serveur étant hébergé sur le même datacenter que l’une des plateformes web. Ainsi si l’on dispose de trois plateformes dans trois datacenters, en Europe, Asie et Amérique, on mettra en place trois DNS pour mondomaine.com, sur ces mêmes plateformes.

Comme ces trois serveurs DNS partagent la même adresse IP, on compte sur les algorithmes de routage IP pour trouver automatiquement le serveur DNS le plus proche de l’internaute. Chaque DNS répond à la requête de nom de domaine de manière légèrement différente, en plaçant l’IP de son propre datacenter en tête de liste.

Le génie de cette solution, c’est de trouver de manière naturelle le serveur le plus proche, au sens de la topologie de l’Internet, et non au sens géographique, en utilisant les mécanismes standards du réseau.

Partager une adresse IP est parfois hasardeux, et effectivement, dans une connexion TCP/IP, il se pourrait que certains paquets arrivent à un serveur et d’autres à un autre serveur, ce qui rendrait la communication impossible. Mais l’interrogation DNS n’utilise que le protocole UDP, qui est sans session, de sorte qu’il est compatible avec le mode Anycast.

Conclusion

Pour un acteur réellement global, et il y en a de plus en plus, y compris d'origine française, la planète est petite en termes de business, mais reste grande quand il s'agit de servir des clients sur les 5 continents. Pour autant, il existe toute une panoplie de solutions pour construire des plateformes à l'échelle de ces enjeux globaux.