Résumé

  • Le projet Resource Priorities publié par le W3C en 2013 proposait notamment lazyload et postpone pour infléchir l’ordre des téléchargements. La note du groupe de travail datée de 2014 déclare cette spécification abandonnée.
  • Un rapport ultérieur du WICG, Priority Hints, a été retiré après l’intégration de ses parties pertinentes dans HTML et Fetch. L’attribut actuel fetchpriority exprime high, low ou auto entre ressources de même destination ; Fetch distingue toujours une priorité interne propre au navigateur.

Sur une page chargée, l’image d’ouverture et un ornement situé plusieurs écrans plus bas peuvent se présenter ensemble à la caisse. Leurs octets n’ont pas lu la conférence de rédaction. L’auteur connaît pourtant la place de chacun dans le récit. Le navigateur dispose d’un autre savoir : l’état de la machine, la connexion et les autres demandes déjà en cours. Donner à l’auteur une voix sans lui remettre la caisse, voilà le problème technique et politique des priorités de ressources.

Le premier projet public du W3C, daté du 29 octobre 2013, s’intitulait Resource Priorities. Il proposait lazyload, postpone et une propriété CSS. Le document observait qu’un téléchargement suivant simplement l’ordre du document pouvait mal servir la vitesse ressentie. lazyload indiquait une moindre urgence lorsque les ressources se disputaient la connexion ; postpone concernait l’attente jusqu’à l’approche de l’élément dans la zone visible. Ce texte présente une architecture envisagée, pas un inventaire des navigateurs qui l’auraient adoptée.

La suite est inhabituellement franche. La note du groupe de travail du 23 octobre 2014 annonce que la spécification n’est plus maintenue et qu’elle a été abandonnée. Elle renvoie les lecteurs vers les resource hints. lazyload figure encore dans cette version ; la section consacrée à postpone a disparu. La tentation de raconter un progrès linéaire, de cet ancien attribut à fetchpriority, excède les pièces disponibles. Les contrats techniques et les trajectoires documentaires diffèrent.

Le rapport Priority Hints du WICG, daté du 22 février 2023, décrit plus tard un signal de priorité relative destiné à être pris en compte par le navigateur. Il porte aujourd’hui lui aussi la mention « obsolète », mais pour une autre raison : les éléments utiles ont été intégrés aux spécifications HTML et Fetch. Un document a été abandonné ; l’autre a cédé sa place à des textes vivants. Le même tampon rouge ne raconte donc pas la même histoire.

Dans le standard HTML actuel, fetchpriority accepte high, low et auto. La comparaison s’effectue avec d’autres ressources ayant la même destination. L’absence de valeur, ou une valeur invalide, conduit à auto. Voilà une précision qui rabat les envolées des vendeurs de miracles : inscrire « high » partout n’attribue pas une priorité absolue sur tout le trafic. L’auteur émet une préférence située.

Le standard Fetch donne à une requête une priorité high, low ou auto, puis un champ distinct de priorité interne, dont la forme peut dépendre de l’implémentation. Le navigateur conserve ainsi ses propres paramètres de décision. Une rédaction peut mieux distinguer la photo principale d’une décoration ; elle ne connaît pas à l’avance la totalité des contraintes qui pèseront sur la visite.

L’idée durable est simple : faire circuler l’intention éditoriale vers celui qui exécute, sans faire du balisage un ordre militaire. Les textes établissent les mécanismes et les dates, pas un gain chronométré pour un site particulier. Quand une page déclare chaque fichier urgent, elle fournit autant d’indications qu’un restaurant où tous les clients portent un badge « VIP ». La file, elle, existe toujours.