Summary

  • La première ébauche publique du W3C, datée du 26 octobre 2010, partait d'un défaut concret : un chronomètre lancé par le script d'une page arrive après une partie du voyage.
  • La recommandation du 17 décembre 2012 a établi des repères pour la navigation, la recherche de nom, la connexion, la réponse et les étapes du document. Le site restait responsable du diagnostic et des corrections.

Le client arrive à la réception d'un hôtel, exténué. Le réceptionniste note l'heure, lui tend la clé et annonce que l'enregistrement a pris trente secondes. Le client a pourtant attendu son taxi, cherché l'adresse, fait la queue devant la porte et patienté pendant que l'hôtel retrouvait sa réservation. Le chronomètre du réceptionniste est exact. Son histoire est incomplète.

L'ébauche publique de Navigation Timing du 26 octobre 2010 décrit le même piège pour les pages web. Un script placé dans l'en-tête pouvait noter son heure d'exécution, puis calculer le temps écoulé jusqu'à l'événement de chargement. Il ignorait tout ce qui avait précédé son arrivée, notamment l'obtention du document. Pour le lecteur, cette attente avait bel et bien eu lieu. Pour le script, elle n'existait pas.

Le W3C proposait donc de demander l'heure à celui qui était là depuis le départ : le navigateur. navigationStart ouvrait le relevé. La page pouvait ensuite comparer ce point de départ avec la fin du chargement. Le premier bénéfice tenait presque dans une soustraction. Le changement plus profond consistait à rendre visibles les étapes que le code de la page ne pouvait pas dater tout seul.

Le relevé distinguait le début de la récupération, la recherche DNS, la connexion, l'envoi de la requête et l'arrivée de la réponse. Il suivait ensuite le document pendant son chargement, son passage à l'état interactif et l'exécution des événements du DOM. Une seconde de retard cessait d'être une grosse pièce de monnaie posée sur la table. Elle se divisait en petites lignes que l'on pouvait examiner. Si la réponse arrivait vite mais que le document devenait interactif tard, le serveur et le code de la page n'avaient pas le même dossier à défendre.

La version candidate du 2 juin 2011 marque une étape dans ce parcours. La recommandation du 17 décembre 2012 fixe l'interface PerformanceTiming et ses repères, de navigationStart à loadEventEnd. Le calendrier de publication du W3C replace ces textes entre l'ébauche de 2010 et la décision de 2012. Ce calendrier évite de raconter une invention instantanée : le reçu a été discuté, précisé puis adopté.

Un reçu honnête sait aussi quand une ligne ne représente pas un nouveau trajet. Si le navigateur réutilise une connexion déjà ouverte, les heures de début et de fin de connexion peuvent coïncider. Si le document vient d'un cache, certaines étapes du réseau se replient de la même façon. Lire chaque zéro comme un dysfonctionnement serait aussi maladroit que facturer un deuxième taxi à quelqu'un qui n'a pas quitté la voiture. La recommandation décrit ces cas au lieu de promettre que chaque visite suivra le même itinéraire.

Elle exige également une horloge monotone pour mesurer les étapes successives. Un changement de l'heure du système pendant le chargement ne doit pas faire apparaître une durée négative. Un hôtel dont la facture prétend que l'ascenseur est arrivé avant son départ perdrait rapidement la confiance de ses clients. Pour une mesure technique, la confiance dépend de conventions modestes de ce genre.

D'autres lignes restent volontairement vides. Lorsqu'une redirection traverse des origines différentes, les détails de son calendrier sont ramenés à zéro. L'interface ne doit pas fournir au nouveau site un moyen de reconstituer le comportement d'un autre. Le texte de 2012 signale aussi le cas de pages appartenant à des auteurs distincts sur une même origine : les frontières d'un nom d'hôte ne suivent pas nécessairement les frontières sociales de ses occupants. La précision exige ici une limite.

Le navigateur ne collectait pas des statistiques pour le compte du site et ne réparait pas une page lente. Dès la première ébauche, le W3C laissait la collecte, le stockage et la transmission des mesures aux applications. La recommandation précisait que l'interface n'était pas un concours de vitesse entre navigateurs. Un trajet mesuré décrit une visite, avec son appareil, son cache et son réseau. Pour comprendre le problème, il faut encore choisir les visites comparables et regarder les bonnes lignes.

Ce partage des rôles a laissé une trace durable dans la façon de parler de performance. Avant, une équipe pouvait accuser « le chargement » comme on accuse la météo. Après, elle pouvait demander quand la réponse était arrivée, quand le DOM était devenu interactif et quelle partie du trajet méritait une réparation. Le navigateur a remis les tickets. Il restait à lire la facture.