Entrevista Backend: Explicación de HTTP 103 Early Hints y los trade-offs de Preload

Prompt y contexto

Esta pregunta sobre HTTP, gateways y rendimiento es adecuada para roles de backend, plataforma e infraestructura. El origen tiene un tiempo de espera predecible antes de que el HTML final esté listo. Debe decidir si enviar 103 y evitar precargas incorrectas, fallos de parseo en clientes antiguos y descargas duplicadas.

Qué evalúa el entrevistador

• Distinguir la semántica de las pistas 103 de la semántica de la respuesta final.
• Usar el tiempo de procesamiento del servidor (think time), la estabilidad de los recursos y los aciertos de caché para evaluar el valor.
• Diseñar un fallback elegante en HTTP/2 o HTTP/3 en lugar de convertir 103 en una ruta obligatoria.
• Verificar que la precarga no genere solicitudes duplicadas, recursos incorrectos o exceso de ancho de banda.

Preguntas de clarificación

Confirme si la espera proviene de la generación dinámica de HTML o de la transferencia de red, si la solicitud es una navegación de nivel superior, si los clientes y proxies manejan 1xx de manera confiable, si las URL de los recursos, versiones y valores de as son estables, y si los recursos son almacenables en caché. Si la respuesta final se puede enviar de inmediato, un encabezado Link normal o un elemento link de HTML es más simple. Si los recursos varían con la autenticación, redirecciones o personalización, las pistas tempranas incorrectas pueden costar más de lo que ahorran.

Estructura de respuesta en 30 segundos

103 es una pista previa a la respuesta final, no el resultado de la página. Mientras genera HTML, el origen puede enviar 103 con Link: rel=preload o preconnect para que el cliente prepare los recursos en paralelo; el 200 final aún proporciona los encabezados autoritativos. Habilítelo solo cuando el tiempo de procesamiento del servidor sea significativo, las predicciones sean estables y HTTP/2 o HTTP/3 sean confiables. Mida el uso de caché, las descargas duplicadas, el LCP, los errores y el ancho de banda, con un fallback normal a la respuesta final para clientes más antiguos.

Análisis detallado paso a paso

1. Encuentre la ventana de optimización. Mida el tiempo de espera entre la recepción de la solicitud y la disponibilidad del HTML final. Si el origen devuelve rápidamente 200, 103 no tiene una brecha útil; mantenga la precarga ordinaria en la respuesta final.
2. Defina la semántica de 103. 103 indica que es probable que la respuesta final incluya estos campos. Un cliente puede prepararse especulativamente, pero la pista no puede reemplazar ni cambiar la semántica de la respuesta final.
3. Elija el contenido de la pista. Prefiera CSS, scripts u orígenes de conexión estables, críticos y almacenables en caché. La versión del recurso, el tipo de medio y las credenciales de origen cruzado deben coincidir con la respuesta final; no sugiera recursos personalizados inciertos.
4. Restrinja el protocolo y los clientes. Prefiera HTTP/2 o HTTP/3 y verifique que los proxies, navegadores y rutas de observabilidad manejen 1xx correctamente. Deshabilite o degrade para clientes HTTP/1.1 antiguos que puedan tratar 103 como final.
5. Maneje la respuesta final. El 200/3xx/4xx final decide el resultado de la página. Si una pista 103 resulta incorrecta, el cliente sigue la respuesta final; un intermediario no debe almacenar en caché la pista como el objeto final.
6. Mida el valor y el costo. Compare el LCP de primera vista, los aciertos de recursos, las descargas duplicadas, el ancho de banda y los errores antes y después. Si las redirecciones, el almacenamiento en caché deshabilitado o las variantes de recursos desperdician precargas, reduzca el conjunto de páginas o elimine 103.

Respuesta modelo

No habilitaría 103 en todas partes solo porque parece más rápido. Primero verificaría un tiempo significativo de generación dinámica de HTML y una navegación de nivel superior. Si las URL de CSS y scripts críticos, las versiones, as y el comportamiento del caché son estables, enviaría pistas a través de HTTP/2 o HTTP/3:

HTTP/2 103 Early Hints
Link: </style.abc.css>; rel=preload; as=style
Link: </app.abc.js>; rel=preload; as=script

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Link: </style.abc.css>; rel=preload; as=style

La respuesta final sigue siendo autoritativa; 103 no promete que se utilizará un recurso. Para clientes antiguos, proxies no confiables o páginas donde las redirecciones y la personalización cambian los recursos, recurro a los encabezados Link normales en la respuesta final. Ejecutaría un experimento midiendo el tiempo de espera del servidor, LCP, aciertos de caché, descargas duplicadas, ancho de banda y 4xx/5xx. Si las pistas no cubren una brecha real, elimino 103.

Errores comunes

• Tratar 103 como el estado final → el cliente puede pensar que la página tuvo éxito → explique que la respuesta final decide el resultado.
• Copiar cada recurso HTML en 103 → los recursos personalizados o no almacenables en caché se descargan dos veces → sugiera solo recursos críticos estables.
• Ignorar la compatibilidad de protocolos y proxies → los clientes antiguos pueden analizar 1xx incorrectamente → prefiera HTTP/2/3 y proporcione fallback.
• Medir solo LCP → el ancho de banda de precarga desperdiciado puede ocultar una ganancia local → monitoree también las solicitudes duplicadas, el caché y los errores.
• Omitir encabezados finales autoritativos → las pistas no son metadatos finales → repita los campos Link requeridos en la respuesta final.

Preguntas de seguimiento

¿En qué se diferencia 103 de HTTP/2 Server Push?

103 permite que el cliente decida si buscar el recurso; Server Push envía recursos de forma proactiva y puede enviar recursos que el cliente ya tiene en caché. Cuando el estado del caché es incierto, 103 facilita evitar transferencias innecesarias.

¿Qué sucede si la respuesta final redirige a otro origen (cross-origin)?

Las conexiones o recursos iniciados tempranamente pueden descartarse, convirtiendo la pista en un costo adicional de ancho de banda y conexión. Habilítelo solo para puntos de entrada estables e incluya la tasa de redirección en el experimento.

¿Cómo maneja las versiones dinámicas de los recursos?

Use una URL con hash de contenido conocido, o sugiera únicamente una versión que garantice coincidir con la respuesta final. Si la versión es desconocida, espere al HTML final en lugar de adivinar.

¿Por qué no enviar 103 en todas las páginas?

Sin tiempo de procesamiento del servidor no hay trabajo paralelo que exponer, y las navegaciones más profundas pueden haber almacenado ya en caché los recursos críticos. Despliegue por página de entrada, protocolo, comportamiento de caché y valor medido.