Por qué el ancho de banda no es lo que importa
La demostración aritmética de que duplicar el caudal casi no mejora el tiempo de carga mientras que reducir la latencia lo mejora de forma proporcional.
Todo el mundo cree que contratar más megas hace que la web vaya más rápido. Es la intuición más extendida sobre rendimiento web y es falsa por encima de un umbral bastante bajo. La razón no es sutil ni discutible: una carga de página no es una transferencia continua de datos, es una secuencia de esperas, y las esperas no se acortan ensanchando la tubería. Esta lección lo demuestra con números.
- Definir latencia y ancho de banda con precisión y separar sus efectos.
- Calcular el tiempo de una transferencia descomponiéndolo en espera y transmisión.
- Demostrar por qué duplicar el caudal deja de ayudar por encima de unos pocos megabits.
- Aplicar el resultado para decidir dónde invertir el esfuerzo de optimización.
Las dos magnitudes
El ancho de banda es cuántos bits caben por segundo en el enlace. Se mide en megabits por segundo. Es la anchura de la tubería.
La latencia es cuánto tarda un bit en llegar de un extremo al otro. En la web se trabaja con el tiempo de ida y vuelta, el RTT, porque casi ningún protocolo puede continuar sin recibir la respuesta del otro extremo. Es la longitud de la tubería.
La analogía de la tubería es útil si se entiende bien: el ancho de banda determina cuánta agua sale por segundo una vez que el agua ha empezado a salir, y la latencia determina cuánto tardas en ver la primera gota. En una carga de página, el número de veces que tienes que esperar a la primera gota es enorme, y ahí es donde se va el tiempo.
Hay un límite físico que conviene tener presente: la luz en fibra óptica viaja a unos dos tercios de la velocidad en el vacío, lo que da unos 200.000 kilómetros por segundo. Madrid a Nueva York son unos 5.700 kilómetros en línea recta, es decir, unos 28 milisegundos de ida y 56 milisegundos de ida y vuelta en el mejor caso imaginable, con cable perfectamente recto y cero procesamiento intermedio. En la práctica, con enrutamiento real y equipos por medio, son 80 a 100. Ese número no lo puede mejorar ninguna tecnología, solo se puede evitar acercando el servidor.
La aritmética de una transferencia
El tiempo total de traer un recurso se descompone así:
tiempo = espera inicial + tiempo de transmision
espera inicial = numero de RTT necesarios x RTT
tiempo de transmision = tamano / ancho de bandaHagamos el cálculo con un caso concreto: traer un documento HTML de 30 KB desde un origen nuevo, sin caché de DNS, sobre HTTPS.
Los viajes de ida y vuelta necesarios antes de que llegue el primer byte de contenido son cuatro: uno para DNS, uno para el saludo TCP, uno para TLS 1.3, y uno para la petición y el primer byte de respuesta.
Con RTT de 100 ms y 5 Mbps:
espera inicial = 4 x 100 ms = 400 ms
transmision = 30 KB / 5 Mbps
= 240.000 bits / 5.000.000 = 48 ms
total = 448 msAhora duplicamos el ancho de banda a 10 Mbps y dejamos el RTT igual:
espera inicial = 400 ms
transmision = 240.000 / 10.000.000 = 24 ms
total = 424 msHemos duplicado el ancho de banda y hemos ganado 24 milisegundos, un 5%. Duplícalo otra vez, a 20 Mbps, y ganarás 12 más. La serie converge: por mucho que ensanches la tubería, los 400 milisegundos de espera no se mueven ni un microsegundo.
Ahora al revés. Volvemos a 5 Mbps y reducimos el RTT a la mitad, a 50 ms:
espera inicial = 4 x 50 ms = 200 ms
transmision = 48 ms
total = 248 msHemos ganado 200 milisegundos, un 45%, sin tocar el ancho de banda. Y esa mejora escala: si el RTT baja a 25 ms, ganas otros 100.
La medición clásica de esta relación, publicada por el equipo de Chrome, encontró que el tiempo de carga de una página mejora de forma prácticamente lineal al reducir el RTT, mientras que aumentar el ancho de banda solo ayuda hasta unos 5 Mbps y a partir de ahí la curva se aplana casi por completo. Es exactamente lo que predice la descomposición anterior, y es la razón de que las operadoras vendan megas y la web no vaya más rápido.
Por qué una página no es un archivo
El cálculo anterior era para un solo recurso. Una página real amplifica el efecto porque encadena muchas esperas, y muchas de ellas son secuenciales.
Considera una página con esta cadena de dependencias:
1. HTML 4 RTT hasta el primer byte
2. CSS descubierto en el HTML 1 RTT sobre la conexion abierta
3. Fuente referenciada en el CSS, en otro origen
4 RTT: DNS, TCP, TLS, peticion
4. Imagen del hero 1 RTT sobre la conexion del origenLa fuente no puede descubrirse hasta que el CSS ha llegado y se ha parseado, porque su URL está dentro. Es decir, esos cuatro viajes del paso 3 empiezan después de que termine el paso 2. La cadena crítica suma diez viajes de ida y vuelta encadenados.
Con RTT de 100 ms, eso es un segundo entero de espera pura, sin haber transferido un solo byte útil. Con RTT de 30 ms, son 300 milisegundos. Y el ancho de banda no aparece en ningún sitio de este cálculo.
Es más: el ancho de banda casi nunca se satura durante la parte crítica de una carga. Los recursos críticos son pequeños, van llegando de uno en uno o de pocos en pocos, y la tubería está prácticamente vacía mientras se espera la respuesta. Puedes comprobarlo en cualquier cascada: la utilización real del enlace durante el primer segundo de una carga típica es muy baja.
Dónde sí importa el ancho de banda
Para ser justos, hay tres casos donde el caudal es el factor dominante y conviene reconocerlos.
Recursos grandes en la ruta crítica. Una imagen de hero de 800 KB a 1,6 Mbps son cuatro segundos de transmisión pura. Ahí el ancho de banda manda, y también manda el tamaño del recurso, que es la parte que tú controlas.
Vídeo. Es una transferencia continua y sostenida; el caudal es exactamente lo que determina la calidad que puedes servir.
Conexiones muy malas. Por debajo de 1 Mbps, incluso los recursos pequeños tardan lo suficiente como para que el caudal pese. El perfil de referencia de Lighthouse, 1,6 Mbps, está justo en esa frontera.
La regla que se deriva es limpia: el ancho de banda determina el coste de los bytes, la latencia determina el coste de las peticiones. Si tu problema es que sirves imágenes enormes, es un problema de bytes. Si tu problema es que la cadena crítica tiene diez eslabones, es un problema de viajes, y comprimir mejor no lo va a tocar.
Consecuencias para el trabajo
De todo lo anterior salen cuatro prioridades ordenadas, y el orden importa.
Primera: reduce el número de orígenes. Cada origen nuevo cuesta DNS, TCP y TLS, tres o cuatro viajes de ida y vuelta, aunque el recurso pese dos kilobytes. Traer una fuente de un dominio ajeno puede costar más tiempo que la propia fuente.
Segunda: acorta la cadena de dependencias. Un recurso que no se puede descubrir hasta que llega otro añade su cadena completa a la ruta crítica. Que todo lo crítico sea descubrible desde el HTML inicial es más valioso que hacerlo más pequeño.
Tercera: acerca el servidor. Servir desde un punto de presencia cercano reduce el RTT, y reducir el RTT multiplica por el número de viajes. Es la única palanca que mejora todos los eslabones a la vez.
Cuarta: reduce bytes. Comprimir y elegir formatos mejores sigue mereciendo la pena, y es lo que más se hace, pero llega después de las tres anteriores en orden de rentabilidad para una cadena crítica típica.
El mito del ancho de banda no persiste por ignorancia sino porque las herramientas de diagnóstico lo camuflan. Una cascada de red dibuja barras cuya longitud es tiempo, y el ojo va a la barra más larga, que suele ser un recurso grande descargándose en paralelo sin bloquear nada. Lo que de verdad decide el tiempo de carga no es ninguna barra individual sino el escalonado entre barras: los huecos donde no hay nada descargándose porque se está esperando una respuesta. Esos huecos son latencia y no se ven, porque las herramientas dibujan lo que ocurre, no lo que no ocurre. El ejercicio que cambia la percepción de cualquiera es este: abre una cascada, tapa mentalmente las barras y mira solo el perfil escalonado de los inicios. Si cada recurso empieza claramente después de que termine el anterior, tienes un problema de cadena y de latencia por mucho que las barras sean cortas. Si todos empiezan casi a la vez y las barras son largas, entonces sí es un problema de bytes y de caudal. Ese diagnóstico se hace en cinco segundos y decide en qué vas a gastar el mes siguiente.