Résumé

  • Le premier projet public Resource Hints du W3C, publié le 21 octobre 2014, présentait preconnect comme une indication portant sur une origine. La résolution DNS, la négociation TCP et, le cas échéant, TLS pouvaient commencer avant que l’adresse complète de la ressource soit connue.
  • Les projets suivants ont distingué dns-prefetch, preconnect, prefetch et prerender. Le navigateur gardait le choix d’établir toute la connexion, une partie seulement, ou de ne rien entreprendre selon ses ressources.

Dans une galerie, le visiteur hésite entre deux photographies. La page connaît déjà le serveur qui détient les deux, mais le clic n’a pas encore désigné le fichier. Dès le choix fait, une connexion à monter de zéro ajouterait de l’attente au geste le plus simple du monde : voir l’image sélectionnée. preconnect propose de préparer le contact pendant cette hésitation. Le navigateur peut réserver la table sans inventer la commande du client.

Dans le premier projet public du W3C du 21 octobre 2014, le développeur ou le serveur pouvait proposer une origine au navigateur. Le texte énumérait les étapes susceptibles de commencer plus tôt : recherche DNS, poignée de main TCP et négociation TLS facultative. Son autre indice principal était alors preload, lié à une ressource à charger. La distinction évite une erreur coûteuse : établir une conversation avec une origine ne revient pas à récupérer d’avance un fichier dont personne ne connaît encore le nom.

Le projet du 4 mai 2017 présentait une famille de quatre relations. dns-prefetch vise la résolution du nom. preconnect va plus loin vers la connexion. prefetch concerne une ressource qui pourrait servir lors d’une prochaine navigation ; prerender peut préparer un futur document. La page peut connaître la destination sans connaître le trajet détaillé. Mélanger ces gestes reviendrait à faire livrer tout le menu sous prétexte d’avoir réservé une table.

Le projet du 27 juin 2019 expose précisément le cas de l’URL dynamique. L’application peut connaître l’origine avant de savoir quelle ressource exacte la construction de la page demandera. Une connexion commencée pendant cet intervalle évite de lancer toute la négociation au dernier moment. Le navigateur n’a pas besoin de deviner la photographie future ; il lui suffit de savoir avec quel serveur il pourrait bientôt parler.

Encore faut-il que la réservation vaille son coût. Le projet du 5 octobre 2020 laisse au navigateur le choix d’une négociation complète, partielle ou nulle. Il décide aussi du nombre de connexions à ouvrir vers une origine. État du réseau, ressources de l’appareil, protocole et limites de connexions entrent dans son calcul. Une page n’obtient pas quinze tables en glissant quinze petits papiers sous la porte.

Cette liberté protège surtout la visite en cours. Une connexion vers un serveur que personne n’utilisera occupe du réseau et de la mémoire ; une poignée d’origines mal choisies peut ralentir précisément l’image que le lecteur voulait voir. Le texte de 2020 prévoit que des travaux preconnect encore en cours ne retardent pas l’événement de chargement du document. Un restaurateur prévoyant garde des places pour les convives annoncés. Il ne met pas dehors ceux qui sont déjà à table.

L’historique de publication du W3C situe le premier projet public en octobre 2014 et les projets successifs jusqu’en 2020. Les brouillons ont quitté le simple duo preconnect/preload pour distinguer quatre gestes : trouver un nom, établir un contact, récupérer un fichier, préparer une page. Le changement de vocabulaire révèle la vraie question : combien de travail engager avant que le visiteur ait décidé ? La page apporte son indice, le navigateur tient les comptes. Puis le lecteur clique, et l’on voit si la réservation était bien placée.