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: sirve, 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 una sola red —INTERNEXA (AS18678)—, por ruta pública de internet, tomando el RTT mínimo de la serie. Es un punto de observación colombiano, no una muestra representativa de todas las ciudades, operadores, horarios o cuentas.

Cada renglón es un endpoint concreto; algunos pertenecen al mismo proveedor en instalaciones distintas. La misma ciudad puede dar números muy diferentes según la red y el servicio medido. Phoenix aparece tres veces, entre 117,8 ms y 186 ms. Por eso no sería correcto afirmar que una ciudad tiene una latencia fija.

El proveedor A aparece en Asheville, Phoenix y São Paulo porque observamos endpoints o cuentas asociados a instalaciones distintas. Eso demuestra variación dentro de una misma marca; no permite predecir dónde quedará cualquier cuenta nueva.

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 predicción de tiempo de carga: los navegadores reutilizan conexiones y ejecutan algunas peticiones en paralelo. Supongamos veinte idas y vueltas secuenciales solo para visualizar el orden de magnitud. Los únicos números medidos 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 quede más cerca que uno en Estados Unidos. Está más cerca en el mapa. Desde la red y sesión medidas, el endpoint de São Paulo respondió entre 168 y 180 ms y el de Asheville en 94,9 ms. Eso describe esos endpoints, no todas las rutas entre Colombia y ambas ciudades.

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.

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 anunciaba cada prefijo en BGP:

• Alrededor del 11% apareció asociado a redes clasificadas como colombianas (~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.

El resultado describe el anuncio de red observado. No certifica la ubicación física del servidor ni dónde se almacenan los datos, especialmente en los 559 dominios ocultos detrás de un CDN.

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). Los nombres de los saltos pueden dar pistas como mia, dfw, phx o gru, pero no constituyen por sí solos una certificación de ubicación.
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. Desde la red y fecha indicadas, el endpoint medido dio 16,9 ms. El resultado de cada lector dependerá de su ciudad, operador, ruta y momento de la prueba.

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