Résumé

  • Le premier projet public Resource Timing du W3C, daté du 24 mai 2011, déplaçait la mesure du chargement global vers chaque ressource, notamment les images, et décrivait la recherche du domaine, la connexion, la requête et la réponse.
  • Le texte candidat de niveau 1 du 30 mars 2017 organisait ces mesures dans une chronologie avec un tampon limité. Pour les ressources d’une autre origine, Timing-Allow-Origin décidait de l’accès aux détails. Le navigateur mesurait; l’éditeur menait l’enquête.

La page était lente et chacun accusait son voisin. L’image principale soupçonnait la feuille de style. La feuille de style désignait un script. Le script trouvait que le serveur avait mauvaise mine. Une durée totale disait au lecteur combien de temps il avait attendu, pas quelle valise avait coincé le tapis roulant. Resource Timing posa un chronomètre sur chaque bagage.

Le premier projet public Resource Timing publié par le W3C le 24 mai 2011 partait d’un problème concret : comprendre la latence d’une page composée de ressources distinctes. Son exemple observait la durée de récupération d’une image. Cette échelle était différente de celle du temps de navigation du document. Une page peut commencer à s’afficher pendant qu’une photographie, une police ou un script suit encore son propre trajet. Une seule durée pour l’ensemble masque ces allées et venues.

Le projet décrivait une entrée de mesure avec le nom de la ressource, le type d’élément qui l’avait demandée et plusieurs étapes du chargement. fetchStart, domainLookupStart, connectStart, requestStart, responseStart et responseEnd servaient à lire le parcours. Le temps avait-il été pris par la recherche d’un nom, l’établissement d’une connexion, l’attente d’un premier octet ou le reste de la réponse ? Une horloge à plusieurs aiguilles n’écrit pas le diagnostic toute seule. Elle donne une question plus précise à poser à l’équipe.

Les aiguilles pouvaient parfois rester proches les unes des autres. Le navigateur réutilisait une connexion ou tirait une ressource du cache; certaines étapes du réseau n’étaient alors pas rejouées. Des instants égaux pouvaient décrire cette réutilisation. Pour comparer deux visites, il fallait savoir si l’une arrivait avec un cache déjà rempli et l’autre les mains vides. Le relevé portait sur une récupération particulière, avec son contexte, plutôt que sur la personnalité éternelle d’une image.

Dans la recommandation candidate Resource Timing Level 1 du W3C, datée du 30 mars 2017, ces entrées prenaient place dans une chronologie de performance. L’exemple du texte appelait performance.getEntriesByType('resource'), isolait les éléments dont initiatorType valait img, puis utilisait responseEnd et startTime pour leur durée. On pouvait ranger les arrivées de plusieurs images, regarder celles qui s’attardaient et examiner ensuite leurs étapes. Le navigateur donnait enfin une feuille de pointage à chaque ressource.

Le carnet avait une taille finie. Le texte de 2017 précisait un tampon pour les entrées et des méthodes comme setResourceTimingBufferSize() et clearResourceTimings(). Une page bavarde pouvait remplir le cahier. L’éditeur qui collectait ces mesures devait choisir combien de feuilles garder et à quel moment vider le carnet. Si les dernières ressources n’étaient plus enregistrées, l’absence de leur ligne ne témoignait d’aucune vitesse miraculeuse. La capacité de mesure était elle-même un choix d’exploitation.

Une autre décision appartenait au fournisseur d’une ressource distante. Une image venue d’une autre origine pouvait figurer dans la chronologie, tandis que le navigateur limitait par défaut la visibilité de certaines étapes fines. Le serveur de cette ressource pouvait envoyer Timing-Allow-Origin pour autoriser une origine à lire davantage de détails. Le site qui intégrait l’image ne décidait donc pas seul de soulever le rideau sur la recherche de nom, la connexion ou la réponse d’autrui.

Cette frontière changeait la lecture du relevé. Une entrée pouvait montrer une ressource étrangère et une durée tout en gardant plusieurs colonnes détaillées fermées. Lire un zéro comme « aucun temps dépensé » serait confondre absence d’accès et mesure instantanée. Avec l’autorisation du fournisseur, le navigateur dévoilait davantage de phases; sans elle, l’éditeur travaillait avec les indices disponibles. L’hôte distant tenait la corde du rideau de son propre chronomètre.

Le projet de recommandation candidate du W3C du 1er septembre 2026 poursuit cette histoire. Il décrit un modèle enrichi et un tampon plus grand que celui des anciens textes. Chaque date marque une version de la spécification : le projet de 2011, le texte candidat de 2017 et le projet candidat de 2026 n’ont pas exactement le même inventaire. Leur idée durable est claire. Le navigateur voit la récupération d’une ressource et peut en donner un relevé normalisé à la page.

Une image qui prend longtemps devient une piste d’enquête, pas un verdict sur l’expérience du lecteur. Était-elle visible tout de suite ? Bloquait-elle une information importante ? Aurait-elle pu arriver plus tard, être plus légère ou être placée autrement ? Le relevé de récupération répond à la première moitié de l’enquête. La page et son ordre d’affichage répondent à l’autre. Une équipe peut enfin discuter du bon bagage, puis décider s’il faut le déplacer, l’alléger ou changer de tapis.

Resource Timing a ainsi changé la conversation dans la salle de contrôle. « La page est lente » était une plainte. « Cette image a attendu ici, cette feuille a repris une connexion existante, les détails de cette ressource externe restent masqués » formait un programme de travail. Le chronomètre ne réparait rien, mais il empêchait l’image principale d’accuser la feuille de style sans présenter sa propre feuille de temps.