Pregunta y contexto
El origen puede emitir 103 con Link antes de la respuesta final, pero el tráfico de producción aún atraviesa un terminador TLS, un balanceador de carga, un proxy inverso y una CDN. Diseña una matriz de compatibilidad de extremo a extremo, un switch canary, un respaldo transparente y un plan de observabilidad que demuestre que la respuesta 1xx llega a los navegadores compatibles.
Qué evalúa el entrevistador
Las respuestas sólidas distinguen las respuestas provisionales de las finales, seleccionan recursos de alta confianza, discuten HTTP/2, HTTP/3, proxies y CDN, y proporcionan un respaldo transparente cuando se ignora 103. También cubren sugerencias incorrectas, riesgos de caché y de origen cruzado, y mediciones del beneficio real para el usuario.
Preguntas para aclarar
- ¿Qué tan temprano y con qué nivel de confianza puede conocer el servidor el conjunto de recursos?
- ¿El cliente, el terminador TLS, el proxy inverso y la CDN preservan las respuestas 1xx?
- ¿Están versionados los recursos y es necesario
preconnectde origen cruzado? - ¿El objetivo es el LCP, la brecha posterior al TTFB o el descubrimiento más temprano de CSS y fuentes?
- ¿Cómo se observan y gestionan los errores, los aciertos de caché y los clientes sin 103?
Respuesta en 30 segundos
Antes de la respuesta final, enviaría 103 con un pequeño conjunto de sugerencias Link de alta confianza y luego enviaría la respuesta final normal. Los recursos utilizan URL versionadas y las conexiones de origen cruzado se limitan a dominios de confianza. Ignorar 103 debe dejar la página correcta porque el HTML final todavía hace referencia a los recursos. Compararía las rutas compatibles y no compatibles mediante trazas y RUM para LCP, tiempo de descubrimiento, bytes duplicados y errores antes de expandir la cobertura.
Respuesta detallada paso a paso
Paso 1: Comprender los tiempos
103 es una respuesta provisional informativa y debe ir seguida de una respuesta final. Puede transportar sugerencias como Link: </app.css>; rel=preload; as=style mientras el servidor está trabajando. Que un cliente actúe sobre ellas depende de la pila de protocolos, el navegador y la política; la corrección del negocio no debe depender de ellas.
Paso 2: Seleccionar recursos
Sugiere únicamente recursos que sean casi seguros, de tamaño razonable y estables: CSS crítico, fuentes o un preconnect. Evita imágenes de baja probabilidad, scripts personalizados y recursos dependientes de permisos que desperdicien ancho de banda o precarguen el elemento incorrecto.
HTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8Paso 3: Verificar intermediarios y respaldo
Prueba la ruta real del balanceador de carga, la terminación TLS, la CDN y el navegador para reenviar o consumir 103. Un cliente que lo ignore aún debe recibir referencias ordinarias en la respuesta final; nunca hagas que una página dependa de un mensaje provisional.
Paso 4: Acotar los efectos de caché y seguridad
Las sugerencias deben coincidir con el contexto de la solicitud actual. Usa URL con hash de contenido y Cache-Control correcto; nunca construyas valores arbitrarios de Link a partir de la entrada del usuario. preconnect de origen cruzado revela la intención de conexión y consume recursos, así que permite solo orígenes de confianza y parámetros necesarios.
Paso 5: Evitar precargas incorrectas
Si la autenticación, los experimentos o la geografía cambian el conjunto de recursos, espera a tener mayor confianza u omite la sugerencia. Si la respuesta final ya no hace referencia a un recurso sugerido, es posible que el navegador haya desperdiciado una descarga; mide ese costo.
Paso 6: Observar y revertir
Registra si se envió 103, el estado final, el tiempo de descubrimiento, el acierto de caché, los bytes duplicados y las diferencias por proxy. Controla el despliegue por ruta o tráfico mediante un feature flag. Desactiva las sugerencias si el ancho de banda, los errores o las métricas de usuario empeoran; el HTML final permanece sin cambios.
Compensaciones y límites
103 frente a enlaces de precarga
103 adelanta una sugerencia, mientras que el link del HTML ordinario sigue siendo la referencia autoritativa final. Deben coincidir para evitar descargas duplicadas o conflictos de prioridad. Las sugerencias no reemplazan CSP, la integridad ni la política de permisos.
Versiones de protocolo e intermediarios
RFC 8297 define la semántica, pero una cadena de proxies puede descartar respuestas 1xx. Mide las combinaciones reales de HTTP/2, HTTP/3, CDN y clientes, y mantén una línea base sin 103.
Plan de despliegue y evidencia
Lanzamiento gradual
Comienza con CSS estático en una ruta, verifica la respuesta final y las referencias, y luego expande a fuentes o preconnects seguros. Mantén un interruptor de emergencia (kill switch) y compara las primeras visitas, las visitas en caché y las redes lentas por separado.
Métricas y aceptación
Haz seguimiento de LCP, tiempo de descubrimiento de recursos, bytes duplicados, tasa de aciertos de caché, 4xx/5xx y ancho de banda. Concilia las herramientas del navegador, los registros perimetrales (edge logs) y RUM; los registros de envío del servidor por sí solos no pueden probar el comportamiento del cliente.
Errores comunes y preguntas de seguimiento
Error: tratar 103 como un éxito final
El estado del negocio, el almacenamiento en caché y los errores utilizan la respuesta final; perder 103 no debe fallar la solicitud.
Error: sugerir todos los recursos
Los recursos de baja confianza desperdician ancho de banda y conexiones. Prefiere un conjunto crítico, pequeño y estable.
Error: probar únicamente una ruta local directa
Las CDN, los proxies y la terminación TLS de producción pueden cambiar el comportamiento de 1xx; prueba de extremo a extremo.
Pregunta de seguimiento: ¿qué pasa si no se admite 103?
Confía en las referencias habituales del HTML final y en el almacenamiento en caché existente. La corrección se mantiene; solo se pierde la posible ganancia de rendimiento.
Pregunta de seguimiento: ¿cómo demuestras que vale la pena mantenerlo?
Ejecuta un experimento dividido (split test) para LCP, descubrimiento, bytes duplicados, errores y ancho de banda, segmentado por condiciones de caché y de red.