J’adore le principe du préchargement. Il s’agit tout simplement de charger par avance les informations dont on pense avoir besoin plus tard pour pouvoir les utiliser instantanément à ce moment là. Quand plus rien ne fonctionne, le préchargement peut encore améliorer les choses.
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 ?
Très bon article, comme d’habitude. Bravo et merci.
Très intéressant comme d’habitude.
J’attends avec impatience un article sur comment améliorer ce temps de résolution sur un serveur dédié, ou alors vers quel prestataire se tourner.
Ca risque pas de surcharger les différents serveurs inutilement?
Pour les serveurs distants le surcout DNS sera quasi nul. Le FAI aura tout en cache.
Pour les serveurs DNS des FAI peut être, un peu. Je doute cependant que ce soit un cout énorme face au reste de l’infrastructure FAI. Ca reste probablement acceptable, d’autant que l’essentiel sera toujours du cache.
Pour le client, l’impact négatif sera quasi nul (requêtes courtes, en UDP)