Resumen

  • Los campos de una respuesta 103 son una previsión, no una copia adelantada de la respuesta final. El cliente puede iniciar un preload, pero debe procesar después el resultado definitivo con independencia de la pista.
  • El origen o un intermediario pueden proponer trabajo; el navegador decide si lo admite; el estado final resuelve la navegación; y el recurso insinuado aún debe superar sus propios controles de red, identidad, política y uso.

La petición llega a una aplicación que todavía consulta sesión y base de datos. Quizá devuelva el panel solicitado, quizá redirija al inicio de sesión, quizá falle. En el borde queda una respuesta antigua donde shell.css aparecía como recurso crítico. Si el navegador espera, pierde una oportunidad. Si actúa, puede gastar en una página que nunca se servirá.

RFC 8297 formaliza esa incertidumbre con 103 Early Hints. El servidor envía algunos campos que probablemente repetirá más tarde y continúa preparando el resultado. Ante un Link con relación preload, el cliente puede empezar a recuperar el destino.

El nombre del estado evita una promesa excesiva. La pista no declara éxito, no garantiza que el campo sobreviva y no obliga al navegador. Ofrece una opción temporal antes de que exista una respuesta completa.

Una pista no ocupa el lugar del resultado

RFC 9110 define las respuestas 1xx como intermedias. Una petición puede recibir varias y, después, una respuesta final. Las 1xx terminan al acabar su sección de campos y no llevan contenido. Un agente de usuario puede ignorar una respuesta informativa inesperada.

El límite normativo de RFC 8297 es aún más claro: evaluar los campos de 103 para optimizar rendimiento no debe alterar el procesamiento de la respuesta final. Si llega 302, el resultado es una redirección; si llega 500, la existencia previa de una pista no lo convierte en 200.

Tampoco puede leerse la ausencia. Un campo que no figura en 103 puede aparecer en el resultado porque aún no se conocía. La respuesta temprana puede contener solo una parte de lo esperado. Y puede equivocarse: es válido que varios 103 acumulen candidatos y que el conjunto final cambie uno de ellos.

El protocolo acepta esa discrepancia porque la certeza completa llegaría demasiado tarde para servir de pista. La condición es no dejar que la ventaja cronológica se transforme en autoridad semántica.

Cuatro decisiones que no se heredan

El origen decide el estado final y sus campos. Puede publicar una previsión, pero no delega esa decisión. Un intermediario también puede generar 103. El propio RFC describe un caché que usa campos de una respuesta caducada mientras revalida y luego reenvía las respuestas del origen.

El navegador decide qué trabajo especulativo admite. Puede ignorar, consultar caché, limitar bytes, aplazar una conexión o descartar el valor tras una redirección. Un enlace no fija la prioridad de la cola local.

La respuesta final decide qué ocurrió con la navegación. El documento puede no existir o puede estar en otro origen. Por último, el recurso tiene un resultado independiente: DNS, conexión, TLS, credenciales, estado HTTP, tipo, integridad y política determinan si sus bytes son utilizables.

RFC 8288 define un enlace como contexto, relación, destino y atributos. Esa estructura expresa una relación entre recursos; no autentica el destino ni promete que una operación sobre él vaya a terminar bien.

La implementación web establece sus propios límites

El estándar HTML procesa Early Hints durante navegaciones. El algoritmo actual atiende la primera pista temprana y la descarta si después aparece una redirección entre orígenes.

En ese momento solo maneja un conjunto acotado de atributos de precarga: as, crossorigin, integrity y type. Otros necesitan que exista un Document. Los enlaces de la pista se estudian antes que los de la respuesta final y los elementos del documento, pero llegar antes no equivale a prevalecer.

La política de seguridad también conserva control. Una CSP temprana puede gobernar el fetch especulativo; una política final más estricta puede impedir que el documento use una respuesta ya obtenida. El coste ocurrió, pero no compró derecho de uso.

El estándar Fetch trata 103 como un paso intermedio y continúa hasta el resultado definitivo. El trabajo adelantado pertenece a la petición; no la sustituye.

El caché conoce el pasado, no el presente

Generar la pista desde una respuesta antigua puede ser una buena optimización. La interfaz y su hoja de estilos suelen ser estables. También puede ser una predicción equivocada después de un despliegue, un cambio de sesión o una ruta personalizada.

Por eso la procedencia forma parte de la evidencia. Un operador debe saber si la pista salió de la aplicación, de una regla del CDN o de metadatos caducados. Los campos tempranos y finales deben guardarse como dos objetos. Si diferentes capas emiten candidatos, sus desacuerdos no pueden desaparecer bajo una sola métrica de “preloads enviados”.

El diseño correcto concede valor al pasado sin convertirlo en verdad presente. El borde predice, el cliente valora el precio y el origen termina la respuesta.

La especulación deja huella aunque no deje contenido

Un destino inútil consume algo real: solicitud DNS, conexión, energía, ventana de congestión, carga del origen y quizá información revelada a un tercero. Puede competir con el HTML o la imagen que sí determinarán la experiencia. El resultado final puede renunciar al recurso, pero no recuperar los paquetes enviados.

El indicador relevante es la reutilización útil. Hay que enlazar la recepción de 103 con el inicio adelantado, la respuesta de red o caché, la reconciliación con los campos finales, la aceptación de políticas y el consumo efectivo por el documento. Los milisegundos ganados deben compararse con bytes y solicitudes sin uso.

La compatibilidad tampoco se presume. RFC 8297 advierte que un cliente HTTP/1.1 que confunda una respuesta informativa con una final puede desordenar el encuadre de mensajes posteriores en una conexión persistente y abrir una fuga entre orígenes. El servidor puede evitar 103 en HTTP/1.1 si no conoce al cliente. HTTP/2 reduce ese riesgo concreto de encuadre, no la posibilidad de una mala pista.

El registro IANA confirma que 103 significa Early Hints. No confirma que un proxy lo conserve, un navegador actúe o un usuario perciba mejora.

La especificación común mínima con decisiones locales de Lu Heng explica por qué este mecanismo puede permanecer ligero. Todos comparten un significado pequeño: estos campos son provisionales y habrá una respuesta final. La adopción y el gasto se deciden en cada implementación. La primacía del código en ejecución exige observar mensajes, acciones y resultados.

La prueba final no es una gráfica más rápida. Es poder apagar 103 y seguir obteniendo una página completa y correcta. Si no ocurre, la optimización ha adquirido una autoridad que el protocolo nunca le dio.