Un visitante en Bogotá abre una página con dominio .com.co. El dominio y la empresa pueden ser colombianos, mientras la ruta de red termina en otro país. El nombre del dominio no revela dónde está el servidor.
No es una anécdota suelta. Clasificamos 1.352 dominios bajo la jerarquía colombiana —.com.co, .gov.co, .edu.co, .org.co, .net.co y .mil.co— según el sistema autónomo que anuncia su prefijo, y alrededor de 150 aparecieron asociados a redes clasificadas como colombianas. Once por ciento.
Y antes de seguir, el límite, porque un número sin su límite es una consigna. De esos 1.352, 552 resolvieron a un sistema autónomo extranjero directo y 559 quedaron detrás de un CDN, donde desde afuera no se ve el origen. El 11% no certifica ubicación física: clasifica el anuncio de red observado. Tampoco permite resolver el grupo del CDN ni decir en qué país se almacenan los datos.
Este artículo cuenta cómo se midió, qué pasa de verdad con el grupo del CDN y qué cuesta todo eso en milisegundos.
El método: el AS, no el dominio
Un dominio no dice dónde está nada. Lo que sí dice algo es la ruta.
Para cada dominio resolvimos su dirección IP y miramos qué sistema autónomo (AS) anuncia ese prefijo en BGP, la tabla de rutas pública de internet. El AS es el operador que le dice al resto del mundo «este bloque de direcciones se alcanza por aquí». Es el dato más cercano que existe, sin entrar a la máquina, a la pregunta de quién sirve el sitio y desde dónde.
El reparto quedó así:
| Clasificación | Dominios |
|---|---|
| AS colombiano | ~150 |
| AS extranjero directo | 552 |
| Detrás de un CDN | 559 |
| Total clasificado | 1.352 |
De ahí sale el 11%: unos 150 sobre 1.352. Es una medición reproducible del AS anunciado, no un censo definitivo de datacenters.
Una advertencia metodológica que conviene dejar dicha: un AS colombiano no garantiza que la máquina esté en un rack en Colombia, ni un AS extranjero garantiza que el equipo esté afuera. La latencia y el traceroute aportan señales adicionales, pero tampoco prueban por sí solos una dirección física.
El grupo del CDN, medido
Los 559 que quedan detrás de un CDN son el bulto ambiguo del estudio. Un CDN puede entregar desde un punto de presencia en Bogotá o desde uno en Miami, y el visitante no elige cuál le toca.
En la muestra y sesión medidas, el 95% de las respuestas observadas detrás de Cloudflare llegó desde su punto de presencia de Miami, a unos 69 milisegundos, no desde el de Bogotá. Eso identifica el borde que atendió la petición, no el origen del sitio.
También observamos respuestas desde bordes en Bogotá cercanas a 16,1 ms. Cuando el borde cae local, puede entregar muy bien el contenido cacheado. La marca del proveedor no cambia esta distinción técnica.
Ahora bien: que el borde caiga local no significa lo que casi todo el mundo cree que significa. Y esto es lo más importante del artículo.
Un borde de CDN no es un datacenter cerca
Un CDN acerca lo estático: imágenes, hojas de estilo, JavaScript, tipografías. Eso se copia al borde y se entrega desde ahí, rapidísimo.
Lo dinámico no. El HTML de un WordPress con carrito, el login, la búsqueda, el checkout, el panel de control: nada de eso se cachea, porque cada respuesta depende de quién pregunta. Cada una de esas peticiones vuelve al origen, esté donde esté. Y hay tres cosas que ningún borde acerca jamás: la base de datos, el correo y el FTP.
Se puede medir, y lo medimos. El 30 de agosto de 2026, desde Bogotá, tomando el TTFB del HTML (el tiempo hasta el primer byte de la página, no del ping), mejor de tres a cinco intentos:
| Endpoint medido | TTFB del HTML | Alcance de la observación |
|---|---|---|
| Sitio de Conexcol | 0,085–0,105 s | sitio institucional, origen directo en Colombia |
| Sitio externo A | 0,260–0,307 s | sitio institucional detrás de CDN |
| Sitio externo B | 0,283–0,294 s | sitio institucional detrás de CDN |
| Sitio externo C | 0,293 s | sitio institucional detrás de CDN |
En uno de los endpoints externos, la cabecera cf-cache-status: DYNAMIC indicó que ese HTML no salió de la caché del CDN.
En esa misma sesión, el RTT al borde fue de 65,3 ms y el TTFB observado de 338,9 ms. Es un ejemplo puntual de por qué el ping al borde y el tiempo del HTML responden preguntas distintas.
Un borde cercano acelera las imágenes; no acerca el servidor.
Conviene leer esa tabla con cuidado: mide sitios institucionales, no los planes de hosting que venden sus operadores. No es una clasificación de proveedores. Solo demuestra que un HTML dinámico puede requerir un viaje adicional hasta el origen.
El sector público es donde más se nota
Dentro del corpus, dos subconjuntos se comportan peor que el promedio:
.gov.co: 119 de 242 (49%) resuelven a un AS extranjero..edu.co: 107 de 199 (54%) resuelven a un AS extranjero.
Uno de cada dos. No vamos a nombrar entidades: son terceros que no pidieron aparecer en nada, y el punto no es señalar a nadie sino describir un patrón. El patrón es que la ruta del trámite que un ciudadano hace desde Neiva o desde Pasto sale del país y vuelve. Dónde queda alojado el dato es una pregunta aparte, y el AS no la responde: hay que preguntársela a la entidad.
Lo que cuesta en milisegundos
Medimos el 30 de agosto de 2026 desde Bogotá, sobre red INTERNEXA (AS18678), por ruta pública, tomando el RTT mínimo. Es el punto de vista de un visitante colombiano, no el de un servidor dentro de un datacenter.
| Endpoint de la muestra | RTT mínimo | Región observada o declarada |
|---|---|---|
| Conexcol | 16,9 ms | Colombia |
| Referencia local A | 18,4 ms | Bogotá, Colombia |
| Referencia local B | 20,0 ms | Colombia |
| Proveedor A, endpoint 1 | 94,9 ms | Asheville, EE. UU. |
| Proveedor B | 96,3 ms | Ashburn, Virginia |
| Proveedor C | 98–105 ms | Dallas, Texas |
| Proveedor A, endpoint 2 | 117,8 ms | Phoenix, EE. UU. |
| Proveedor D | 121–126 ms | Phoenix, Arizona |
| Proveedor E | 132–137 ms | Santiago de Chile |
| Proveedor F | 133–138 ms | Salt Lake City, EE. UU. |
| Proveedor A, endpoint 3 | 168–180 ms | São Paulo, Brasil |
| Proveedor G | 173–179 ms | São Paulo, Brasil |
| Proveedor H | 178–186 ms | Phoenix, Arizona |
| Proveedor I | 190–208 ms | Argentina |
Una página no se descarga de una sola petición: se arma con muchas, y cada ida y vuelta se paga completa. La diferencia entre 16,9 y 133 milisegundos no se siente como «una décima de segundo»: se siente como la página que responde al toque frente a la página que hay que esperar.
Un datacenter «latinoamericano» puede resultar más lento
Aquí está el hallazgo contraintuitivo, y es el más útil de todo el estudio.
En esta medición desde una red de Bogotá, el endpoint del proveedor A en São Paulo respondió entre 168 y 180 ms, mientras otro endpoint asociado al mismo proveedor en Asheville respondió en 94,9 ms. Es un resultado puntual, no una regla universal sobre ambas ciudades.
La causa está en el traceroute. Desde Bogotá el tráfico sube a Miami; a São Paulo solo se llega bajando desde ahí. El desvío se paga dos veces, ida y vuelta. La geografía del mapa y la geografía de las rutas no son la misma cosa.
Otro par de endpoints asociados a una misma marca dio 173–179 ms desde São Paulo y 133–138 ms desde Salt Lake City. La diferencia describe esos endpoints en esa sesión; no caracteriza todas las cuentas ni todos los planes de la marca.
Registro no es ubicación
Dos patrones explican por qué el papel y la ruta no siempre coinciden:
- Un bloque puede estar registrado a nombre de una empresa colombiana y ser anunciado por una red cuya ruta y declaración pública apuntan a Estados Unidos.
- La ausencia de Colombia en un geofeed solo demuestra que ese archivo no declaraba una ubicación colombiana en la fecha consultada; no permite generalizar sobre todos los productos del operador.
Un bloque registrado a nombre colombiano no obliga a nadie a poner el hierro en Colombia. La ruta sí es verificable, y es lo único que el visitante experimenta.
Hay varias opciones locales
Hay más de un operador y más de una región cloud con infraestructura en Colombia. Si tu criterio principal es la latencia, conviene medir varias opciones locales desde las redes y ciudades donde están tus usuarios.
Nos gusta pelear ahí. Creemos que somos el mejor hosting de Colombia, y lo creemos precisamente porque lo que separa a unas opciones de otras ya no es la ruta. Es quién te contesta el teléfono, quién te emite la factura, bajo qué jurisdicción queda tu contrato y quién te sostiene el dominio cuando algo se rompe un viernes a las seis.
Cómo verificar tu propio sitio
No hace falta creernos. Hazlo tú.
- Resuelve la IP de tu dominio:
dig +short tudominio.com.co. - Consulta qué AS anuncia esa IP. Cualquier buscador BGP público lo dice.
- Corre
pingytraceroutedesde una conexión colombiana, no desde una nube ni desde un servidor. Anota el mínimo, no el promedio. - Mide además el TTFB de tu HTML, que es lo que sufre el visitante:
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://tudominio.com.co. Repítelo varias veces y quédate con el mejor. - Si usas CDN, mira la cabecera
cf-cache-status(o su equivalente). Si diceDYNAMIC, esa página viene del origen, no del borde. - Repite a distintas horas. Un solo dato no es una medición.
Si tu resultado se parece más a las filas de abajo de la tabla que a las de arriba, ya sabes de dónde salen los segundos que pierdes. Y entonces decide. Pero decide con el número en la mano, no con la bandera de la tienda donde compraste.
Metodología: 1.352 dominios bajo jerarquía .co clasificados por el AS que anunciaba cada prefijo. Latencias y TTFB medidos el 2026-08-30 desde una sola red en Bogotá; son observaciones puntuales y no caracterizan todos los productos de ningún proveedor. Nombres, endpoints, fuentes y límites se concentran en el anexo metodológico.
