Latencia: el coste de la distancia
Por que ejecutar codigo cerca del usuario reduce el tiempo de ida y vuelta. La latencia, el RTT, el limite de la velocidad de la luz y por que la distancia se paga varias veces en cada conexion.
La razón última del edge cabe en una palabra: latencia. Si acercar el código al usuario merece la pena, es porque la distancia cuesta tiempo, y ese tiempo tiene un suelo físico que ningún ingeniero puede romper: la velocidad de la luz. Esta lección explica por qué la geografía se convierte en milisegundos, por qué esos milisegundos se pagan varias veces por conexión, y por qué estar cerca no es un lujo sino pura aritmética que decide la sensación de rapidez de tu producto.
- Definir latencia y RTT, y separarlos del ancho de banda.
- Entender la velocidad de la luz como límite físico de la distancia.
- Ver por qué una conexión paga la latencia varias veces (handshakes).
- Cuantificar qué gana el usuario cuando el código corre cerca.
Latencia no es ancho de banda
Se confunden a menudo, pero son cosas distintas. El ancho de banda es cuántos datos caben por segundo; la latencia es cuánto tarda un dato en llegar. Puedes tener una fibra enorme y aun así sentir la web lenta si cada petición viaja al otro lado del mundo.
La medida clave es el RTT (round-trip time): el tiempo de una ida y vuelta completa, de mandar una petición a recibir la respuesta. Casi todo en la web es conversacional —pregunta, respuesta, pregunta, respuesta— así que el RTT, no el ancho de banda, es lo que define la sensación de rapidez.
Latencia
Cuánto tarda un dato en recorrer el camino. Se mide en milisegundos y depende, sobre todo, de la distancia.
Ancho de banda
Cuántos datos caben por segundo. Se mide en megabits y depende de la capacidad del enlace.
RTT
Una ida y vuelta completa. Es la unidad real de coste, porque la web pregunta y espera respuesta sin parar.
Percepción
El usuario siente la latencia, no el caudal. Una app lejana se nota perezosa aunque la fibra sea gigante.
El ancho de banda es lo ancho que es el tubo; la latencia es lo largo que es. Un camión cargado de discos duros cruzando un país tiene un ancho de banda brutal y una latencia pésima. Para una app interactiva, casi siempre manda la latencia: el usuario espera la ida y vuelta, no el caudal.
Esta distinción tiene una consecuencia de diseño: optimizar el ancho de banda —comprimir, servir menos bytes— ayuda con archivos grandes, pero no cura una app que se siente lenta por culpa de muchas idas y vueltas pequeñas. Para eso solo hay dos palancas: acortar cada viaje o hacer menos viajes.
La velocidad de la luz manda
La distancia se convierte en tiempo por una ley que no se negocia. La luz viaja a unos 300.000 km/s en el vacío, pero por la fibra óptica va más despacio, a unos 200.000 km/s. De ahí sale un límite inferior absoluto: ningún dato puede ir de A a B más rápido que eso, hagas lo que hagas.
Hagamos el cálculo. Un usuario en Madrid habla con un servidor en Virginia, a unos 6.000 km:
Distancia ida y vuelta: 6.000 km x 2 = 12.000 km
Velocidad en fibra: ~200.000 km/s
RTT minimo teorico: 12.000 / 200.000 = 0,06 s = 60 msY esos 60 ms son el suelo teórico: en la práctica el cable no va en línea recta, hay routers, colas y congestión, así que el RTT real ronda los 90 o 100 ms. Compáralo con lo que ocurre cuando hay un PoP en la propia Madrid:
| Camino del usuario | Distancia ida y vuelta | RTT aproximado |
|---|---|---|
| Madrid a Virginia | 12.000 km | 90 a 100 ms |
| Madrid a Fráncfort | 4.000 km | 30 a 40 ms |
| Madrid a un PoP en Madrid | pocos km | menos de 10 ms |
La conclusión es incómoda para quien viene de escalar con más CPU: el número de la última fila no se consigue con una máquina más rápida, sino estando ahí. La latencia de distancia vive por debajo de tu código, en la capa física, y solo se reduce reduciendo kilómetros.
Es fácil creer que con suficiente dinero o mejor hardware la latencia bajará sin fin. No es así: la velocidad de la luz en fibra es una constante de la naturaleza. Ninguna empresa, por grande que sea, entrega un dato de Madrid a Sídney en menos de lo que la luz tarda en recorrer esa fibra. La única variable que queda en tus manos es la distancia, y el edge existe precisamente para reducirla a casi cero.
Tres referencias para calibrar la intuición sobre distancias reales:
- Misma ciudad: menos de 10 ms. Se siente instantáneo.
- Mismo continente: entre 20 y 50 ms. Cómodo para casi todo.
- Continentes distintos: de 100 a 300 ms. Aquí es donde el edge marca la diferencia.
Conviene además distinguir el promedio de la cola: no solo importa el RTT medio, sino el peor caso. Un servidor lejano no solo es más lento de media; su tráfico atraviesa más redes intermedias, así que sufre más picos de congestión y su latencia es también más impredecible. La cercanía no solo baja el número: lo estabiliza.
La distancia se paga varias veces
Aquí viene lo que casi todos subestiman: una conexión no paga el RTT una sola vez. Establecer una conexión segura son varias idas y vueltas antes de transferir el primer byte útil.
sequenceDiagram participant U as Usuario participant S as Servidor lejano U->>S: Handshake TCP S-->>U: Confirmacion U->>S: Handshake TLS S-->>U: Confirmacion U->>S: Peticion HTTP S-->>U: Respuesta
Cada flecha de ida y vuelta cuesta un RTT completo. Con un RTT de 100 ms, arrancar una petición HTTPS puede irse a 300 ms o más solo en handshakes, antes de que el servidor haga nada útil. Si además tu app encadena varias peticiones dependientes, multiplicas ese coste una y otra vez.
- TCP necesita su propio handshake para abrir la conexión.
- TLS añade el suyo para cifrar; las versiones modernas lo recortan, pero rara vez llega a cero.
- Cada subpetición dependiente que dispares vuelve a pagar el viaje si abre una conexión nueva.
Un ejemplo con números lo deja claro. Una app que autentica, luego lee el perfil y luego carga datos, cada paso esperando al anterior, con un RTT de 100 ms:
Handshake TCP + TLS: ~200 ms
Autenticacion: ~100 ms
Leer perfil: ~100 ms
Cargar datos: ~100 ms
Total antes de pintar: ~500 ms de puro viajeExisten mitigaciones parciales que conviene conocer, porque explican por qué la web moderna reutiliza conexiones con tanto celo:
- Keep-alive y HTTP/2: reutilizar una conexión abierta evita pagar de nuevo los handshakes.
- TLS 1.3 y 0-RTT: recortan el handshake de cifrado a una ida y vuelta, o a cero en reconexiones.
- QUIC y HTTP/3: fusionan el handshake de transporte y el de cifrado para arrancar antes.
Todas estas técnicas reducen cuántas veces pagas el RTT, pero ninguna reduce el RTT en sí: ese número lo fija la distancia. Puedes exprimir el protocolo al máximo y, aun así, si el servidor está a 100 milisegundos, la primera respuesta tarda 100 milisegundos como mínimo. Por eso son un complemento del edge, no un sustituto: optimizan el número de viajes; el edge optimiza la longitud de cada viaje.
Lo peligroso no es una petición lenta, sino una cadena de ellas. Si tu página necesita autenticarse, luego leer un perfil y luego cargar datos, y cada paso espera al anterior, sumas tres o cuatro RTT en serie. A 100 ms cada uno, es casi medio segundo de puro viaje, sin contar el trabajo real. Acercar el servidor al usuario no ahorra un RTT: ahorra todos, multiplicados por cada handshake y cada eslabón de la cadena.
Y hay un detalle que agrava todo lo anterior en el mundo real: los navegadores limitan cuántas conexiones abren en paralelo a un mismo origen. Cuando ese límite se alcanza, las peticiones hacen cola y esperan turno, sumando aún más RTT en serie. La latencia no solo se multiplica por los handshakes: también por la contención.
Por qué el edge gana
Recogiendo todo lo anterior, el edge ataca el único factor que ni la mejor CPU ni el mejor protocolo pueden tocar: los kilómetros. Y lo hace en el punto donde más duele, el primer viaje:
| Con servidor lejano | Con Worker en el edge |
|---|---|
| RTT de 90 a 100 ms | RTT menor de 10 ms |
| Handshakes de unos 300 ms | Handshakes de decenas de ms |
| Peor caso impredecible | Latencia estable y baja |
Aquí está la idea que justifica toda la plataforma. Puedes comprar un servidor diez veces más rápido y no arreglar nada, porque el cuello de botella no es el cómputo: es el viaje. Si el usuario está a 100 ms, ninguna CPU del mundo le entrega la respuesta antes de esos 100 ms de ida más 100 de vuelta, y eso por cada ronda de conversación. La latencia de distancia es un impuesto que se cobra en la capa física, debajo de tu código, y solo hay una forma de bajarlo: reducir la distancia. Eso es, exactamente, lo que hace el edge. Al ejecutar tu Worker en el PoP de la ciudad del usuario, el RTT cae de cien y pico milisegundos a menos de diez, y como ese ahorro se multiplica por cada handshake y cada ida y vuelta, la mejora percibida es enorme: una app que se sentía perezosa se vuelve instantánea, no porque calcule más rápido, sino porque el viaje casi desaparece. Pero hay un corolario que no puedes olvidar y que gobernará el resto del track: mover el compute al borde solo elimina la distancia hasta el compute. Si tu Worker está a 5 ms del usuario pero consulta una base de datos a 120 ms, has cambiado el cuello de botella de sitio, no lo has eliminado; incluso puedes empeorar, porque ahora ese viaje a los datos parte de un compute que ya no está junto a ellos. Por eso Cloudflare no vende solo compute cercano, sino también datos cercanos —KV, D1 con réplicas de lectura, Durable Objects, la Cache API—: la latencia manda, y manda en los dos extremos de cada petición. Optimizar uno solo es resolver media ecuación. El arte del edge es cerrar los dos viajes a la vez.
- Abre una terminal y haz
pinga un servicio grande. El número en milisegundos es, en esencia, tu RTT hasta él. - Estima el RTT teórico mínimo entre tu ciudad y un centro de datos a 5.000 km usando 200.000 km/s. Compáralo con el ping real y explica la diferencia.
- Explica por qué una conexión HTTPS paga la latencia varias veces antes del primer byte útil.
- Razona el corolario: si el Worker está cerca pero la base de datos lejos, ¿qué has ganado y qué no?