¿Cómo medirías Early Hints con firstInterimResponseStart?

Pregunta y contexto

Los navegadores están incorporando PerformanceResourceTiming.firstInterimResponseStart, que registra cuándo llega el primer byte de una respuesta provisional 1xx. Implementa un observador para evaluar si 103 Early Hints reduce el tiempo de preparación de recursos, incluyendo casos no compatibles, cross-origin y en caché.

Qué está evaluando el entrevistador

• Si comprendes requestStart, firstInterimResponseStart y la sincronización de los encabezados de respuesta finales.
• Si sabes que el valor cero puede significar ausencia de 1xx, enmascaramiento cross-origin o una marca de tiempo no disponible relacionada con la caché.
• Si puedes usar PerformanceObserver con entradas almacenadas en búfer (buffered entries) y reportes muestreados.
• Si separas el beneficio a nivel de protocolo del soporte del navegador, Timing-Allow-Origin y las métricas de producto.

Preguntas aclaratorias para hacer primero

Objetivo de medición

¿Estamos midiendo el tiempo hasta el primer 1xx, la cantidad de precargas (preloads) de Early Hints o los resultados del usuario como LCP y la preparación para la interacción?

Alcance de los recursos

¿Deberíamos observar solo la navegación del mismo origen (same-origin), o también recursos de CDN, fuentes y scripts cross-origin? ¿Está configurado Timing-Allow-Origin?

Política de compatibilidad

¿Los datos impulsarán una decisión en tiempo real? ¿Los navegadores antiguos deben proporcionar una métrica de respaldo equivalente cuando la propiedad no esté disponible?

Estructura de respuesta en 30 segundos

Utilizaría un PerformanceObserver y calcularía firstInterimResponseStart - requestStart solo cuando la propiedad exista y sea distinta de cero. El valor cero no puede demostrar que el servidor omitió el 103 porque la sincronización cross-origin puede estar enmascarada y las rutas de caché pueden exponer un cero. La telemetría debe registrar el soporte, el alcance del origen y la sincronización de la respuesta final, para luego validar Early Hints contra métricas de usuario como LCP.

Pasos detallados de la respuesta

1. Explicar las marcas de tiempo

requestStart es cuando el navegador está a punto de solicitar el recurso; firstInterimResponseStart es cuando llega el primer byte de una respuesta 1xx; finalResponseHeadersStart es cuando llegan los encabezados de respuesta finales. Cuando existe una respuesta provisional, la primera diferencia aproxima la espera de la red hasta ese 1xx.

2. Escribir el observador

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const interim = entry.firstInterimResponseStart;
    if (typeof interim !== "number" || interim <= 0) continue;

    reportTiming({
      name: entry.name,
      interimWait: interim - entry.requestStart,
      finalHeaders: entry.finalResponseHeadersStart - interim,
      initiator: entry.initiatorType,
    });
  }
});

observer.observe({ type: "resource", buffered: true });

El código de producción debe detectar las funciones de la propiedad y limitar los nombres, el muestreo y los campos para que URLs completas o parámetros de consulta confidenciales no entren en la analítica.

3. Interpretar el valor cero correctamente

Cero puede significar que no hubo respuesta provisional, o que un recurso cross-origin no expuso los tiempos a través de Timing-Allow-Origin; los aciertos de caché (cache hits) y las solicitudes canceladas también pueden producir cero para las marcas de tiempo relacionadas. Los paneles deben separar "no observado" de "ausencia de 1xx confirmada" y nunca convertir cero en una duración negativa o una falla automática.

4. Manejar recursos cross-origin

Si una CDN o fuente es cross-origin, el servidor debe devolver Timing-Allow-Origin para el sitio permitido antes de que se expongan los campos de temporización protegidos. Configura ese encabezado para los orígenes de implementación reales en lugar de para todos los orígenes, y acepta que algunos usuarios permanezcan inobservables debido a las políticas.

5. Separar 103 del beneficio para el usuario

La propiedad reporta el tiempo del primer 1xx; no identifica si es 103 ni demuestra que se utilizó una precarga. Confirma 103 con datos de navegación, registros del servidor o un experimento controlado, luego compara finalResponseHeadersStart, responseEnd del recurso y LCP. Una precarga temprana o incorrecta puede perjudicar el rendimiento incluso cuando el primer 1xx llega rápidamente.

6. Diseñar el respaldo de compatibilidad

Los navegadores no compatibles aún pueden reportar métricas comunes como requestStart, responseStart y responseEnd, pero no pueden inventar tiempos provisionales. Marca la capacidad y agrega las muestras antiguas y nuevas por separado; una API faltante no debe bloquear el renderizado.

7. Construir verificación y gobernanza

Compara casos de mismo origen y cross-origin en HTTP/2 o posterior, aciertos y fallos de caché, y servidores con y sin 103. Valida mediante aserciones que interimWait >= 0 y que los encabezados finales no precedan a la primera respuesta provisional. Limita la frecuencia de los reportes e interpreta los tiempos junto con LCP, la tasa de aciertos de precarga y la tasa de errores en lugar de tratar una marca de tiempo de red como un resultado de producto.

Ejemplo de respuesta de alta calidad

Utilizaría un PerformanceObserver con búfer y reportaría el tiempo de espera de 1xx solo cuando firstInterimResponseStart exista y sea distinto de cero. Preservaría el cero como indeterminado, segmentaría por origen, Timing-Allow-Origin, caché y capacidad del navegador, y verificaría 103 con experimentos controlados. Early Hints se mantiene solo si LCP, la tasa de aciertos de precarga y los errores mejoran, no meramente porque un byte provisional haya llegado antes.

Errores comunes

• Tratar un valor distinto de cero como prueba de que la respuesta fue 103.
• Tratar cada cero como prueba de que el servidor no envió ningún 1xx.
• Ignorar la brecha de datos provocada por la falta de Timing-Allow-Origin en recursos cross-origin.
• Usar responseStart como el tiempo de encabezado final y mezclar respuestas provisionales con finales.
• Llamar a getEntriesByType solo después de la carga y perder entradas registradas anteriormente.
• Monitorear los tiempos de red sin verificar LCP, los aciertos de precarga y los errores.

Preguntas de seguimiento y respuestas

¿Puede firstInterimResponseStart confirmar que fue 103?

No. Registra el primer byte de cualquier respuesta 1xx, incluyendo 100 Continue. Confirma 103 con registros del servidor, solicitudes controladas y el comportamiento de carga de recursos.

¿Por qué las entradas cross-origin suelen ser cero?

Resource Timing enmascara las marcas de tiempo cross-origin. Sin un Timing-Allow-Origin coincidente, los campos protegidos devuelven cero. Corrige la política de respuesta o clasifica la muestra como no observable; no inventes una estimación.

¿En qué se diferencian responseStart y finalResponseHeadersStart?

Con una respuesta provisional, responseStart puede reflejar el primer byte provisional, mientras que finalResponseHeadersStart representa los encabezados finales. Usa este último al medir la preparación del servidor antes de la respuesta final.

¿Cuál es el respaldo para navegadores más antiguos?

Detecta la presencia de la propiedad, continúa recopilando los tiempos comunes de solicitud y respuesta, y marca el campo provisional ausente. Agrega las muestras de navegadores antiguos por separado de las muestras con la nueva API.

¿Cómo demuestras que vale la pena mantener Early Hints?

Ejecuta cohortes habilitadas y deshabilitadas con la misma red, caché y versiones de activos. Compara LCP, tasa de aciertos de precarga, tiempo de encabezado final, finalización de recursos y errores; un 1xx temprano es solo evidencia intermedia.