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 ?

Je ne parle même pas de ce que pourraient nous apporter HADOPI et LOPSI2 s’ils filtrent les accès côté FAI (on peut leur faire confiance pour affirmer que les débits ne bougeront pas, mais en ce qui concerne la latence…). À 120ms de latence c’est d’un coup plusieurs secondes qui partent en fumée. En fait ce sont souvent les publicités qui ont la plus grande latence. Quand le javascript qui gère la pub est bloquant et qu’on a deux ou trois redirections HTTP, on peut facilement perdre une seconde. Si vous ne me croyez pas, regardez l’exemple de Right Media.

Les solutions

Pour aller plus vite il faut donc soit avoir moins de composants par page, soit faire en sorte que la latence entre ces composants et le visiteur est réduite. Moins de composants c’est renouveler des solutions que j’ai déjà abordé ici : mettre en cache tout ce qu’on peut, container les fichiers javascript, faire de même avec les feuilles de style, et explorer les sprites CSS pour les images. Réduire la latence elle-même est par contre plus complexe. Comme on ne peut pas d’un coup de baguette magique améliorer la connexion du visiteur (quoi que certains tentent de jouer avec TCP), il ne reste plus qu’à approcher le serveur au maximum près du fournisseur d’accès du visiteur.

Pour un public français c’est réalisable, les FAI français font du peering entre eux, tout est regroupé entre quelques gros, la latence due au placement géographique est probablement proche de zéro (pour un site américain, avoir des serveurs sur les deux côtes au lieu d’une seule fait une réelle différence par contre). Sauf qu’assez souvent ce n’est pas un site français c’est un site francophone, ou adressé aux français (qui sont peut être en déplacement). Reste que même pour un site non touristique qu’on croit adresser aux français métropolitain, il y a des requêtes qui viennent des DOM TOM, des pays limitrophes, des pays européens (oui, je travaille tous les jours de Paris avec une adresse IP londonienne ) et finalement d’un peu partout dans le monde (je suis toujours étonné de voir les statistiques géographiques de ce blog).

Content Delivery Network

L’idéal serait donc d’avoir un serveur local chez chaque FAI. Malheureusement on se doute bien qu’au niveau coûts c’est infaisable, d’autant plus s’il faut les synchroniser. Les CDN, puisque c’est comme ça que ça s’appelle (Content Delivery Network, réseau de distribution de contenu), se placent à quelques endroits géographiques, avec des liens réseaux spécifiques vers les FAI principaux et entre les différents emplacements. Amazon propose donc quatorze emplacements, huit aux USA, quatre en Europe (Londres, Dublin, Amsterdam et Francfort), ainsi que deux en Asie (Hong Kong et Tokyo). Akamaï, le leader, propose 71 pays différents (et probablement plusieurs emplacements aux USA).

Dans l’ensemble sur les CDN donnant des listes précises, les pays du nord et les USA semblent les mieux couverts mais ce peut être un biais du à mes sources d’information. N’ayant pas eu à faire de recherche spécifique  l’Asie l’Afrique ou l’Europe ont peut être quelques CDN spécifiques. À vous de fouiller dans la cinquantaine de CDN dans le monde. Akamaï propose une petite application pour constater la latence entre deux villes. Bon, c’est visiblement très biaisé, mais le principe est bien là, lui.

Fonctionnement

Sur le principe un CDN ce n’est pas bien compliqué. Il s’agit de modifier le DNS pour faire pointer vers celui du CDN. Là on utilise des DNS personnalisés chez différents FAI, ou un système de tracking géographique des adresses IP pour renvoyer les différents utilisateurs chacun vers le serveur le plus proche de chez eux. Le serveur lui même est soit pré-rempli avec tous les composants utiles, soit fonctionne comme un proxy évolué (ce qui demande que vous même gériez correctement toutes vos entêtes de cache).

Dois-je utiliser un CDN ?

Pour un petit site français, pas certain. Pour un site plus gros, cela peut permettre de déporter les coûts de serveurs et de bande passante, c’est uniquement une question financière. Par contre, dès que vous visez plus international, en dehors de la simple Europe occidentale, ça peut commencer à prendre son sens. Les coûts sont assez progressifs et abordables même pour une petite société (Akamaï part à partir de 150$/mois, Amazon a un prix au consommé qui semble ridicule pour des petits trafics).

Une seule chose, ne vérifiez pas l’efficacité depuis votre bureau français, avec une faible latence. Au mieux entre un CDN avec un serveur à Paris et votre propre serveur parisien, il n’y aura pas grande différence. Il se pourrait même que le CDN semble ralentir vos pages (vu qu’il faudra peut être joindre Londres pour certains réseaux). Par contre pour d’autres, aux DOM TOM ou à l’étranger, la différence sera notable. Un petit coup par webpagetest peut donner un premier aperçu si vous le souhaitez.

Au pire, rien ne vous empêche de fournir un lien directement vers votre serveur quand le visiteur est dans la même zone géographique, et un lien vers le CDN sinon. Une petite reconnaissance de l’adresse IP devrait suffire et le risque de dégrader les performances en cas d’erreur est assez faible.

Oui il faut, quand vous le pouvez, utiliser les liens centralisés de Google ou de Yahoo pour vos bibliothèques javascript. Je parle de ne pas recopier jquery ou yui directement sur vos serveurs, mais d’utiliser les liens centralisés proposés par les deux moteurs de recherche.

Voilà pour la réponse générique, ensuite on peut détailler un peu.

Content delivery network

Le premier gain c’est l’utilisation des CDN de Yahoo! et de Google. Le principe du CDN c’est plus ou moins placer des serveurs dans plusieurs pays, voire directement chez les FAI, pour que le trajet fait sur le réseau soit le plus court possible. On vise une latence réduite. La latence ça peut tuer un site web.

Seuls les plus gros sites web peuvent s’offrir des CDN. Profiter de Yahoo! ou Google c’est toujours appréciable.

Maintenant vous n’utiliserez qu’une seule grosse bibliothèque javascript. En échange vous allez utiliser un nom de domaine supplémentaire, donc une requête DNS supplémentaire et une connexion de plus. Le deal est intéressant si ce qu’on gagne en latence dépasse ce que coûte la requête DNS.

Soyons clairs, si vos contenus ne sont pas sur le même continent qu’une partie sensible de vos clients, alors c’est un bon deal, n’hésitez pas. Aux États-Unis, éviter de traverser de l’Alaska vers New-York, c’est du temps gagné, non négligeable. Mais en même temps les sociétés vraiment internationales ont déjà souvent un hébergement par pays ou continent, ou utilisent déjà un CDN.

Si vous restez en Europe occidentale ça devient déjà moins clair. Si vous êtes hébergés en France dans un gros datacenter et que vos clients sont en France … là pas sur que le bénéfice du CDN soit réel. Les FAI ont des liens de peering entre eux et avec les hébergeurs français, la latence est globalement faible dès le départ. (Note: ceci n’a pas été vérifié par des tests, je suis preneur d’avis et de retours d’expérience sur la pertinence de CDN pour un trafic français avec un hébergement en France)

Nombre de domaines

Le second aspect de ces caches centralisés c’est le fait qu’ils sont justement sur un domaine séparé. Il y a du pour et du contre.

Dans le pour, votre Javascript peut être téléchargé immédiatement même si les files de téléchargement sont déjà occupées avec d’autres éléments de votre site. Maintenant comme on définit souvent ce genre de bibliothèques javascript tout en haut de page, les files de téléchargement sont généralement vides à ce moment là de toutes façons. Bref, je ne suis pas convaincu.

Toujours dans le pour, si votre navigateur est très récent (comprendre : IE 8, Safari 4, Firefox 3.1) le javascript ne bloque pas les autres téléchargements. Là aussi, avoir un domaine différent évite d’utiliser un slot dans vos autres téléchargements. En pratique, avec six slots simultanés minimum sur ces navigateurs, je ne suis pas convaincu que cela fasse une différence fondamentale.

Bref, pas convaincu, sachant qu’il y a du contre qui s’ajoute : avec un nom de domaine en plus, comme on l’a vu, il y a une requête DNS supplémentaire. Est-ce que ça vaut le coup pour un unique fichier ? pas sûr du tout.

Cache centralisé

Troisième aspect, en utilisant les liens de Google et Yahoo! on finit par tous utiliser les mêmes URL pour nos bibliothèques javascript.

Le résultat c’est que pour les bibliothèques les plus populaires, cela augmente la probabilité que vous l’ayez déjà en cache à cause d’un site précédent. Là le gain est important, surtout pour vos pages d’accueil (celles qui ont le plus gros trafic « cache vide »). Reste qu’en réalité l’URL contient la version de la bibliothèque et tous les sites n’utilisent pas les mêmes versions, ou même les mêmes bibliothèques. La mutualisation est assez limitée et le gain reste à prouver.

L’avantage concret est par contre visible pour les entreprises et pour les universités. Ces dernières ont des proxys cache qui auront toutes les chance d’avoir déjà votre bibliothèque en cache, dans la bonne version. Sur la cinquantaine (ou le millier) de collègues, il y en aura bien un qui aura téléchargé la bibliothèque avant vous.

La question est donc, vos visiteurs sont-ils sur des lignes professionnelles ou des lignes de particuliers ? dans ce second cas le gain n’est pas évident.

Mais alors, pourquoi répondre « oui » ?

Parce que je parlais jusqu’à maintenant du cas idéal. Si vous avez déjà un CDN, que vos ressources statiques sont déjà sur domaine séparé, et que vos entêtes de cache sont bien réglées, alors gardez vos bibliothèques chez vous. Mais … ce n’était le cas pour aucun de ceux qui m’ont posé la question.

En fait je doute que ce soit le cas pour quiconque se pose la question. Ceux qui ont déjà fait tout le chemin de performance avec CDN, domaine tiers et entêtes de cache, ils ont souvent les moyens de tester eux même quelle est la meilleure solution. Ou mieux, ils ont déjà réalisé que pour éliminer une requête HTTP il faut déjà fusionner leur bibliothèque javascript avec leur code javascript spécifique. Bref, la question est sans objet pour eux.

Pour les autres, qui n’ont pas les moyens d’utiliser un CDN quand bien même ils en auraient besoin, ou qui n’ont pas déjà un domaine séparé pour les ressources statiques, ou qui ne gèrent pas correctement leurs entêtes de cache, pour eux c’est intéressant. Ce n’est pas parfait, mais c’est un mieux, une démarche d’amélioration progressive. Pour vous, qui vous posez la question, la réponse est probablement « oui, utilisez les liens de Yahoo et Google pour vos bibliothèques javascript ». Et puis … ça fait autant de bande passante en moins à payer.

En cas de doute, le « oui » a plus de chance d’être positif ou sans effet que de réellement être négatif.

Pour l’exemple, j’ai arbitrairement utilisé le blog de Frédéric de Villamil. La page semble assez rapide à charger. Concrêtement, de chez moi, je met environ 500 ms à charger les composants internes (je ne compte donc pas le tag Google analytics et les images Flickr).

Sur ces 450 ms je charge :

• 82 ms pour la connexion initiale et le téléchargement du fichier HTML ;
• 19 ms pour la feuille de style ;
• 96 ms pour 4 fichiers javascript ;
• le reste vient des 9 images, chargées avec deux fils de téléchargements parallèles.

En soit il n’y a rien d’extraordinaire mais cela fait tout de même un total de 15 ressources à télécharger.

L’impact de la latence

Pour chaque ressource à télécharger je subis la latence du réseau, c’est à dire le temps d’acheminer ma requête jusqu’au serveur puis le temps que sa réponse traverse les câbles pour atteindre ma machine. 

Frédéric utilise une machine sur un réseau très proche du mien. Un aller-retour met donc 12 ms à s’exécuter, ce qui est extrêmement peu. 15 ressources à télécharger c’est 15×12 = 180 ms, soit tout de même 40% de mon temps d’attente.

Si on regarde de plus près, les 4 fichiers javascripts sont génériques. Si je les concatène pour en faire un seul, je gagne d’un coup 3 aller-retours, soit 60 ms (13% de mon temps d’attente).

En allant un peu plus loin, les images de fond pour l’entête et le pied de page pourraient être regroupées en un sprite CSS vertical. Les autres images de mise en page pourraient être regroupées en un sprite horizontal.  Sur 6 images de mise en page (il y avait deux images de contenu), nous réduisons à deux fichiers. Le gain est de 50 ms (11% du temps d’attente).

Avec ces réductions, c’est un total de 110 ms qu’on peut épargner aux navigateurs, soit 25% du temps de chargement de la page. Non seulement la page finira de s’afficher 25% plus vite, mais en plus l’affichage débutera bien plus tôt : le chargement de nos fichiers javascript bloquait l’affichage de la page. 60 ms de gagné à cet endroit, c’est une page qui débute son affichage 60 ms plus tôt.

L’ordre de grandeur des gains

Les chiffres mentionnées semblent minimes, et ils le sont. Mais un chargement de près de 500 ms c’est un chargement qui est ressenti par le visiteur. Permettre de débuter l’affichage plus vite et finir plus rapidement le téléchargement de toutes les images, c’est un vrai ressenti de « site rapide » pour l’utilisateur. Quelle que soit la valeur absolue, quand vous dépassez 250 ms, 25% de gain c’est visible.

Ces chiffres sont minimes aussi parce que j’ai pris un cas presque idéal : peu d’images dans le graphisme, et un serveur avec une liaison presque directe vers mon fournisseur d’accès Internet. La latence avec le serveur est plus souvent de l’ordre de 30 à 60 ms, parfois plus. Même Google et Yahoo sont à un peu plus de 30 ms de de chez moi.

Si le serveur de frédéric avait une latence de 40 ms au lieu des 12 ms, mon navigateur aurait mis un peu plus d’une seconde à tout afficher. Il commence à y avoir un vrai sentiment d’attente de la part de l’utilisateur (imaginez si votre téléviseur mettait ce temps là à réagir).

Nos petites optimisations simples à faire auraient épargné presque 280 ms : plus d’un quart de seconde. Là aussi cela se verra pour l’utilisateur, surtout si ça veut dire que la page commence son chargement plus vite.