Hazte la pregunta antes de seguir leyendo. Tienes que elegir entre dos servidores para un sitio que van a visitar colombianos: uno en São Paulo y otro en Virginia. ¿Cuál eliges?
Casi todo el mundo dice São Paulo. Mismo continente, mismo huso horario, mismo hemisferio, factura en la región. Suena a sentido común.
En nuestra medición, la respuesta intuitiva fue la más lenta: observamos entre 70 y 85 milisegundos de diferencia. Es un resultado de esos endpoints, desde esa red y en esa fecha; no una regla universal sobre ambas ciudades.
Lo que dice el reloj
Medimos el 30 de agosto de 2026 desde Bogotá, sobre red INTERNEXA (AS18678), por ruta pública y anotando el RTT mínimo. No desde un datacenter ni desde un nodo de pruebas alquilado: desde donde está sentado tu visitante colombiano.
| Endpoint de la muestra | Latencia desde Bogotá |
|---|---|
| Conexcol — Colombia | 16,9 ms |
| Referencia local A — Bogotá | 18,4 ms |
| Referencia local B — Colombia | 20,0 ms |
| Proveedor A, endpoint 1 — Asheville | 94,9 ms |
| Proveedor B — Ashburn, Virginia | 96,3 ms |
| Proveedor C — Dallas, Texas | 98-105 ms |
| Proveedor A, endpoint 2 — Phoenix | 117,8 ms |
| Proveedor D — Phoenix | 121-126 ms |
| Proveedor E — Santiago de Chile | 132-137 ms |
| Proveedor F — Salt Lake City | 133-138 ms |
| Proveedor A, endpoint 3 — São Paulo | 168-180 ms |
| Proveedor G — São Paulo | 173-179 ms |
| Proveedor H — Phoenix | 178-186 ms |
| Proveedor I — Argentina | 190-208 ms |
Medido el 2026-08-30 desde Bogotá, red INTERNEXA (AS18678), ruta pública, RTT mínimo.
Lee la tabla de abajo hacia arriba y verás el patrón: el fondo de la lista es casi todo Suramérica. São Paulo, Santiago, Buenos Aires. Los destinos que suenan «cerca» son varios de los que más tardan.
Ojo con la trampa contraria, que también está en la tabla: la ciudad no lo explica todo. Dos endpoints en Phoenix dieron 121-126 ms y 178-186 ms. Manda la ruta, no el mapa.
Por qué pasa: el desvío se paga dos veces
La respuesta está en el traceroute, no en el mapa.
Internet no se cablea únicamente por cercanía geográfica, sino por acuerdos de interconexión. En las rutas medidas, el tráfico internacional pasó por Miami antes de continuar a su destino. Se ve en el traceroute, salto por salto.
Si el destino es Virginia o Texas, subir ya es ir en la dirección correcta. Llegas.
Si el destino es São Paulo, subiste para nada. Desde Miami hay que bajar otra vez, cruzando de nuevo todo el continente, para llegar a Brasil. Recorres el largo de Suramérica dos veces: una hacia arriba y otra hacia abajo. Y luego el paquete de respuesta hace el mismo viaje absurdo de vuelta.
Eso es lo que compras cuando compras «un servidor en Latinoamérica»: el desvío completo, ida y regreso, en cada imagen, en cada consulta a la base de datos, en cada handshake de TLS.
Dos pares de endpoints observados
Dos pares muestran por qué hay que medir el servicio concreto y no extrapolar desde el mapa.
Proveedor A. Un endpoint asociado en Asheville respondió en 94,9 ms y otro en São Paulo en 168-180 ms. Esa diferencia describe la muestra observada; no implica que todas las cuentas del proveedor sigan las mismas rutas.
Proveedor G. Un endpoint vinculado a su tienda para Colombia respondió desde São Paulo en 173-179 ms; otro vinculado a su tienda estadounidense respondió desde Salt Lake City en 133-138 ms. No comparamos planes, precio ni calidad: solo esos endpoints y su ruta en esa sesión.
Nada de esto descalifica una instalación ni a su operador. São Paulo puede ser la opción correcta para una audiencia brasileña. La conclusión útil es que un destino regional no garantiza menor latencia para Colombia.
«Pero yo tengo CDN»
Es la objeción inmediata, y es razonable. Un CDN acerca el contenido al usuario. Debería borrar el problema.
Acerca lo estático. No acerca el servidor.
Primero, dónde te atienden. En la muestra y sesión revisadas, el 95% de las respuestas observadas detrás de Cloudflare llegó desde el punto de presencia de Miami, no desde Bogotá. Eso describe el borde que atendió la petición, no la ubicación del origen.
Segundo, y más importante: lo que no se cachea. El HTML de un WordPress con carrito, el login, la búsqueda, el checkout, el panel de administración. Nada de eso se guarda en el borde: cada petición vuelve al origen, esté donde esté. Y hay tres cosas más que ningún borde acerca — la base de datos, el correo y el FTP.
Esto también se mide. El 2026-08-30, desde Bogotá, tiempo hasta el primer byte del HTML, el mejor de entre tres y cinco intentos:
| Endpoint | Configuración observada | Primer byte del HTML |
|---|---|---|
| Sitio de Conexcol | Colombia, directo | 0,085 – 0,105 s |
| Sitio externo A | detrás de CDN | 0,260 – 0,307 s |
| Sitio externo B | detrás de CDN | 0,283 – 0,294 s |
| Sitio externo C | detrás de CDN | 0,293 s |
Medido el 2026-08-30 desde Bogotá, red INTERNEXA (AS18678), ruta pública.
En el sitio externo B, la cabecera cf-cache-status: DYNAMIC indicó que el HTML no salió de la caché del CDN. En esa sesión, el RTT hasta el borde fue de 65,3 ms y el TTFB observado de 338,9 ms. Es una demostración del mecanismo, no una evaluación general del proveedor ni del servicio que vende.
Un borde cercano acelera las imágenes; no acerca el servidor.
El dato de fondo
Esto no es un caso raro. Clasificamos 1.352 dominios colombianos (.com.co, .gov.co, .edu.co, .org.co, .net.co, .mil.co) por el sistema autónomo que anunciaba cada prefijo. Alrededor del 11% apareció asociado a redes clasificadas como colombianas: unos 150. De los demás, 552 resolvieron a un AS extranjero directo y 559 quedaron detrás de un CDN.
Nueve de cada diez dominios de esa muestra no aparecieron asociados a un AS clasificado como colombiano. Eso no certifica la ubicación física ni dónde se almacenan los datos; muestra por qué hace falta corroborar varias señales.
Lo que sí arregla el problema
Una de las palancas más fuertes es acercar el origen a la audiencia y conectarlo bien. Para público colombiano, un origen en Colombia conectado al NAP puede evitar rutas internacionales innecesarias.
Hay varias opciones locales: operadores colombianos y regiones de nubes globales. Este artículo no pretende clasificarlas. La comparación correcta exige el producto concreto, el endpoint, el precio, la capacidad y mediciones repetidas desde las redes donde están los usuarios.
Lo que la etiqueta no dice es dónde responde el servidor. «Servidor en Latinoamérica» y «servidor en Colombia» suenan parecido, y entre São Paulo y Bogotá medimos más de 150 milisegundos de diferencia.
Compruébalo tú, ahora
No nos creas:
dig +short tusitio.com
ping -c 20 <la IP que salió>
traceroute -n <la IP que salió>Mira el mínimo del ping, no el promedio. Y mira el traceroute: si ves nombres con mia, miami, ashburn o gru en los saltos, ya sabes por dónde está viajando tu negocio.
Si el mínimo sale en tres cifras, hay un costo de red que ninguna optimización de imágenes elimina por sí sola. Un número bajo tampoco garantiza buen servicio: revisa además TTFB, estabilidad, capacidad, soporte y las condiciones del plan.
Mediciones puntuales: 2026-08-30, desde Bogotá, una sola red (INTERNEXA, AS18678), ruta pública y RTT mínimo. No caracterizan todos los productos o cuentas de ningún proveedor. Los nombres, endpoints exactos, fuentes y límites se concentran en el anexo metodológico.
