Por qué São Paulo es peor que Virginia para un sitio colombiano

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.

Es la respuesta equivocada. Y no por poco: entre 70 y 85 milisegundos de diferencia, cada vez, en cada petición.

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.

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. Phoenix aparece dos veces, con GoDaddy en 121-126 ms y con Namecheap en 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 por cercanía geográfica sino por acuerdos de interconexión. Y el punto por donde Colombia intercambia la mayor parte de su tráfico con el mundo queda al norte: Miami. Se ve en el traceroute, salto por salto. Cuando tu paquete sale de Bogotá hacia un destino internacional, lo primero que hace es subir.

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.

El caso que lo deja sin discusión

Hay dos ejemplos que valen más que toda la explicación.

Hostinger. Su propia infraestructura en Asheville, Estados Unidos, responde a Bogotá en 94,9 ms. Su infraestructura en São Paulo, mismo proveedor, misma empresa, responde en 168-180 ms. El servidor «latinoamericano» del mismo dueño es casi el doble de lento para un colombiano que el estadounidense.

HostGator. Su tienda en Estados Unidos entrega desde Salt Lake City: 133-138 ms. Su tienda colombiana, la que te habla en español y te muestra precios en pesos, entrega desde São Paulo: 173-179 ms. Es decir, la versión colombiana de la marca responde entre 35 y 46 ms más lento a un colombiano que la versión estadounidense de la misma marca.

Nadie está mintiendo. São Paulo es un datacenter excelente. Sirve maravillosamente a Brasil, que es donde está el mercado que justifica esa inversión. Lo que no hace es servirte a ti.

«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. Revisamos los sitios colombianos que usan Cloudflare y el 95% se sirve desde el punto de presencia de Miami, no desde el de Bogotá, aunque el de Bogotá exista. Eso son unos 69 ms. Mejor que 180, claro. Pero cuatro veces peor que quedarse en el país.

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:

Medido el 2026-08-30 desde Bogotá, red INTERNEXA (AS18678), ruta pública.

Y la prueba más limpia no la ponemos nosotros: la pone el propio CDN. La respuesta de wnpower.net trae la cabecera cf-cache-status: DYNAMIC, que es Cloudflare declarando que esa página no la está sirviendo desde caché. En esa misma sesión, ese sitio contestó el ping del borde en 65,3 ms y el primer byte del servicio en 338,9 ms. El ping halaga; el servicio no.

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 anuncia cada prefijo. Resultado: solo el 11% se sirve desde infraestructura físicamente colombiana. Unos 150. De los demás, 552 están en un AS extranjero directo y 559 detrás de un CDN.

Nueve de cada diez sitios con dominio colombiano de esa muestra viven afuera. Y averiguarlo cuesta los tres comandos que van al final de este artículo.

Lo que sí arregla el problema

Una sola cosa: que el servidor de origen esté en Colombia, conectado al NAP Colombia, donde el paquete no tiene que subir a ningún lado.

Y hay que decirlo completo, porque una página que esconde a su competencia no merece que le creas: no somos los únicos que lo hacen. HostDime opera datacenter propio en Bogotá y mide 20,0 ms. Oracle abrió región en Bogotá y mide 18,4 ms. El Uptime Institute lista 23 instalaciones premiadas en Colombia, 13 de ellas con Tier III construido. Hay país, hay infraestructura, hay opciones serias.

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 que te sale es de tres cifras, tienes un problema que ninguna optimización de imágenes va a resolver. Si te sale por debajo de 21 ms —donde midieron los tres primeros de la tabla— ya no tienes que volver a pensar en esto.

Todas las mediciones: 2026-08-30, desde Bogotá, red INTERNEXA (AS18678), ruta pública, RTT mínimo. La latencia de un tercero depende de a qué instalación caiga tu cuenta; por eso publicamos el punto de medición y la fecha.