¿Qué son las conexiones de red en la velocidad de página?

¿Qué son las conexiones de red en la velocidad de página?

Una conexión de red es el canal que un navegador abre con un servidor antes de poder descargar nada. Establecerla cuesta tiempo: una resolución DNS, un handshake TCP y, en HTTPS, una negociación TLS. Una página que trae archivos de muchos servidores distintos paga ese coste muchas veces, así que cómo se abren, reutilizan y comparten las conexiones suele importar tanto como el tamaño de los archivos.

Cuánto cuesta una conexión nueva

La primera petición a un servidor incluye una resolución DNS, un handshake TCP y la negociación TLS segura. Las siguientes son más rápidas porque la conexión ya está abierta (MDN, "Understanding latency"). Cada paso es un viaje de ida y vuelta por la red, de modo que el coste crece con la distancia entre visitante y servidor. Por eso una conexión nueva duele más en redes móviles y para visitantes lejanos.

Ejemplo: una página carga sus propios archivos, un script de analítica, un host de fuentes, una red publicitaria y un widget de chat. Son cinco orígenes, es decir, cinco resoluciones DNS y cinco conexiones antes de que llegue el último byte, aunque cada archivo sea pequeño.

Reutilizar conexiones

• Conexiones persistentes (keep-alive). Una conexión persistente permanece abierta y se reutiliza para varias peticiones, evitando repetir el handshake. En HTTP/1.1 la persistencia es el valor por defecto; las conexiones inactivas se cierran pasado un tiempo (MDN, "Connection management in HTTP/1.x").
• Paralelismo en HTTP/1.x. HTTP/1.x atiende las peticiones una tras otra en cada conexión, así que los navegadores abren varias por dominio. Lo habitual son 6 conexiones paralelas, una cifra que MDN describe como típica y no como estándar fijo.
• Multiplexación en HTTP/2. HTTP/2 permite que peticiones paralelas compartan una conexión y comprime las cabeceras repetidas. Los trucos de HTTP/1 como el domain sharding dejan de ayudar y pueden perjudicar: usa menos orígenes. HTTP/3 también multiplexa y evita bloquear todos los flujos cuando se pierde un paquete (MDN, "Evolution of HTTP").

Calentar conexiones con antelación

Si sabes que la página necesitará otro origen, avisa al navegador pronto. <link rel="preconnect"> inicia por adelantado el trabajo de DNS, TCP y TLS, y solo ayuda en peticiones a otro origen. MDN aconseja reservarlo para los orígenes más críticos, porque hacer preconnect a muchos terceros puede resultar contraproducente. Para orígenes menos prioritarios, <link rel="dns-prefetch"> ahorra solo el paso DNS. Consulta la precarga de recursos para las pistas relacionadas y la referencia de MDN sobre preconnect para la sintaxis exacta.

Otras formas de reducir el coste de conexión

• Menos orígenes. Aloja tú mismo las fuentes y scripts críticos y elimina las etiquetas de terceros que no necesitas.
• Servir desde cerca. Una CDN acorta cada viaje de ida y vuelta y reduce el tiempo hasta el primer byte.
• No esperar a terceros. Carga los scripts no críticos con carga asíncrona para que una conexión lenta no detenga el renderizado.
• Usar versiones modernas de TLS y HTTP en el servidor y la CDN.

Errores frecuentes

• Hacer preconnect a una docena de orígenes "por si acaso". Cada uno consume una conexión y tiempo de CPU.
• Mantener hábitos de HTTP/1 tras pasar a HTTP/2, como repartir recursos entre subdominios.
• Probar solo desde una ubicación. El coste de conexión depende de la distancia, y una página rápida cerca del servidor puede ser lenta en otro lugar.
• Culpar al tamaño de los archivos cuando la cascada muestra barras largas de DNS, conexión o TLS.

Cómo medirlo

El panel de red del navegador divide cada petición en resolución DNS, conexión, TLS, espera y descarga, y muestra cuándo las peticiones esperan una conexión (MDN, "Understanding latency"). Fíjate en barras de conexión repetidas hacia el mismo origen y en muchos orígenes pequeños. Para seguirlo en el tiempo, la monitorización de velocidad de página de LoadFocus ejecuta auditorías Lighthouse programadas desde 25 regiones cloud, y así comparas cómo carga la misma página a distintas distancias. Para una comprobación rápida, el verificador de Core Web Vitals es gratuito. Para tus APIs, la monitorización de APIs desglosa cada tiempo de respuesta en DNS, conexión TCP, primer byte y descarga. Si comparas versiones de protocolo, lee los artículos del blog sobre HTTP/3 y las pruebas de carga y protocolos de red para pruebas de rendimiento. El fondo del retraso en sí está en la latencia.

Preguntas frecuentes

¿Por qué la primera petición a un sitio es más lenta que las siguientes?

La primera necesita una resolución DNS, un handshake TCP y una negociación TLS. Las siguientes reutilizan la conexión abierta y se saltan esos pasos.

¿Cuántas conexiones abre un navegador a un servidor?

Con HTTP/1.x, los navegadores suelen abrir 6 conexiones paralelas por dominio. Con HTTP/2 y HTTP/3, las peticiones comparten una conexión mediante multiplexación, y normalmente basta una.

¿Qué hace preconnect?

Indica al navegador que inicie el trabajo de DNS, TCP y TLS para otro origen antes de que la página lo pida. Solo ayuda con peticiones a un origen distinto y conviene limitarlo a los más críticos.

¿Una conexión más rápida arregla una página lenta?

No siempre. El ancho de banda ayuda con descargas grandes, pero la mayoría de las páginas están limitadas por los viajes de ida y vuelta y el número de orígenes. Reducir conexiones y distancia suele ayudar más que añadir ancho de banda.

¿Qué diferencia hay entre dns-prefetch y preconnect?

dns-prefetch solo resuelve el nombre de dominio. preconnect además abre la conexión TCP y, en HTTPS, completa la negociación TLS: ahorra más tiempo, pero cuesta más.