Resumen

  • El primer borrador público de Resource Hints del W3C, de octubre de 2014, propuso preconnect para un origen conocido antes de conocer la URL completa del recurso. La preparación podía incluir consulta DNS, negociación TCP y, cuando correspondiera, TLS.
  • En los borradores posteriores, dns-prefetch, preconnect, prefetch y prerender señalaron trabajos distintos. El navegador conservó la decisión de abrir una conexión completa, hacer solo parte del trabajo o no seguir la sugerencia.

El visitante recorre una galería. La página sabe dónde viven las fotografías, pero no cuál elegirá. No tiene sentido descargar una foto al azar y llamarlo previsión; sí puede interesar tener iniciada la relación con el servidor que entregará la elegida. El problema cotidiano era el tiempo muerto entre conocer una dirección de origen y conocer un archivo. preconnect quiso aprovechar ese intervalo.

El primer borrador público del W3C, del 21 de octubre de 2014, describió la indicación de conexión anticipada. Saber el origen permitía adelantar la búsqueda DNS, el saludo TCP y, en una conexión protegida, la negociación TLS. El mismo texto trataba preload, una operación diferente que mira un recurso determinado. Reservar mesa en el restaurante no equivale a mandar traer todos los platos.

Para el borrador del 4 de mayo de 2017, la familia estaba mejor separada. dns-prefetch pide resolver el nombre. preconnect apunta a preparar la conexión con un origen. prefetch mira hacia un recurso que quizá haga falta en la siguiente navegación. prerender puede procesar un futuro documento. El orden expresa cantidades crecientes de trabajo y de apuesta. Una pista sobre dónde está el servidor no adivina qué solicitará la persona.

El borrador del 27 de junio de 2019 explicaba el caso de la URL dinámica: a veces el origen se conoce pronto, mientras la ruta completa aparece durante la construcción de la página. Si la negociación con el servidor ya empezó, la petición concreta puede salir sin esperar a montar desde cero la conexión. La idea no necesitaba una bola de cristal; le bastaba con una libreta de direcciones.

Claro que cada saludo anticipado consume algo. El borrador del 5 de octubre de 2020 deja al agente de usuario hacer el saludo completo, solo una parte o nada. También le deja decidir cuántas conexiones abrir a cada origen. Pesan el protocolo, los límites globales, la red y la capacidad del dispositivo. Una página puede recomendar diez restaurantes; el navegador aún tiene que cuidar el presupuesto de la noche.

La especulación que no se utiliza tiene un coste, y muchas conexiones tempranas pueden competir con los recursos que la página necesita ahora. El texto de 2020 indica que los trabajos preconnect pendientes no deben retrasar el evento de carga del documento. La promesa de una visita futura no debe convertirse en una cola para quien ya está esperando delante de la pantalla.

La historia de publicaciones del W3C sitúa el primer borrador en octubre de 2014 y recoge las versiones posteriores. Son borradores que fueron afinando los límites entre resolver un nombre, abrir una conexión y traer contenido. Su centro es una decisión repartida: la página aporta conocimiento adelantado del origen y el navegador decide qué trabajo le conviene hacer. La mesa queda preparada cuando el comensal realmente va a llegar.