Solo el 11% de los sitios colombianos se sirve desde Colombia

Un visitante en Bogotá abre una página con dominio .com.co. El dominio es colombiano. La empresa es colombiana. La factura es colombiana. El servidor está en Virginia.

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 se sirven desde infraestructura que se anuncia como colombiana. Once por ciento.

Y antes de seguir, el margen, porque un número sin su margen no es un número: es una consigna. De esos 1.352, 552 resuelven a un sistema autónomo extranjero directo y 559 quedan detrás de un CDN, donde desde afuera no se ve el origen. Si todos esos 559 se sirvieran localmente —hipótesis generosa—, la proporción «en Colombia» llegaría como máximo al 52%: (150 + 559) sobre 1.352. Ese es el techo aritmético del estudio. El piso verificado es el 11%. Y lo que medimos después dice que la realidad se parece mucho más al piso que al techo.

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í:

De ahí sale el 11%: unos 150 sobre 1.352.

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. Por eso el censo nunca viaja solo. Va siempre acompañado de la medición de latencia, que sí es empírica y no depende de registros.

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.

No se parece al techo. Medimos también dónde aterrizan de verdad: el 95% de los sitios colombianos que usan Cloudflare se sirve desde el punto de presencia de Miami, a unos 69 milisegundos, no desde el de Bogotá.

Hay excepciones reales y vale la pena nombrarlas, porque un artículo que solo trae evidencia a favor no sirve para decidir nada. Hay sitios que salen del borde de Google en Bogotá a 16,1 ms: es el caso de Wix. Y GoDaddy, por ejemplo, sirve capa estática desde el borde de Cloudflare Bogotá. Cuando el borde cae local, cae muy bien.

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:

Y la prueba más limpia no la ponemos nosotros: la pone Cloudflare. La respuesta de wnpower.net trae la cabecera cf-cache-status: DYNAMIC. Es el propio CDN declarando, en su propia cabecera, que esa página no se está sirviendo desde caché.

En la misma sesión medimos el contraste que lo explica todo: contra WNPower, el RTT al borde da 65,3 ms y el TTFB del servicio da 338,9 ms. El ping halaga; el servicio no.

Un borde cercano acelera las imágenes; no acerca el servidor.

Conviene leer esa tabla con cuidado y sin trampa: mide el sitio web de cada empresa, no el servicio que vende. Que hostdime.com.co esté detrás de un CDN no dice nada malo de HostDime, que opera datacenter propio en Bogotá y mide 20,0 ms de RTT. Dice algo del mecanismo, que es universal: si el HTML es dinámico, alguien tiene que ir hasta el origen a buscarlo.

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.

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.

El datacenter «latinoamericano» es la peor opción para un visitante colombiano

Aquí está el hallazgo contraintuitivo, y es el más útil de todo el estudio.

Para un visitante colombiano, São Paulo queda más lejos que Estados Unidos. Hostinger en São Paulo: 168–180 ms. Hostinger en Asheville: 94,9 ms. Cerca del doble, y la opción «regional» es la mala.

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.

El caso más limpio es HostGator: su tienda colombiana entrega desde São Paulo (173–179 ms) y su tienda estadounidense desde Salt Lake City (133–138 ms). Comprar en la tienda con bandera colombiana sale, según qué extremos del rango se comparen, entre 35 y 46 milisegundos peor que comprar en la estadounidense.

Registro no es ubicación

Dos ejemplos de por qué el papel y la ruta no coinciden. Los dos salen de declaraciones públicas de los propios proveedores, no de una sospecha nuestra.

• ColombiaHosting. Su bloque figura en LACNIC a nombre colombiano y su marca es colombiana, pero la ruta aterriza en Dallas, y nuestra medición lo confirma: 98–105 ms. No hay nada que destapar. Ellos lo declaran en su propia página de «nosotros», donde hablan de «dos de los mejores centros de datos en Estados Unidos».
• Hostinger. Publica su propio geofeed RFC 8805 (github.com/hostinger/geofeed), el fichero con el que un operador declara dónde ubica sus prefijos. En ese fichero no aparece ninguna ubicación en Colombia. Lo declara el operador; no lo dedujimos nosotros.

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.

No somos los únicos, y decirlo nos conviene

Hay más de un proveedor sirviendo de verdad desde Colombia. HostDime opera su propio datacenter en Bogotá y mide 20,0 ms. Oracle abrió región en Bogotá y mide 18,4 ms. Si tu criterio único es el milisegundo, tienes varias opciones colombianas legítimas, y este artículo no pretende esconderlas: un texto que borra al rival serio se cae con una sola búsqueda.

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ú.

1. Resuelve la IP de tu dominio: dig +short tudominio.com.co.
2. Consulta qué AS anuncia esa IP. Cualquier buscador BGP público lo dice.
3. Corre ping y traceroute desde una conexión colombiana, no desde una nube ni desde un servidor. Anota el mínimo, no el promedio.
4. 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.
5. Si usas CDN, mira la cabecera cf-cache-status (o su equivalente). Si dice DYNAMIC, esa página viene del origen, no del borde.
6. 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 anuncia cada prefijo. Latencias (RTT mínimo) y TTFB del HTML medidos el 2026-08-30 desde Bogotá, red INTERNEXA (AS18678), por ruta pública, desde una conexión de consumidor y no desde un datacenter. Los datos de terceros citados provienen de registros públicos (LACNIC, BGP, RDAP), de geofeeds RFC 8805 declarados por los propios operadores y de las páginas públicas de cada proveedor.