Resumen

  • El primer borrador público de Resource Timing del W3C, del 24 de mayo de 2011, propuso medir recursos individuales como las imágenes mediante marcas de búsqueda de nombre, conexión, petición y respuesta.
  • La Recomendación Candidata de nivel 1 del 30 de marzo de 2017 situó las entradas en una línea de tiempo, describió un búfer finito y dejó al servidor externo decidir con Timing-Allow-Origin si revelar tiempos detallados.

La página tardaba y había una reunión de sospechosos. La imagen principal señaló la hoja de estilos. La hoja de estilos nombró al script. El script sugirió llamar al servidor. Saber cuánto había esperado el lector confirmaba el retraso, pero no identificaba el equipaje que atascaba la cinta. Resource Timing repartió cronómetros a los bultos. El sospechoso más lento ya no podía esconderse detrás del promedio familiar.

El primer borrador público de Resource Timing del W3C, fechado el 24 de mayo de 2011, empezó por la latencia dentro de una página. Su ejemplo calculaba el tiempo de obtención de una imagen. El reloj de la navegación del documento cubría otra escala: la página reúne fotografías, hojas de estilo y scripts que viajan por separado. Algunas piezas llegan después de que otras ya estén a la vista. Una cifra para la página entera revela el resultado final, pero borra la ruta de cada pieza.

El borrador describió una entrada con nombre del recurso, tipo de iniciador y momentos de su recorrido. fetchStart, domainLookupStart, connectStart, requestStart, responseStart y responseEnd permiten separar búsqueda de nombre, conexión, petición, espera de la respuesta y recepción. Un operador podía señalar una fase concreta antes de pedir arreglos. «Internet anda mal» era una explicación demasiado cómoda para un registro que ahora daba nombres y horas.

La lectura exigía contexto. Una conexión reutilizada no vuelve a establecerse como una nueva. Un recurso servido desde caché no repite todos los pasos de red. Por eso dos marcas iguales pueden contar una historia normal, no una avería del cronómetro. Comparar dos visitas sin indicar cuál llegó con la caché caliente sería como comparar dos viajes sin decir que uno empezó ya en la estación de destino. La entrada describe esa obtención particular, con sus condiciones.

En la Recomendación Candidata Resource Timing Level 1 del W3C de 30 de marzo de 2017, las entradas vivían en una línea de tiempo de rendimiento. El ejemplo recuperaba performance.getEntriesByType('resource'), seleccionaba los elementos con initiatorType igual a img y comparaba responseEnd con startTime. Las imágenes podían ponerse en fila y examinarse una a una. Hojas de estilo y scripts también dejaban rastro. La página ya no necesitaba comparecer como único acusado cada vez que una fotografía llegaba tarde.

El libro de entradas tenía un número limitado de páginas. El texto de 2017 explicaba el búfer de tiempos y operaciones como setResourceTimingBufferSize() y clearResourceTimings(). Una página con muchas peticiones podía llenar el espacio reservado. Quien recogía datos debía elegir su capacidad y el momento de limpiarlo. Si faltaban las últimas líneas, no era una prueba de que los últimos recursos hubiesen cruzado la red a velocidad sobrenatural. Tal vez se acabó el papel.

Había otra persona en la sala: el servidor que entregaba un recurso de otro origen. El navegador podía anotar la existencia y duración de esa obtención, pero limitaba por defecto los detalles de sus fases. El servidor del recurso podía enviar Timing-Allow-Origin para permitir que un origen concreto leyera más. Integrar una imagen ajena no daba al editor acceso automático al desglose de DNS, conexión y respuesta del proveedor. La llave del cronómetro detallado estaba en el mostrador ajeno.

Esto cambiaba la interpretación de los campos vacíos. Una entrada externa podía mostrar nombre y duración sin ofrecer las columnas finas. Tratar un valor limitado como «cero milisegundos de trabajo» equivalía a confundir una puerta cerrada con un trayecto instantáneo. Con permiso del proveedor, el navegador mostraba más fases; sin él, el sitio debía investigar con las pistas disponibles. La limitación formaba parte del dato.

El borrador de Recomendación Candidata del W3C del 1 de septiembre de 2026 continuó la idea de registrar cada recurso, con más atributos y un búfer descrito de mayor tamaño. Las fechas separan versiones distintas. El borrador de 2011, el texto candidato de 2017 y el borrador de 2026 no eran un único contrato inmóvil. Lo que perduró fue el formato compartido para preguntar cuánto tardó en llegar una pieza concreta y qué partes del trayecto podían verse.

Incluso una medición impecable necesita un editor. La imagen más lenta quizá está muy abajo, lejos de la primera pantalla; una pieza algo más rápida puede retrasar el titular que el lector quería. Resource Timing habla del traslado, mientras que el diseño habla de su importancia. Hay que juntar ambas lecturas antes de recortar una imagen, cambiar su entrega, adelantarla o dejarla para después. El cronómetro localiza una pista; no decide el orden de la redacción.

Así cambió la conversación. «La página va lenta» invitaba a repartir culpas. «Esta imagen esperó aquí; esa hoja reutilizó una conexión; el proveedor externo no abrió los detalles» permitía asignar trabajo. El cronómetro no reparaba la página, pero la imagen principal ya no podía acusar al CSS sin enseñar primero su propia ficha de llegada.