Resumen

  • El borrador Resource Priorities del W3C de 2013 exploró lazyload y postpone para comunicar preferencias de descarga. La nota de 2014 declaró abandonada aquella especificación.
  • El informe Priority Hints del WICG dejó de ser la referencia cuando sus partes pertinentes pasaron a HTML y Fetch. El fetchpriority actual ofrece high, low y auto frente a recursos del mismo destino; Fetch mantiene una prioridad interna distinta.

Una portada digital reúne peticiones que no valen lo mismo para quien lee. La fotografía de apertura puede explicar el titular; una imagen ornamental al final del texto puede esperar. El orden en que aparecen en el documento tampoco describe necesariamente esa importancia. Pero el navegador administra más que la intención del editor: compite con otras solicitudes y trabaja bajo límites de red y aparato. La historia de las pistas de prioridad transcurre justo en esa fricción.

El primer borrador público del W3C, fechado el 29 de octubre de 2013, se llamaba Resource Priorities. Proponía pistas programables, entre ellas lazyload, postpone y una propiedad CSS. lazyload trataba los recursos de menor urgencia cuando había competencia; postpone planteaba aplazar una descarga hasta que el elemento entrara en la zona visible o se acercara a ella. Su argumento era que descargar en el orden del documento no siempre mejora lo que percibe la persona. El borrador registra una propuesta, no una cifra de adopción.

La nota de trabajo del 23 de octubre de 2014 hizo algo poco frecuente en la prosa normativa: declaró que el grupo dejaba de mantener la especificación y que esta había sido abandonada. Remitió a resource hints. Conservó lazyload; la sección de postpone ya no estaba. En ese punto, la cronología no autoriza a presentar el atributo actual como una simple versión rehecha de aquellos dos nombres. Comparten el problema de la cola, pero los documentos no prueban una descendencia directa.

Más tarde apareció otro recorrido. El informe Priority Hints del WICG de 22 de febrero de 2023 formuló una señal de prioridad relativa para que el navegador la considerara al obtener recursos. Hoy el propio informe se marca obsoleto porque sus partes relevantes se incorporaron a HTML y Fetch. Una especificación quedó abandonada; el texto operativo de otra cambió de casa. «Obsoleto» puede ser lápida o cartel de mudanza. Conviene mirar el motivo antes de escribir la historia.

El estándar HTML vigente enumera tres estados para fetchpriority: high, low y auto. Su comparación se hace con otros recursos del mismo destino. Tanto la omisión como un valor inválido conducen a auto. Ese detalle restringe la fanfarronería del «todo primero»: el autor no obtiene un pase universal para adelantar cualquier descarga. Puede marcar diferencias dentro de una clase de recursos.

El estándar Fetch separa dos campos. Una solicitud tiene prioridad high, low o auto, y también una prioridad interna que puede tomar una forma definida por la implementación. La diferencia describe bien el reparto. La página aporta conocimiento sobre el contenido; el navegador conserva su propio cálculo operativo. Si la red se estrecha o el dispositivo se satura, la nota del editor entra en una decisión más amplia.

Pensemos en una imagen principal marcada como alta frente a otras imágenes decorativas. El editor aporta una pista que los bytes aún no pueden contar. El navegador decide cómo usarla. Los cinco textos permiten reconstruir esta arquitectura; no calculan los milisegundos ahorrados por un sitio concreto. La invención que perdura es la conversación entre quien conoce la importancia y quien debe gestionar la cola.