Problema y escenarios aplicables
La generación de HTML es lenta y el conjunto de recursos varía según el usuario, el experimento o la autorización. Diseña una política de predicción que genere 103 Early Hints por ruta y cohorte, con un umbral de confianza explícito, un límite de privacidad y control de predicciones erróneas.
Esto encaja en entrevistas de backend, edge-gateway y de ingeniería de rendimiento. Asume que la solicitud finalmente devuelve una respuesta 2xx o una redirección, y que el conjunto de recursos puede variar según el usuario, el experimento o la autorización.
Qué está evaluando el entrevistador
- Si comprendes que 103 es una sugerencia provisional, no una respuesta final ni un estado de negocio.
- Si la certeza del recurso, la versión del protocolo y el comportamiento cross-origin impulsan la decisión de enviar u omitir.
- Si puedes manejar discrepancias entre la sugerencia y la respuesta final, redirecciones y límites de CSP.
- Si utilizas métricas reales de navegadores, cachés y protocolos por capas en lugar de basarte únicamente en el tiempo del servidor.
Preguntas de aclaración antes de responder
- ¿Se conocen los recursos antes de la generación final del HTML? La incertidumbre hace que las descargas especulativas sean un desperdicio.
- ¿La conexión es HTTP/2 o más reciente? Los clientes heredados de HTTP/1.1 pueden manejar incorrectamente las respuestas informativas.
- ¿Qué recursos merecen una sugerencia? El CSS crítico, las fuentes y el precalentamiento de la conexión tienen beneficios diferentes en comparación con las imágenes de baja prioridad.
- ¿Existen redirecciones cross-origin, CSP, cohortes de usuarios o diferencias de autorización? Cada uno de ellos cambia la validez de la sugerencia.
Un marco de respuesta en 30 segundos
“Trato a 103 como una sugerencia de rendimiento descartable y solo envío recursos Link de alta confianza que probablemente aparezcan en la respuesta final. Lo condiciono a HTTP/2 o más reciente, derivo la lista en el límite de la CDN/origen y lo omito cuando las redirecciones o los recursos específicos del usuario hacen que la predicción sea incierta. La respuesta final sigue llevando el Link autoritativo y la CSP, y la lógica de negocio nunca depende de 103. En un canary mido la llegada, el tiempo de adelanto, la tasa de precargas útiles, las descargas duplicadas y los errores; lo desactivo si no hay ganancias visibles para el usuario”.
Análisis detallado paso a paso
1. Desacoplar las sugerencias de la respuesta de negocio
El RFC 8297 define 103 como una respuesta informativa: un cliente puede procesar encabezados de forma especulativa mientras espera, pero no debe tratarlos como metadatos finales. Envía únicamente sugerencias de rendimiento, nunca autorización, precios o estado de éxito. La respuesta final debe seguir siendo correcta cuando un proxy descarta 103.
2. Elegir encabezados Link de alta certeza
Prioriza CSS above-the-fold, fuentes o preconnect hacia una CDN fija. Si las cohortes, los permisos o los experimentos cambian el conjunto de recursos, calcula una intersección segura u omite la sugerencia. Una sugerencia no es una descarga forzada; as, CORS y CSP siguen rigiendo la obtención.
3. Establecer filtros de protocolo y redirección
Haz de HTTP/2 o superior el filtro predeterminado por compatibilidad y seguridad. Cuando una solicitud termina en una redirección cross-origin, un navegador puede descartar el primer 103; una pasarela también puede fusionar o reordenar respuestas informativas. Prueba la cadena de proxies en el canary para que 103 nunca se confunda con la respuesta final.
4. Manejar la CSP y la desviación de la respuesta final
103 puede llevar una CSP que restrinja las cargas especulativas, pero la respuesta final sigue siendo la autoritativa. Si el servidor descubre más tarde un recurso incorrecto, es posible que el cliente ya haya iniciado su descarga. Limita las sugerencias a activos de bajo riesgo, almacenables en caché y que se puedan descartar con seguridad; nunca uses 103 para eludir la CSP final.
5. Verificar con métricas por capas
Mantén un grupo de control sin 103 y habilítalo solo para HTTP/2 o posterior en el experimento. Mide la llegada de 103, el tiempo de adelanto de los recursos, el ratio de precargas útiles, las solicitudes duplicadas, el LCP final, el ancho de banda y los errores. Segmenta por acierto de caché, redirección cross-origin y dispositivo; si el TTFB mejora pero el LCP no, reviértelo.
Respuesta de ejemplo de alta calidad
Primero me aseguraría de que 103 solo transporte sugerencias de rendimiento y de que la respuesta final no dependa de él. Para HTTP/2 o superior, sugeriría únicamente CSS above-the-fold de alta confianza, fuentes o una conexión a una CDN fija; las cohortes de usuarios, la autorización o las redirecciones cross-origin que hagan incierto el conjunto de recursos provocan una omisión. El canary de la pasarela y del navegador debe demostrar que las respuestas informativas no se tratan como finales, mientras que la respuesta final repite el Link y la CSP autoritativos. Compararía la llegada, la tasa de aciertos útiles, las descargas duplicadas, el LCP, el ancho de banda y los errores según la caché y el dispositivo; si solo mejora el TTFB del servidor, desactivaría Early Hints.
Errores comunes
- Síntoma: Tratar 103 como una respuesta de éxito. Por qué falla: no tiene semántica de finalización de negocio y puede ser descartada. Solución: completa la autorización, el estado y el cuerpo en la respuesta final.
- Síntoma: Precargar cada recurso. Por qué falla: las páginas dinámicas generan descargas desperdiciadas, contención de ancho de banda y contaminación de la caché. Solución: sugiere solo activos de alta certeza y establece un umbral de aciertos útiles.
- Síntoma: Ignorar HTTP/1.1 y la cadena de proxies. Por qué falla: los clientes más antiguos pueden procesar incorrectamente las respuestas informativas. Solución: añade un filtro de protocolo, pruebas de proxy y un interruptor de emergencia.
- Síntoma: Medir solo el TTFB. Por qué falla: las sugerencias tempranas pueden no mejorar el renderizado y pueden competir por el ancho de banda. Solución: mide el LCP, duplicados, ancho de banda y errores.
Preguntas de seguimiento y respuestas
¿Qué pasa si un recurso sugerido ya no se necesita?
Limita las sugerencias a activos especulativos seguros y pon un límite a la tasa de descargas inválidas. 103 no puede garantizar que se utilizará un recurso.
¿Deberías seguir enviando 103 a través de una redirección cross-origin?
Omítelo por defecto, o restríngelo al precalentamiento de conexión seguro que no esté relacionado con el destino final. Los navegadores pueden descartar el primer 103 y los proxies pueden reordenar las respuestas, así que decide a partir de una prueba de extremo a extremo.
¿Puede el Link final diferir del Link en 103?
Sí: 103 es una sugerencia y la respuesta final es la autoritativa. Una discrepancia grande indica un mal predictor, así que reduce el conjunto de sugerencias y monitorea los duplicados.
¿Cómo evitas que 103 filtre información del usuario?
No incluyas autorización, cohortes ni URLs sensibles. Genera sugerencias a partir de un conjunto de activos públicos de bajo riesgo, mientras las comprobaciones de autorización y CSP finales permanecen activas.
¿Cuándo es mejor el preload en HTML ordinario que 103?
Usa el preload en el HTML final cuando los activos se conozcan únicamente después de la generación del HTML o cuando las respuestas informativas no puedan entregarse de manera confiable. 103 es útil cuando el servidor conoce el conjunto de activos antes de poder producir el HTML.