Qué es la latencia y por qué el NVMe no la arregla

Tu sitio web tiene dos relojes, y en la publicidad casi siempre aparece uno solo.

El primer reloj corre dentro del servidor: procesador, memoria, disco. El segundo corre afuera, en el cable, entre el navegador de tu cliente y ese servidor. Los dos suman en el tiempo que tu visitante espera mirando una pantalla en blanco. Pero no suman parejo, porque no corren a la misma velocidad. Y la diferencia no es de un poquito: es de tres ceros.

Este artículo explica esa diferencia, con números medidos, y para qué sirve de verdad un disco NVMe.

Microsegundos contra milisegundos

Un disco NVMe atiende una lectura en microsegundos: millonésimas de segundo. Es una pieza extraordinaria de ingeniería y no vamos a desmerecerla — en Conexcol también usamos NVMe, y por buenas razones que veremos más abajo.

La red trabaja en milisegundos. Un milisegundo tiene mil microsegundos. Cuando un servidor responde en 96,3 milisegundos, está tardando más de noventa y seis mil microsegundos. Es otra escala. Es otro reloj.

Esto no es una opinión, se mide.

Metodología. Mediciones del 30 de agosto de 2026, desde Bogotá, sobre red INTERNEXA (AS18678), por ruta pública de internet, tomando el RTT mínimo de la serie. Ese es el punto de vista de un visitante colombiano sentado en su casa o en su oficina; no es un datacenter midiéndose a sí mismo desde adentro, que siempre da bonito.

Cada renglón es un proveedor distinto en una ciudad distinta, y por eso no los fundimos: la misma ciudad da números muy diferentes según quién te atienda ahí. Phoenix aparece tres veces, entre 117,8 ms y 186 ms. Decir «Phoenix es 120 ms» sería más cómodo para nosotros y falso.

Y fíjate en el proveedor A: aparece en Asheville, en Phoenix y en São Paulo. Es el mismo servicio contratado, cayendo en tres continentes de tráfico distintos según el caso. Lo que compras no siempre es lo que te toca.

El mejor disco NVMe del mundo se mueve dentro del primer renglón de esa tabla y no toca ninguno de los otros.

Qué es exactamente la latencia

Latencia, en la práctica, es el RTT: round trip time, el tiempo que tarda un paquete en ir hasta el servidor y volver. Es lo que reporta un ping.

No confundas latencia con ancho de banda. Son cosas distintas y se optimizan distinto:

• Ancho de banda es cuántos carriles tiene la vía. Manda cuando bajas un archivo grande.
• Latencia es cuánto se demora un carro en ir y volver. Manda cuando abres una página.

Y una página web no es un archivo grande. Es un montón de viajes cortos.

Una página no es un viaje: son decenas

Abrir una URL cualquiera dispara, como mínimo, esta secuencia:

1. DNS: resolver el nombre a una dirección IP. Uno o varios viajes.
2. TCP: el saludo de tres vías para abrir la conexión. Un viaje completo.
3. TLS: la negociación del candado HTTPS. Uno o dos viajes más.
4. La petición del HTML: otro viaje.
5. Todo lo que el HTML pide después: CSS, JavaScript, tipografías, imágenes, el logo, el pixel de analítica.
6. Lo que el JavaScript pide luego: el carrito, el precio, el inventario, la sesión.

Hagamos una cuenta de servilleta. Es un supuesto, no una medición, y lo marco para que nadie lo lea como un dato: supongamos veinte idas y vueltas para armar una página completa. Los únicos números medidos de esta cuenta son los de la tabla de arriba.

• Con el origen a 16,9 ms: veinte viajes son 0,34 segundos.
• Con el origen en São Paulo, a 168–180 ms: veinte viajes son entre 3,4 y 3,6 segundos.

Unas diez veces. Y todavía no hemos ejecutado una sola consulta de base de datos.

Eso es lo que tu visitante siente como «esta página está lenta». No es el disco. Es la distancia, cobrada en cada uno de esos viajes.

La distancia en línea recta no manda: manda la ruta

Aquí viene el dato más útil de todo el artículo, y es contraintuitivo.

Uno esperaría que un servidor en Brasil le quede más cerca a un colombiano que un servidor en Estados Unidos. Está más cerca en el mapa. La medición dice lo contrario: São Paulo respondió entre 168 y 180 ms, y un servidor en Asheville, Estados Unidos, respondió en 94,9 ms. El «latinoamericano» salió casi el doble de lento.

La explicación está en el traceroute. Desde Bogotá, el tráfico sube a Miami. Y a São Paulo se llega bajando desde Miami. Es decir: se paga el desvío dos veces, ida y vuelta, por un destino que en el mapa parecía vecino.

Lo mismo con Argentina, en 190–208 ms, y con Santiago de Chile, en 132–137 ms — más lejos, en tiempo, que Virginia.

La lección práctica: cerca en el mapa no es cerca en la red. Lo que manda es dónde están los puntos de intercambio de tráfico, cómo está conectado el operador y por dónde sale de verdad tu paquete. Un servidor en Bogotá, conectado al NAP Colombia, no tiene que subir a ninguna parte: ya está donde está tu cliente.

Entonces, ¿el NVMe no sirve?

Sí sirve. Sirve muchísimo, y aquí lo usamos.

El NVMe arregla exactamente lo que le toca arreglar:

• La consulta pesada de la base de datos que lee de disco.
• El arranque en frío cuando el caché está vacío.
• El sitio con miles de archivos pequeños, que es donde los discos mecánicos se ahogaban.
• Los picos de escritura: logs, sesiones, colas, importaciones.
• La restauración de una copia de seguridad, que deja de tomar la tarde.

Lo que el NVMe no puede hacer es acortar un viaje a Virginia. Está optimizando microsegundos en un trayecto donde la red está gastando decenas de miles de microsegundos. Es como poner llantas de competencia sabiendo que el problema es el trancón de la autopista: la mejora existe, es real, y es invisible al lado de lo otro.

Por eso el orden correcto para acelerar un sitio es este, y en este orden:

1. Acerca el origen a tu público. Es la única palanca que mueve los 100 ms.
2. Reduce el número de viajes. Menos peticiones, menos redirecciones, HTTP/2, caché de navegador.
3. Cachea lo que puedas. Página completa, objetos, consultas.
4. Ahí sí, aprieta el servidor: NVMe, más CPU, más RAM, PHP al día, índices en la base de datos.

El paso 4 es el que más se vende en las fichas de producto. El paso 1 es el que más mueve el número.

Y el CDN tampoco acorta el viaje de lo dinámico

La segunda respuesta que aparece siempre es «ponle un CDN y ya». Un CDN acerca copias de lo estático: imágenes, CSS, tipografías. Eso es real y sirve. Pero el HTML de un WordPress con carrito, el login, la búsqueda, el checkout y el panel no se cachean: cada petición vuelve al origen, esté donde esté. Y no se acercan ni la base de datos, ni el correo, ni el FTP.

Eso también se mide. TTFB del HTML, mejor de 3 a 5 intentos, el 30 de agosto de 2026, desde Bogotá, red INTERNEXA (AS18678), ruta pública:

Uno de esos sitios devolvió la cabecera cf-cache-status: DYNAMIC en su propio HTML: es el CDN declarando, por escrito, que esa página no la está sirviendo desde caché. Y en la misma sesión ese mismo sitio dio 65,3 ms de RTT hasta el borde y 338,9 ms de TTFB del servicio: el ping halaga, el servicio no.

Un borde cercano acelera las imágenes; no acerca el servidor. Lo desarrollamos entero en el artículo sobre cuándo un CDN ayuda y cuándo no.

El mapa colombiano, medido

Censo propio de 1.352 dominios colombianos (.com.co, .gov.co, .edu.co, .org.co, .net.co, .mil.co), clasificados por el sistema autónomo que anuncia cada prefijo en BGP:

• Solo el 11% se sirve desde infraestructura físicamente colombiana (~150 dominios).
• 552 se sirven desde un AS extranjero directo.
• 559 están detrás de un CDN.
• El 49% de los .gov.co (119 de 242) resuelve a un AS extranjero.
• El 54% de los .edu.co (107 de 199) también.

Dicho de otro modo: la mayoría de los sitios con nombre colombiano le cobra a cada visitante colombiano un viaje internacional, y se lo cobra en cada uno de los viajes que hacen falta para armar la página.

Cómo comprobarlo tú mismo, en tres minutos

No nos creas. Mídelo:

1. ping tudominio.com desde tu conexión, en Colombia. Mira el tiempo mínimo, no el promedio.
2. traceroute tudominio.com (o tracert en Windows). Mira dónde muere: los nombres de los saltos suelen delatar la ciudad — mia, dfw, phx, gru.
3. Mide el TTFB, no solo el ping. curl -o /dev/null -s -w "%{time_starttransfer}\n" https://tudominio.com te dice cuánto tarda el servicio, que es lo que sufre tu cliente. El ping mide el borde; el TTFB mide el origen.
4. Busca el AS que anuncia el prefijo, no a nombre de quién está registrado el bloque. Son dos cosas distintas: un bloque puede estar registrado a nombre colombiano y anunciarse desde otro país. El registro dice quién lo pidió; el AS dice desde dónde sale el tráfico.
5. Busca el geofeed (RFC 8805) del operador si lo publica: es una declaración del propio dueño sobre en qué ciudad está cada prefijo.
6. Mide desde donde están tus clientes. Si tu público es colombiano, medir desde un servidor en Ohio no te dice nada.

Lo que de verdad mueve el número

La latencia es el único componente del rendimiento web que no se arregla comprando hardware. Se arregla con geografía y con conectividad: estar donde está tu gente, y estar bien conectado ahí.

En Conexcol operamos en Colombia, conectados al NAP Colombia. Por eso la medición desde Bogotá da 16,9 ms, y no 96,3 ms, ni 168–180 ms. No es un truco de configuración: es dónde está el servidor.

Mídenos. Es la clase de afirmación que se puede comprobar con un ping y treinta segundos.

Si lo que estabas decidiendo es qué tipo de servidor contratar y no sólo dónde ponerlo, qué es un servidor en la nube explica en qué se diferencia del hosting y cuándo compensa cada uno.