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 ?

C’est Marc Hertzog qui se colle à l’exercice avec JQuery. Il a amélioré un module de Scott Jehl qui lit une feuille de style et tente de précharger toutes les images qui y sont référencées. L’idée est séduisante. On supprime alors les temps d’attente pour les images qui s’affichent au survol de la souris ou sur les pages suivantes.

L’idée est séduisante mais je n’accroche pas tout à fait. Tout d’abord parce que c’est au navigateur de faire ça. J’ai souvent dit que sur les performances on compensait les manques des navigateurs et qu’il fallait être pragmatiques (le faire quand même même si dans l’idéal c’est le boulot du navigateur) mais là il s’agit de quelque chose de simple, très simple. Quand un « quick win » n’est pas réalisé par des gens intelligents – et les développeurs de navigateur le sont – c’est qu’il y a anguille sous roche.

Le plus gros défaut que je vois est celui inhérent à tout préchargement : on fait travailler le navigateur. Sur un poste personnel avec une navigation très linéaire ça n’a d’effet négatif quasi que sur les prestataires réseau. Mais sur une ligne partagée (entreprise, wifi), avec des gens très connectés (vidéo en streaming parallèle, deezer ou spotify en tâche de fond), ou simplement sur une navigation avec beaucoup d’onglets (vous faites une recherche, vous ouvrez beaucoup de pages en parallèle), vous pénalisez l’utilisateur ou ses voisins. Même chose pour un utilisateur en itinérance : utiliser son réseau et son processeur pour ça aura une influence forte sur sa batterie.

Le préchargement reste une bonne idée, mais à petite dose, pour des choses ciblées, prévues. Ici on télécharge tout sans discernement. C’est certain, on va aussi télécharger des éléments qui ont une faible probabilité d’être utile. Dans les commentaires de la version originale du script on propose de faire un tri sur l’url de chaque image, suivant son répertoire on décide si c’est une image qui doit être préchargée ou pas. On résout ainsi l’occupation réseau (mais pas l’occupation processeur), mais ça commence à faire usine à gaz. Sans compter que une même image peut avoir du sens pour un préchargement sur certaines pages mais pas sur d’autres.

À ce compte là autant lister les images à précharger dans un tableau javascript au lieu de lire toute la feuille de style. Ou mieux, des <link rel= »prefetch »> parce que c’est fait pour ça.

Enfin, c’est surtout utile pour les changement d’image au survol de la souris, ou sur une action utilisateur. Dans ce cas on modifie l’image en cours, ou on affiche des icônes. Bref, on se retrouve très généralement dans des cas où les images concernées sont de toutes façons dans des sprites, soit avec une liste d’icône, soit avec l’image qu’on remplace – l’image contient alors et la version sans survol et la version avec survol.

Bref, l’idée est bonne mais je reste septique sur la pertinence de mettre en place une solution générique de ce type.